4 ms·

You're absolutely right that historically, it wouldn't have worked. But the web has since moved beyond plain old static documents. What was good for a 1989 web

by jules 14y ago

You're absolutely right that historically, it wouldn't have worked. But the web has since moved beyond plain old static documents. What was good for a 1989 web isn't what's good for a 2013 web. The design by committee of the W3C has resulted in overcomplicated yet at the same time underpowered designs. The model where an ivory tower mandates new things from the top down rarely works well. How many man years does it take to implement a new browser? It's basically an impossible task unless you have mullions of dollars to spend. A much better model for innovation is one where multiple competing technologies get implemented, and the best one wins organically. The web as a VM would have enabled that. You no longer need a committee that mandates HTML5. It can be implemented as a library, and if people like it they will use it. The W3C has a chicken and egg problem: before it standardizes something, there is not much experience with the features it standardizes, so it's hard to do good designs. On the other hand once you standardize something, you're stuck with it. It can (practically) never die. If you have multiple "HTML5 libraries" then it's not a problem to try something out, and pick the best thing. The best solution can win, and the others can slowly fall out of use.

chubot 14y ago
I agree with the problems, i.e. that web standards and implementations are messy, but not with the solutions. It just seems like a big pipe dream -- "oh I wish we could start over from scratch, rewrite the web, and make things clean". Will never happen. I also don't agree in 2013 that moving say HTML5 to a VM is a good idea. There's nothing stopping anyone from releasing a VM now. You could release a new VM and an application platform. I mean that is essentially what, say, Android is. But even Android clients will always be a subset of all web clients. I think people proposing this mythical VM don't have a clear understanding of what VMs are. They are fairly specific devices. Do you think Dalvik, something like v8, or the JVM, or .NET, can form the basis for all future computing? It's an impossible task for a single VM. Even Microsoft is taking more than 10 years to move a decent amount of their own software to their own VM, on a single platform. All VMs necessitate design decisions that are not right for all devices. Even Sun had diverging VMs for desktop and mobile.
- 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.

by jules 14y ago

chubot 14y ago

I agree with the problems, i.e. that web standards and implementations are messy, but not with the solutions. It just seems like a big pipe dream -- "oh I wish we could start over from scratch, rewrite the web, and make things clean". Will never happen. I also don't agree in 2013 that moving say HTML5 to a VM is a good idea. There's nothing stopping anyone from releasing a VM now. You could release a new VM and an application platform. I mean that is essentially what, say, Android is. But even Android clients will always be a subset of all web clients. I think people proposing this mythical VM don't have a clear understanding of what VMs are. They are fairly specific devices. Do you think Dalvik, something like v8, or the JVM, or .NET, can form the basis for all future computing? It's an impossible task for a single VM. Even Microsoft is taking more than 10 years to move a decent amount of their own software to their own VM, on a single platform. All VMs necessitate design decisions that are not right for all devices. Even Sun had diverging VMs for desktop and mobile.

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.