HTML5 is done, but two groups still wrestle over Web's future
cnet.com
cnet.com
Guess what I spent this afternoon doing.
This is why backend server devs seem to actually make it to middle age, whereas front end types go to burning man one time and never come back.
Yeah, HTML/CSS/JS have lots of warts and hangovers from their respective document-oriented origins. But recent developments have been great, and there are myriad tools to make working with these technologies pretty enjoyable (SASS in particular changes the whole business of styling.)
I think that ultimately, building cross-platform, cross-device apps is always going to involve a fair bit of work. The web's still the best tool for doing that, and it's getting better.
HTML/CSS/JS have warts but you have no choice but to use them.
For instance TV set-top boxes very often use the web stack for their GUIs. Though, to be honest, they often use SVG for markup instead of HTML.
See e.g. http://www.w3.org/TR/html5/references.html#refsURL wherein they add in a non-normative note a link to the WHATWG URL spec, but in the normative reference text instead link to an old, outdated working draft from 2012 which specifies an incorrect algorithm and APIs that do not exist in any browser like getParameterNames() and so on.
It's very tragic, and not at all good for the health of the web.
And rightly so. Being locked into a store worries me much, much less than being locked into using JS and HTML.
JS and HTML are about the only things offering freedom on the internet these days.
it was going just fine until apple disabled it in iOS7
but despite that setback, google continues to bank its entire business on offline web apps.
That doesn't preclude other sources and as you've noted, HTML and JavaScripts are Web technologies which are of course a subset of... the internet! Besides, these days not all IP packets are transited equally.
As far as I'm concerned, you are comparing two relatively small and often overlapping subsets of internet based technology, and you are making assumptions about the internet as a whole based on that comparison. I don't mean to say that you don't understand the difference between the words, but saying that HTML/JS offers the most freedom seems to ignore the less restrictive technologies it is built on.
Surely, the ability to use an open source software stack to create a socket connection and send arbitrary data to a different machine across the network offers more freedom than HTML/JS in a general sense of the word.
As for not all IP packets being transited equally, I'd say that it's more the result of internet freedom than it is of any sort of restrictive policiy. The way to stop it is either a more restrictive law, or an inconvenience great enough to get people to vote with their feet.
1) markup languages: 1 choice - HTML 2) client-side scripting languages: 1 choice - JS.
PS: please don't tell me about transpilation, it's crap.
Contrast that to the preferred emacs/vim + terminal tools of your average developer. No one is trying to make this easier for us, and those that are get ignored (like Adobe Muse, maybe?).
That you aren't worried doesn't mean that you're correct.
But several people seem to insist that's a poor solution. It sounds like they want direct support for other languages in the browser but how can they securely directly support other languages?
Even if you found some way to get some other language into the browser without translating to javascript; (and this has been done before. remember vbscript?)... the new guest language has to co-exist with any javascript that might also run on the page, share the same memory, share the same dom objects, share the same GC, and avoid all the multiple potential nasty browser crashing bugs that could result from trying to do that. And you have to ship the runtime for that language along with the browser, or as sigh another plugin. And guess what, no backwards compatibility.
Given that, you then have to cope with the fact that javascript's GC might not totally make sense for your language, and do all the workarounds that requires.
Compiling to ASM.js gets around this by essentially giving you a low level VM whose bytecode just happens to look like javascript, and whose behavior when interpreted as javascript happens to be correct. When run in firefox, the code is short circuited and ahead-of-time compiled. It doesn't have to deal with the javascript GC since it allocates a heap for the guest program ahead of time as well.
This is really cool if you think about it. You get javascript's more or less secure sandboxing, you get access to all the apis, you can interact just fine with existing javascript libraries, with about the lowest amount of overhead you can get just short of the NaCl approach (which is basically just a revisit of activeX)
The only downside to all this:
it's not the web.
This is not web. It runs in a web browser, but it's downloading a blob up front, ahead of time compiling, and playing a raw executable inside a browser host.
There's considerable advantages to zero-install programs and games. But you know, exchanging one kind of opaque inaccessible blob in a webpage for a different kind that just happens to not need plugins is not that great.
Accessibility is a good thing, and we shouldn't be too eager to throw it away for the shiny.
compiled html with something that resembles protocol buffer would make webapps much smoother.
I guess I'm a low level nerd.
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.
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.
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.
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.
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.
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.