4 ms·

Do you think HTML+CSS+JS+(...) can form the basis of all future computing? You have to apply the same standards to both sides. It's hard to be perfect, yes, but

by jules 14y ago

Do you think HTML+CSS+JS+(...) can form the basis of all future computing? You have to apply the same standards to both sides. It's hard to be perfect, yes, but it's easy to do better than the web mess. If I had to choose between HTML+CSS+JS+(...) and either the JVM or CLR as the basis of the future of all computing, I would definitely choose one of the latter options. Both the JVM and .NET VM would work okayish, though obviously not ideal. You want a simple bare bones low level VM with the sole purpose of building things on top of it. The JVM and .NET have much cruft of their own. That stuff should go into libraries, not into standards. You don't need to start from scratch and force everybody to adopt, W3C style. You can build the initial version as an abstraction layer on top of web technologies, so that only the VM implementors have to take care of hiding the mess, and application developers can build on top of that. With current improvements in JS VMs and things like WebGL this is slowly becoming feasible. If that is successful, you can implement a high performance version natively. This is inevitable. We won't be using HTML+CSS+JS in 100 years, other than for archaeological purposes. The question is how soon will it happen.

chubot 14y ago
HTML and company aren't the basis of all future computing, but they or their non-Turing complete descendants absolutely will exist in 100 years. They don't exist for lack of imagination; they exist for timeless and fundamental reasons. Do you think plain text will exist in 100 years? If so then it's not that much a stretch to say that HTML will. It astonishes me that people think that only code, and not data, will be transported over networks. That seems to be what you are claiming -- that it's preferable to transmit code than data in all circumstances? The argument isn't symmetric because I fully believe that VMs are necessary for the web. I just don't agree with Kay that the designers of the web are idiots (he really says this) because they didn't start with a VM. VMs will come and go as hardware and devices and circumstances change. Data has much more longevity; it encodes fewer assumptions. Assumptions that are no longer true are generally the reason a technology dies. It is pretty easy to imagine a VM (unknowingly or not) encoding preferences for keyboard and mouse input; that technology would have died with the advent of touch screens. Likewise, a VM that provides affordances for touch screens will likely be dated in 10 years when we're using some other paradigm. HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language. They will be around for a LONG LONG time. More complicated constructs like JS and VMs will have shorter lifetimes. I guarantee you that HTML will be around long after whatever comes after JavaScript, just like HTML will outlive Java Applets and Flash. They layered architecture of the web is absolutely the right thing. Use the least powerful abstraction for the problem, which gives the client -- which necessarily has more knowledge -- more choices. You could distribute all text files as shell scripts, but there's no reason to, and a lot of reasons why you shouldn't.
- jules 14y ago
  Sure some kind of markup construct will exist in 100 years. But not HTML. I do not believe plain text will exist in 100 years, but that's another discussion. I am claiming something far weaker than what you seem to think I'm claiming. I do not think each and every website will be written from scratch on top of the VM. I'm simply claiming that the distribution mechanism for new features of the web will change. Currently the features are mandated by the W3C, then implemented by all browser vendors. The browser vendors send out updates to all users. Instead what will happen is that some future version markup language that's better than the then current HTML will be distributed as a library, running on top of the VM. This way if you are a site owner, you can immediately start using it. You do not need to wait until (1) the W3C recognizes that this markup language is a good thing and standardizes it (2) the browser vendors have implemented it (3) your visitors have updated their browser. You simply include the library, and start using the new markup language. Note that this is already happening in the small. Javascript libraries like knockout.js are already changing the fundamental model of building web applications. Instead of waiting for the W3C to standardize some kind of web components with data binding, people implemented it as a library. 20 years ago people would have thought such a thing impossible. They would have thought that something like that surely has to be built in to the browser. As JS gets more powerful, more and more features can be implemented this way, instead of through standardization. Note that things are still flowing over the network in markup language (in this case, knockout.js template language). A similar thing happened with form elements. Remember the xforms standardization effort? Nobody cares anymore because JS libraries offer far better rich forms elements. The thing that changed is where it's implemented: ON the web, rather than IN the web. This organic model is far more in line with the principles of the internet, rather than the centralized way it's done with the web standards. Instead of giving somebody a fish, give him the tools to fish. > HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language. A few days?! This is absolute nonsense. You can't even read the spec in a few days, let alone all the specs it depends on, like PNG, JPG, etc. Maybe you can implement some tiny subset of HTML in a few days, but the whole thing is massively complicated. In comparison a VM is far far simpler. 100 years is a very long time. The web is 23 years old.

