compiled html with something that resembles protocol buffer would make webapps much smoother.
I guess I'm a low level nerd.
no no no no no no no no no
You know what a compiled web app looks like? Here:
Content-Encoding: gzip
You know what makes webapps slow? It's badly-written Javascript. It's bad router and proxy connections. It's creating forty-odd connections to thirty-odd 3rd party CDN and analytics and ad platforms. It's gigantic images that aren't sized correctly. It's badly-written CSS that misuses transforms and graphics commands.
It's not JS implementations being slow. It's not HTML documents being hard to parse. It's not a shortcoming in HTTP.
Your comment suggests a lack of familiarity with the problem domain.
Um, based on what? My browser routinely takes up gigabytes of memory just to show me 'one PDF' worth of content. Analytics scripts steal my CPU time/power that I pay for. HTML/CSS's shitty ambiguous spec without a reference implementation means that no two browsers will ever work alike. And if you're on mobile, all that means you're battery life is screwed. And um.. security?
http://secunia.com/vulnerability-review/browser_security.htm...
The 1/100 of a penny worth of electricity that analytic scripts cost you a year is worse than the security nightmare of java applets and activeX? Come on.
The irony is that the web stack has become so complex you may as well build apps using one of the many mainstream compiled languages for app logic, and work with an improved DSL for styling and markup. (Which is more or less what Go+SASS/etc are becoming anyway.)
The inevitable next stage will happen when the W3C discovers functional programming - I'm guessing around 2020 - and we'll have Greenspun our way to the 10th law again.
I'm not aware of a single technology with a goal to fundamentally upset any of the things you listed.
Personally, I'm satisfied with javascript development. Is it perfect? No. Are there lots of things that could be done better? Absolutely.
But it frustrates me how many people complain about how much it sucks when there are no projects (with any support) attempting to really change things. If my opinion of javascript is wrong and it really is that bad - I'd think there would be more of a movement to move away from it.
You should watch this https://www.destroyallsoftware.com/talks/the-birth-and-death...
Programmers can't always just start something "new", they have to work on existing platforms to be able to deploy their software quickly and efficiently. This video explain than even though javascript was never intended to run a 3D engine, it now is able to. As he explains it in the video, it's a hack, and it doesn't work that well for most binaries.
If I could, I would start a new browser, without html, with more dynamic languages, with a clang VM, with protocol buffers, etc. But in this age of patents and market shares in IT, I don't expect having enough exposure to have users installing this future browser. If one software company can't deploy its app on the dominant systems, it's screwed. But it doesn't mean JS fits every possible job.
http://www.adobe.com/nl/products/air.html
For some reasons it's not really taking off.
Sure, I personally don't see why that's controversial. They're no different from running JS or flash/silverlight plugins or what have you. My problem with HTML/JS/CSS is that they suck right from the design down to the implementation. With Java and ActiveX , the suckage exists, but mostly at the configuration, deployment and implementation steps. They are redeemable in my view.
>The 1/100 of a penny worth of electricity that analytic scripts cost you a year is worse than the security nightmare of java applets and activeX? Come on.
I see the nightmare coming from IE, FF and Chrome in terms of browser vulnerabilities. Java's installed base is tiny compared to those three.
Also, my CPU usage routinely goes over 50% (E8400) when browsing. I don't think reading a bunch of text should require you CPU to spike like that. I admit the analytics part is an aside because you can bolt it onto Java or ActiveX as well.
also, http relies on tcp, so it will always be synchronous, there is hardly going back and forth between the client and server. ajax is not something easy to deploy.
The size difference over a wire between gzipped/deflated text and protocol buffers is also usually dwarfed by almost any other asset being loaded on the page (images, fonts, videos etc).
The benefits of human readability and simplicity probably outweigh those size differences, I think.
I do agree there's a lot of room for improvement in the html/css/js combination, though. They were designed for far less dynamic interfaces than those we're trying to build today.
The CSS model in particular is very conceptually complicated for a layout system. I say that having used it for 13 years.
Controlling browser prefetching and load ordering would do much more than rewriting to use a binary format, as would alternative layout options, as would better image formats, as would more performant VMs (e.g. better asm.js support), as would... A near-endless number of things. Text vs. binary for the initial document tree doesn't make an appreciable difference.
It's the increasingly complicated DOM, and CSS3 layout model.
Web Apps go slow, and this gets blamed on javascript because that's the language you happen to be writing in. (or wronging in). But the slowness you get usually comes from the constant triggering and retriggering of giant byzantine relayout and compositing algorithms from what you might think is reasonably written code.
it's THAT problem that facebook's react library is aimed at... fixing? no, reducing. Write reasonable JS, and let the library optimise DOM interactions.
Every new feature of HTML5 and CSS adds some weight to those enormous piles of sand the browser has to shift around.
Binary formats would not fix that. Bytecodes wouldn't fix that. Different languages wouldn't fix that. Javascript is fine. it's the DOM and CSS that need to be fixed.
Is it as fast on low end to medium-priced smartphones ? HN is much less complex than other website you can visit, it's a very minimal design.
Even if you compress it, how really is it to parse a big html page ? How many CPU cycle do you need depending on the size of the page ? Couldn't you optimize a webpage by removing unnecessary tags by compiling or pre parsing it ?
I'm talking about parsing performance though, not the size of one page.
Compiling HTML if done correctly and properly would effectively freeze the design permanently.
How ? And do you mean that as a good or a bad thing ? As a bad thing, I disagree, it could still be backward compatible.
And isn't frozen platform better to work on ? Can't remember the quote about frozen water.
Many modern HTML features exist because old parsers were extremely forgiving or even buggy. Even something as simple as the HTML5 doctype isn't a valid SGML doctype expected by HTML 4 browsers. It is a hack which just happens to produce the correct results on older browsers.
Javascript used to have to be placed in HTML comments so that old browsers wouldn't display the source code as content because the earliest browsers had no concept of client side scripting.
Obviously a frozen platform is better to work on -- that's why people continually suggest such things for HTML. Make it compiled! Make it binary! The current situation is far from ideal. But if someone had done that with HTML 1.0 it would have been a lot harder to make it version 5.0.
I think you're focusing on the wrong part of the problem if you think that HTML parsing is the limitation on web performance - it's not.
I just saw my coworker using Axure for prototyping and I was impressed - it creates working prototypes with clickable buttons that perform functions and calculations. It's basically what making webpages should be. Except it isn't. Why don't they just make that compilable and distribute a viewer to compete with web browsers? Inertia.
That's been done - with Flash, for example.
Azure is suitable for building prototypes. It's not a replacement for the arbitrarily flexible set of visual, semantic and development tools that HTML, CSS and Javascript offers.