2 ms·

I think we're approaching a point at which browsers will need to make some sort of break with the current DOM in order to provide the types of rich experiences

I think we're approaching a point at which browsers will need to make some sort of break with the current DOM in order to provide the types of rich experiences engineers and users want. There's simply too much baggage with the current implementation, and this article highlights a lot of it: attribute values limited to strings, a global namespace for CSS, etc. This is happening at other levels of the web with the HTTP/1 —> HTTPS/2 transition. We're patching over shortcomings in the DOM right now with JavaScript, but it's easy to see the appeal of a native solution to some of these issues that doesn't require a facade over the actual thing that people interact with.

wrs 10y ago
It saddens me that the software industry has been flailing around for at least 15 years trying to resolve the tension between having zero-install + standardized framework and having a rich UI toolkit that can do "real" apps without making developers crazy. The answer seems to be this weird cycle of layering reinvention atop reinvention because nobody can just blow up the whole stack and rethink it with any market success. Using the DOM + scripting pattern with a DOM more suited to "rich app" development has been tried multiple times as plugins (FLEX and Silverlight come to mind). But the gravitational pull of zero-install + standards crushed them. We also have in progress what is essentially a reinvention of the JVM idea (WebAssembly) but without the UI layer to go with it. That may be successful in its narrow niche, or it may try to overreach into the UI layer and fail like all the others…too soon to tell.
- nercht12 10y ago
  What would be the language to use? JavaScript won early, so it's been the de-facto choice every since to the point where browsers probably don't even run other scripting languages with the script tag. The first major hurdle in changing all of this would be getting everyone to agree on what to use. Different languages are suited for different jobs. HTML is perfectly fine for static UI, which is what most sites need it to do. What would a better language or set of tools for the web even look like?

wrs 10y ago

It saddens me that the software industry has been flailing around for at least 15 years trying to resolve the tension between having zero-install + standardized framework and having a rich UI toolkit that can do "real" apps without making developers crazy. The answer seems to be this weird cycle of layering reinvention atop reinvention because nobody can just blow up the whole stack and rethink it with any market success. Using the DOM + scripting pattern with a DOM more suited to "rich app" development has been tried multiple times as plugins (FLEX and Silverlight come to mind). But the gravitational pull of zero-install + standards crushed them. We also have in progress what is essentially a reinvention of the JVM idea (WebAssembly) but without the UI layer to go with it. That may be successful in its narrow niche, or it may try to overreach into the UI layer and fail like all the others…too soon to tell.

nercht12 10y ago
What would be the language to use? JavaScript won early, so it's been the de-facto choice every since to the point where browsers probably don't even run other scripting languages with the script tag. The first major hurdle in changing all of this would be getting everyone to agree on what to use. Different languages are suited for different jobs. HTML is perfectly fine for static UI, which is what most sites need it to do. What would a better language or set of tools for the web even look like?