Hopefully 5 years is long enough for us to stop and take stock of the inevitable destination of the browser: an OS in a VM.
With any luck we might finally realise that we're not dealing with "documents" anymore, that HTML, JS, and CSS do not a good UI framework make, and that JS simply isn't good enough for what we need it to do and how we need it to do it.
ECMAScript 7 will be pretty much ready to implement and the standards committee will realise that they've run out of syntax for ECMAScript 8, forcing a rethink. Fingers crossed a neckbeard will arrive and point out that a LISP would be ideal for both defining the "DOM" and providing a base language for targeting by other languages, who can just (ok, "just") serialize their ASTs and pass it in.
Seriously: if, in 5 years, we're still perfecting the dominant user-facing runtime by tweaking an arbitrary XML spec, a language with only one kind of number, and a styling language so inept it almost requires auto-generation tools, well I might just kill myself.
Five years is nowhere near long enough for the entire platform to be replaced with something completely different. Unless, of course, you mean the "OS" and VM that is already in our browsers; but it seems apparent you don't want that OS and VM, you seem to want something very, very different (and different in ways that nobody is really working on, as far as I know).
I'm less critical of JavaScript, but I've also got a much more conservative expectation of how much will change in any five year period. Your estimate assumes more dramatic and rapid change to the web than at any point in its history (except maybe the initial introduction of the graphical browser, or of the release of JavaScript, itself), and an ecosystem with a few billion participants does not and cannot change as fast as one with a few thousand. And, of course, for something to be the way we all do things in five years, somebody would have to be doing it that way today on a small scale.
Please don't kill yourself, despite the fact that your dream definitely is not going to happen the way you've envisioned it. (In its place will be a gradual, but measurable, improvement on nearly every front in the systems we currently work with. It'll probably all turn out alright.)
I wouldn't dare expect this to exist in 5 years, but I hope maybe it's an issue slightly closer to the front of our minds. We really don't need, or even want, a wholesale replacement of the browser internals - the rendering engines, sandboxing techniques, etc. are good: all I'm saying is it would be really, really nice if we could have access to these components at a lower level (not too low, mind) than what we've currently got.
I'm fine with JS as a thing that exists, my problem is with it's position as the "assembly of the web" (credit to user Lerc below for that fine phrase.) The good parts of the HTML/JS/CSS paradigm are making awesome things, but the bad parts make our lives far more difficult than they need to be.
And don't worry, I'm not actually going to kill myself, but thanks for the concern.
After doing web for a little bit, ending up loathing it, and then checking out iOS and enjoying it so far, I couldn't hope for this outcome more. I never realized how crippled browser based web applications and the ancient, shitty tools used for creating them are before developing on a web-connected platform that uses a systems language directly for its applications. Pretty much anything you can do with a computer, you can do in an iOS/Android app, and it can connect to the web, which lets you create rich experiences far more easily. To make any modern web application for a browser, you have to use garbage like opinionated JS frameworks and a myriad of other crutches and hacky solutions because the tools for the frontend are incredibly limited and were not designed for what is demanded of them today. Plus browsers don't easily support connection protocols other than HTTP, so this leads to a whole other host of hacky backend solutions for developing so called "real-time" applications, when you could easily use something like UDP were you not limited by a browser. Only downside to iOS/Android platforms is that they are governed basically by the Apple/Google dictatorships(which is somewhat understandable, because it would be a disaster if anyone could so easily distribute applications widely capable of executing malicious code on a user's device), and it is completely up to them what is allowed and what isn't, in contrast to the open nature of the web. I don't know how this could be remedied, seeing as there is an undeniable trend of more and more consumer-facing web activities being done through mobile apps, rather than browsers. Something like a completely FOSS device OS with a decentralized marketplace; e.g. anyone with a server can host their application, similar to how it is with jailbroken/rooted phones? This still wouldn't solve the problem of people being able to execute malicious code on a user device, but I guess if you think about it it isnt much different from some idiot downloading "free cursors" from some malware site and giving themselves a virus like what happens all the time today.
Really? Web technologies are much easier to work with and make a much better UI toolkit. Just look at the share amount of developers doing Web stuff and compare them with the amount of developers doing iOS.
And btw, iOS development is easy for as long as you do not want to customize things. Once you start changing the standard controls you are entering the land of no return.
Now compare this with web technologies which are designed to be customizable.
Which native tools are you referring to? I only have a little experience with xcode which seems decent but not that great to me. Most of my experience was with Microsoft technologies like WinForms, XAML and MFC a long time ago.
To me, HTML+CSS which I am only really starting to use lately, is a much more pleasant experience. There are many quirks obviously, but I dread to think about how it would have been to design something that doesn't just look like a plain vanilla app in one of the native frameworks. I think Flash was probably a nice design experience with a bit more holistic approach, but I never learned that and I don't see a reason to now.
I know it's a little dated, but I love Java SWT for producing native GUI. In particular, I almost exclusively use 'GridLayout' on all my controls and it just works.
With HTML + CSS I find it difficult to map 'how the screen should look' in my head to the HTML/CSS code due to the complexity of the layout mechanism. I often grind my teeth and think, "How can such a simple layout be so difficult to produce?!"
Well, what I meant was more APIs than tooling itself. Many hate XCode, but I think it OK, and AppCode is decent alternative.
I've been dealing with the web tech for some 18 years now, and iOS development experience was really refreshing.
Yes, doing anything not plain vanilla takes some work, but the APIs are very powerful, and even so with addition of UIDynamics and friends.
OTOH if you want plain vanilla app you don't have to reinvent the wheel.
I'm deathly afraid of that ever becoming true. An OS in a VM by default? Isn't that the end of all things nice and native? I know that's pretty much the state of affairs in the browser already but I do worry about how that would affect other parts.
Will system language become even less popular and "apps" even more popular? Will we completely live in the cloud by default? What will happen to our data in the long run?
What more functionality exactly are you trying to achieve with this "OS in a VM" concept you are referring to?
Would you say Iphone/Android/WP apps satisfy what you consider a "OS in a VM?" Or close to it? The web and and iPhone app environment arent that different anymore.
It's not a concept I'm peddling, it's an observation.
Back in the day the browser was a document browser - like a read-only, network-enabled version of Microsoft Word. It's goals have changed immeasurably, but the technology largely hasn't - at least not at the conceptual level. We use it to make applications that are much more like actual applications than they are documents. The slow march of the browser is to doing "anything" a native app can - we now have geolocation APIs, graphics card access, "threading", native drag-and-drop interop, etc., etc.
By OS, I meant it more in the way the JVM is an "OS" ("virtual machine" is too vague): it can do almost anything the actual OS can, provides platform-agnostic drop-ins for many native toolkits (e.g. GUI), and for a tremendous amount of the workload, developers needn't care needn't care what platform they're on. Now the JVM has its flaws for sure, but at least it knew its purpose before it grew up, the result being it is highly performant (less the boot time) and flexible.
If you need a document browser, sure you can build in a little macro language with only one kind of number, but if you need a VM a la the JVM you'd be well advised to build something better. My point is that we're heading somewhat blindly towards the latter by making a Frankenstein out of the former, and we really could do with pulling over and looking at the map for a bit.
I think this is a ridiculous thing to say. Don't think of the web as dev platform. Think of it as OpenGL or any other GL language. To create a game you need to use a graphics card which provides a primitive set of instructions but they can be empowered with the help of libraries. The web is the same. It provides a primitive set of functions that can be represented in a common way. They are still usable on their own but much more useful as part of frameworks.
Web technologies is for UI what opengl is for gaming.
I am also not fond of language snobbery. There are certainly languages I hate, but I accept that people find that they suit their needs. People should be free to choose something that works for them.
The difference with JavaScript is the notion of it being the "Assembly of the Web". JavaScript as a Compilation target presents a problem. People can't freely choose their preferred development style if it is not accommodated by JavaScript. Blocking IO, pre-emption, concurrency etc. These are all things that programmers may choose, You shouldn't be forced to use such techniques, but nor should a platform deny them because of the limits of a single language.
With any luck we might finally realise that we're not dealing with "documents" anymore, that HTML, JS, and CSS do not a good UI framework make, and that JS simply isn't good enough for what we need it to do and how we need it to do it.
ECMAScript 7 will be pretty much ready to implement and the standards committee will realise that they've run out of syntax for ECMAScript 8, forcing a rethink. Fingers crossed a neckbeard will arrive and point out that a LISP would be ideal for both defining the "DOM" and providing a base language for targeting by other languages, who can just (ok, "just") serialize their ASTs and pass it in.
Seriously: if, in 5 years, we're still perfecting the dominant user-facing runtime by tweaking an arbitrary XML spec, a language with only one kind of number, and a styling language so inept it almost requires auto-generation tools, well I might just kill myself.