Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It's clear that the web has outgrown its original intent. Instead of just being a simple substrate for linked documents, many (if not most) websites are now trying to emulate applications, platforms, and services using the poor, ill-suited DOM.

But I don't think the solution is to give up. Native apps are great, but there's a vast gulf between the binary running on your device and the server you got it from. Downloading and updating take forever. Connecting to other apps is barely possible. Everything is horribly siloed. The brilliance of the web is that it allows people to quickly connect to computers anywhere in the world and get at whatever stuff they might want to serve; native apps will never have that level of flexibility, barring some horrible proprietary ecosystem.

Unfortunately, the web was designed primarily with content in mind, not presentation. The only way servers can provide interesting and slick user experiences is to hack up the content presentation system, which is as silly as using spreadsheet scripting to build enterprise software.

So I think the best approach would be to revisit the design of the web. Instead of having the web be strictly document-centric, I think there should be a higher level above that, through which HTML, CSS, the DOM, and everything else are implemented. A sandboxed, scriptable, low-level canvas that only gives you the bare essentials, allowing you to create native-quality experiences without having to piggyback on the DOM or reinvent the universe via canvas or WebGL. A "Vulkan" equivalent for web software. Not making a document? Feel free to not use HTML — or only embed it in the parts of your web-app that actually present content.

It should be possible for a user to go to facebook.com and immediately retrieve an equivalent to the Facebook app in their browser — smooth scrolling, gestures, and everything. (Or whatever the future equivalent of a browser might be.) But if a user navigates to a simple blog, it should still appear as it does in the web today, because this new web would be a superset of today's web.

We've been interacting with other computers through a seriously constrained pipeline this past decade. Instead of bowing our heads and conceding defeat, why not blow it wide open?



What layer can you realistically have below the DOM? If you get rid of it, how can you realistically avoid reimplementing everything? I don't think this makes sense.


I think UIKit (and possibly Android, which I haven't worked with) has the right idea: nested, texture-backed views that can render their own content.

You might argue that canvas and WebGL nodes in the DOM already serve this role, but I disagree. In their current form, these nodes exist inside the document-based world of the web rather than containing it, an inversion of what I see as the proper hierarchy. This arrangement poses a number of problems for designing rich apps, including very poor performance related to content reflow. Some companies[1] are trying to fix this by manually doing all their rendering inside canvas and re-implementing HTML and CSS along the way. Unfortunately, this is a ton of work and results in a web experience that is non-standard in many ways, including for things like accessibility and text selection. The fact that this actually does work to significantly improve the user experience, however, points to the fact that something needs to drastically change for the web to remain healthy, useful, and relevant.

My understanding is that the DOM is already implemented as a series of texture-backed views in many browsers. That would still remain the same — nobody would have to reimplement this functionality. I just think it would be a great idea for us to be able to use those same texture-backed views for custom UI unrelated to HTML and CSS, and to separate the rendering concerns of text and document flow from the design of user interfaces.

[1]: https://news.ycombinator.com/item?id=9029159


Beyond views you need a way to layout them. Would you not be simply reinventing the DOM?


In my experience, HTML-style layout is just horrible for app UI. It's really much better suited for text. On iOS, you can either use autolayout (constraint-based layout) or alternatively perform layout manually, in code, for that purpose.


I think it should be a subset of DOM / CSS designed for speed and flexibility. A normal browser could render the page correctly but an optimized browser for apps would be able to make some assumptions to render everything much faster. Something like asm.js but for DOM/CSS.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: