"...anything that slows the improvement of the Web means programmers are more likely to devote their energies to writing apps for smartphones and tablets running on Apple's iOS and Google's Android operating systems instead of HTML5..."
And rightly so. Being locked into a store worries me much, much less than being locked into using JS and HTML.
Well, when I want internet I launch browser. When I need something else, I launch an app. More likely than not it gets data from some web server via HTTP and in JSON. It may even use bits of HTML for some views. Who cares.
I don't get this obsession to defeat native on mobiles. Like don't get at all. Some dark thoughts start to creep in: maybe that's just some lazy webdevs who see mobile as new hotness but cannot be bored to learn native try to pull the only thing they know into that space? If embeded programming will be the new hotness, will we see the same?
Why complain about developers developing for Android and iOS, but not metion those developing for Windows or OS X?
And throwing half-baked (at best) features so just some capabilities can be checked on the HTML-on-mobile laundry list won't make them more fun to work with.
How's that offline web apps thing going?
Essentially every Android phone or tablet permits side-loading of apps, and installing third-party app directories ("stores"). People may not use such very much, but the freedom is still there.
It annoys me when the internet and the www so obviously get conflated. The internet is pretty much built on open standards, and open TCP/IP implementation exist for the most obscure of hardware, while HTML and JS are what I'd like to call de facto non-standard.
I'm not conflating the two by any means. Two of the internet's shining sources of freedom are HTML and JavaScript especially when compared to the walled gardens of app stores.
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.
> I'm not conflating the two by any means. Two of the internet's shining sources of freedom are HTML and JavaScript especially when compared to the walled gardens of app stores.
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.
Why not? App development for phones and tablets offer beautiful and very usable platforms to make it easy and painless for developers to create apps.
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?).
Is there actually a secure way to add support for other languages to the web? No matter what it will need to run in a hardware agnostic VM. So let's say for the sake of argument they added built-in support for Java (just the language not the APIs) in browsers. Would that come free of any security costs or would the added schematics grow the attack barrier or make vulnerability testing more difficult?
Yep. just compile it to javascript/asm.js and you get basically native speed, same security sandbox as javascript, and all the same problems with the web; the vast majority of which have absolutely nothing to do with javascript.
While I believe you are correct in that supporting more languages by won't fix the issues people have with developing for it as they would really want the APIs/frameworks for those languages and in that regard compile to JavaScript tools would better serve them since the only secure way to give developers multiple API's to work with is through a translation tool.
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?
Yes, wanting some other language in the browser is a very common wish on hacker news. It's just completely and utterly impractical in real life.
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.
And rightly so. Being locked into a store worries me much, much less than being locked into using JS and HTML.