91–100 of 100 posts
Earlier quoted context omitted.
And it looks like that in the future we will have something like JVM and its classloaders. Just with different names (LLVM? v8? RequireJS? JS AMD?) and a lot more kludges. And without Gosling, Joy and Steele.
In the future JS-ASICs will define what you can do in the web. People will complain "123JS ASIC is the new IE6".
Compiling to Javascript is nothing short of a mental illness. The perversions that the terrible design of the web has driven people to are simply breathtaking...
That's a silly position to take. It works quite well in practice, and is completely competitive with a "designed" VM bytecode.
Compiling to Javascript is nothing short of a mental illness. The perversions that the terrible design of the web has driven people to are simply breathtaking...
Nobody would compile to JavaScript if there was an analogous platform on the Web. There isn't one.
The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is. They want application functionality which is as easy to access as typing an easy to remember name in an address bar. The means of achieving this goal taken by developers have been convoluted in the extreme. Each step has its own 'reasonable argument' defending the decision made, but it still adds up to madness.
Earlier quoted context omitted.
I love the idea that we can make web apps just as successful as native apps, but the reality seems to be the opposite. Mobile web usage went from 20% to 14% according to flurry from 2013 to 2014. That trend could be reversed with a new movement towards the web, but it seems like it would take quite a trend reversal. We're stuck with apple- and google- based rent seeking platforms. http://www.flurry.com/bid/109749/App…
We need installable , offline web apps. They are working on it, but it is late. https://github.com/w3c/manifest (I should note that technically, AppCache + bookmarking provides installable web apps, but nobody seems to want to program with AppCache, and bookmarking doesn't really feel like installing an app, which it should.)
For example, we could package web apps in .apk/.jar package, so they can run like native apps without worrying about missing a resource during offline. JS engine can have more freedom optimizing the code and cache the result.
There is no need to install web app like Chrome Web Store does. All we need is bookmarking and implicit app cache (with smart caching policy). Most people don't use more than 100 apps on regular basis, so 1GB app cache is enough for most people. One major mistake with installable web apps like Chrome Web Store is they often come with security permissions, which defeats major value of web, security and privacy.
Offline can be done with smart API design. For example, browser can let web apps create cache files that sit next to cached .apk and share the same lifespan, then web apps can use sqlite to work with such files for storage. It is essentially the same model as Android/iOS native apps. All these can be done without any app install or security permission. The only risk would be you will lose data if an app is purged during offline, therefore it doesn't have chance to sync the state back to server. If you really about data loss, browser can support pinned apps, so they never get purged by caching policy. That pretty much solves the fundamental problem with web app model.
PS: the usability of JavaScript, web APIs and performance are separate issues. That would also need to solved.
Earlier quoted context omitted.
AppCache sucks . It's completely broken. At least we have the Service Workers spec[0] coming soon, though, which should solve the problem. [0] https://github.com/slightlyoff/ServiceWorker/
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap cer…
Earlier quoted context omitted.
That's a silly position to take. It works quite well in practice, and is completely competitive with a "designed" VM bytecode.
It works well in practice depending entirely upon your goals - and depending entirely on your never ever comparing it to ANY other possible solution to the problem.
As an outsider, it sure doesn't seem to be getting as much traction as asm.js or have compelling advantages, though.
I think developers have a tendency to underestimate how important it is to integrate well with your environment, start up quickly, and have a good deployment story. asm.js nails these things.
Earlier quoted context omitted.
Nobody would compile to JavaScript if there was an analogous platform on the Web. There isn't one.
You are entirely correct on both counts. The fact that we have been driven to madness by the horrible design of the web does not, in any way, mean that it's not still madness to do it. The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is. They want application functionality which is as easy to access as typing an easy to remember name in an address bar. The means of ach…
I wouldn't characterize it as such. The reality is, we are pretty effin lucky the Web turned out the way it did. It does it what it does very well. I mean we have an open platform that every major tech company is on-board with, that isn't controlled, wholly, by any single one of them, a platform that works on almost every capable device out there. Those same companies cannot agree on anything else and are openly hostile to each other in every other space, except this one. It could have been worse. And future versions of JavaScript are looking pretty good too!
I'd prefer that HTML/CSS was better designed for building web-applications (right now it's a Frankenstein that doesn't know whether it wants to be a UI toolkit or markup for text). I'd prefer a language like Dart or Python to power web-pages, instead of JavaScript. But oh well.
>The ultimate goal is to deliver functionality to users. Users don't give a damn what the platform is.
And that's part of the reason why JavaScript sticks around. Users don't care, and you can get far with JavaScript.
Wouldn't it make more sense to market it as llvm-ir-to-javascript compiler? That way it would be more attractive to users of any language with a llvm frontend.
Earlier quoted context omitted.
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap cer…
The cheapest certs I've found are from https://www.gogetssl.com/domain-validation/comodo-positive-s... but the wildcards are still pretty expensive. I can't recommend them though as I haven't bought one yet.
Heer you can find Comodo PositiveSSL Wildcard at $58.36/Year.
Earlier quoted context omitted.
To prevent MITM attacks, Service Workers _require_ HTTPS. HTTPS isn't as accessible as unencrypted HTTP and self signed certs trigger user scarring warning messages. I do think HTTPS is better for privacy to an extent, but unless people can get signed certs for cheaper than their domain name, part of me feels like were only allowing additional web functionality for those able to afford SSL certs. Of course, cheap cer…
The cheapest certs I've found are from https://www.gogetssl.com/domain-validation/comodo-positive-s... but the wildcards are still pretty expensive. I can't recommend them though as I haven't bought one yet.