The trend towards retrofitting interactive applications to run inside the equivalent of a VM is just stupid, not only because of the obvious wastefulness of executing JS (given Moore's Law stopped).
When dealing with a browser, you're limited to a broken interaction model (document? URL? back button?), a broken security model, one programming language with a weak API (that isn't equally supported between browsers either), and you have to abuse HTML into things it's not supposed to. It's a development experience that is subpar even by 90's standards.
Add all that to the pedestrian performance, and I'm amazed this is still an option.
> The trend towards retrofitting interactive applications to run inside the equivalent of a VM is just stupid
Well, Android does it.
And in all honesty, when apps start getting complex they're just as bad. There's a reason URLs exist- it's to give a unique identifier to an item. Apps need to do that too, and end up having to fudge around launching and reaching a specific item.
Apps have URLs also - even iOS, which is the weakest link in terms of inter-app interaction, has them.
The difference here is that one platform requires shoehorning a URL into a non-document-centric use case, and the other one leaves it optional, for the developer to implement as he/she sees fit.
If I'm using the Yelp app, I expect to be able to communicate a restaurant listing to someone else via a URL. But why is it that my alarm clock needs a URL? Or my phone dialer?
The web was envisioned as interlinked documents, and for many parts of the web this is still very much the case (see: Amazon). For others this metaphor breaks down badly, and is the source of a great deal if hacks and kludges.
A lot of programs already use URIs - I know KDE dolphin specifies all resource paths as URLs regardless of if they are local or remote, and it supports a buttload of URI schema. The qt5 QML engine specifies qml files to load by URI, so you can load remote qml applications in a browser that links in the qml runtime.
I mean, we even have this nice syntax (that isn't pervasive or transparent) to supply arguments in a url with something like google.com/search?q=bacon which in bash-world would be google --query bacon or google -q=bacon.
So what is missing from URLs from being uniform resource locators?
Holy God would you look at that URL. It doesn't refer to a resource. In fact it refers to application state. This is a gross abuse of the whole concept of a URL, but the folks at Google aren't idiots - they know this. But the fact of the matter is that Google Maps is not document-based, and people have legitimate need to transport application state, independent of the semantics of the information they're looking for. Even something as simple as showing my friend the same map I'm looking at so we can talk about it requires bending the role of URIs wildly out of shape.
One can argue that the previous link was clearly a reference to the airport, and there can be a URI for it (which wouldn't transport application state, substantially hobbling its use, but whatever). This link refers to "restaurants around Times Square", which isn't a logical entity, and whose relevance to the end user depends entirely on the application state being transported (e.g., zoom level, center point, filtered results, etc).
Every time these insane-o URLs get brought up the URI-acolytes seem to end up suggesting that maybe we shouldn't have rich, interactive maps or such things, that we should force software into roles that play nicely with the document-centric, URI-friendly schemes. I for one believe that software serves users first, and methods to locate and specify information needs to adopt its users needs, not the other way around.
> Even something as simple as showing my friend the same map I'm looking at so we can talk about it requires bending the role of URIs wildly out of shape.
How so? That 'same map' _is_ the resource being uniformly indicated.
> This link refers to "restaurants around Times Square", which isn't a logical entity
Why not? It's a logical entity, which is a collection viewed a certain way.
And that's why it has subpar apps compared to iOS when it comes to anything CPU intensive, high latency that makes it unsuitable for realtime audio/video apps, and you can see core Android engineers debating about why it's slow and such. And for games, devs have to fight the GC and implement stuff manually without allocations to work around it.
So sure, it can run twitter clients and all kinds of everyday apps and web front-end apps quite OK. But for heavy CPU / realtime stuff that get us forward to novel use cases, not so much.
> NOTE: Moore's law is concerned with number of transistors on a chip. That number has climbed, it's just split into several cores.
Exactly, so now Moore's law is working against JavaScript, since JS doesn't do threading. So let's assume JS somehow magically gets to be ~2x slower than native instead of ~4x slower. With the standard being quad cores now, that makes JS ~8x slower than native doing image processing - you know, that whole "instagram" thing that's insanely popular on smartphones. And during that ~8x longer it's spending processing that image, your UI is completely frozen and unresponsive.
Yes I know about WebWorkers, but WebWorkers are hideously inefficient & slow by design. The limitations with them are also absurd, it is not a substitute for threading. The world is better off forgetting that they exist - which it basically has.
Who's we? You and author/OP? Because I've got good news for you, Moore's law corollary has merely slowed, not stopped. It will stop, just not now.
I think Moore's law will work better on mobiles, because they are retreading known grounds and they are way further from reaching, real physical barriers than regular computers.
Dart doesn't exist in a mainstream browser yet. My guess, that some of those problems probably persist in Dart or maybe new, unforeseen ones are introduced.
Right, which is why I asked about Dartium (build of Chromium with DartVM built in). But yeah I guess only people really involved with Dart could answer this question properly.
When dealing with a browser, you're limited to a broken interaction model (document? URL? back button?), a broken security model, one programming language with a weak API (that isn't equally supported between browsers either), and you have to abuse HTML into things it's not supposed to. It's a development experience that is subpar even by 90's standards.
Add all that to the pedestrian performance, and I'm amazed this is still an option.