by jules 14y ago

chubot 14y ago

HTML and company aren't the basis of all future computing, but they or their non-Turing complete descendants absolutely will exist in 100 years. They don't exist for lack of imagination; they exist for timeless and fundamental reasons. Do you think plain text will exist in 100 years? If so then it's not that much a stretch to say that HTML will. It astonishes me that people think that only code, and not data, will be transported over networks. That seems to be what you are claiming -- that it's preferable to transmit code than data in all circumstances? The argument isn't symmetric because I fully believe that VMs are necessary for the web. I just don't agree with Kay that the designers of the web are idiots (he really says this) because they didn't start with a VM. VMs will come and go as hardware and devices and circumstances change. Data has much more longevity; it encodes fewer assumptions. Assumptions that are no longer true are generally the reason a technology dies. It is pretty easy to imagine a VM (unknowingly or not) encoding preferences for keyboard and mouse input; that technology would have died with the advent of touch screens. Likewise, a VM that provides affordances for touch screens will likely be dated in 10 years when we're using some other paradigm. HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language. They will be around for a LONG LONG time. More complicated constructs like JS and VMs will have shorter lifetimes. I guarantee you that HTML will be around long after whatever comes after JavaScript, just like HTML will outlive Java Applets and Flash. They layered architecture of the web is absolutely the right thing. Use the least powerful abstraction for the problem, which gives the client -- which necessarily has more knowledge -- more choices. You could distribute all text files as shell scripts, but there's no reason to, and a lot of reasons why you shouldn't.

jules 14y ago
Sure some kind of markup construct will exist in 100 years. But not HTML. I do not believe plain text will exist in 100 years, but that's another discussion. I am claiming something far weaker than what you seem to think I'm claiming. I do not think each and every website will be written from scratch on top of the VM. I'm simply claiming that the distribution mechanism for new features of the web will change. Currently the features are mandated by the W3C, then implemented by all browser vendors. The browser vendors send out updates to all users. Instead what will happen is that some future version markup language that's better than the then current HTML will be distributed as a library, running on top of the VM. This way if you are a site owner, you can immediately start using it. You do not need to wait until (1) the W3C recognizes that this markup language is a good thing and standardizes it (2) the browser vendors have implemented it (3) your visitors have updated their browser. You simply include the library, and start using the new markup language. Note that this is already happening in the small. Javascript libraries like knockout.js are already changing the fundamental model of building web applications. Instead of waiting for the W3C to standardize some kind of web components with data binding, people implemented it as a library. 20 years ago people would have thought such a thing impossible. They would have thought that something like that surely has to be built in to the browser. As JS gets more powerful, more and more features can be implemented this way, instead of through standardization. Note that things are still flowing over the network in markup language (in this case, knockout.js template language). A similar thing happened with form elements. Remember the xforms standardization effort? Nobody cares anymore because JS libraries offer far better rich forms elements. The thing that changed is where it's implemented: ON the web, rather than IN the web. This organic model is far more in line with the principles of the internet, rather than the centralized way it's done with the web standards. Instead of giving somebody a fish, give him the tools to fish. > HTTP and HTML are foundational to the web. They are basically the simplest thing that could possibly work. You can reimplement them in a few days using a high level language. A few days?! This is absolute nonsense. You can't even read the spec in a few days, let alone all the specs it depends on, like PNG, JPG, etc. Maybe you can implement some tiny subset of HTML in a few days, but the whole thing is massively complicated. In comparison a VM is far far simpler. 100 years is a very long time. The web is 23 years old.