5 ms·

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 exe

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.

untog 13y ago
> 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.
- hcarvalhoalves 13y ago
  > Well, Android does it. With the difference it uses a proper language designed to run on a VM in the first place - which is not the case with Javascript.
  - tracker1 13y ago
    I guess you missed that whole part of the article that discusses similar issues with GC and memory management with Android apps.
- potatolicious 13y ago
  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.
  - zanny 13y ago
    My linux kernel has a url. file:/boot/vmlinuz-linux So does my init daemon! file:/sbin/init Which is a symlink, so let's just specify a familiar program, and just throw on the proper file extension. file:/usr/bin/firefox.elf Still a url. To a program. If your executor supported file URIs you could run that. I could host it on an http server, and if I mounted it using webdav as a davfs2, I could access anything on that server the same way. You could write a python interpreter that can take a url to a python script to run: pythor http://github.com/some_repo/foo/script.py http://github.com/some_repo/foo/script.py 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?
    - potatolicious 13y ago
      Not everything being a resource, for one, and not everything being naturally represented in a URI. It's possible to encode just about any information in a URI, it doesn't mean it isn't a kludge and a force-fit. Take a very, very simple (and common) use case: https://maps.google.com/maps?q=Newark+International+Airport,+Brewster+Road,+Newark,+NJ&hl=en&sll=40.697488,-73.979681&sspn=0.940177,1.685028&oq=newark+li&hq=Newark+International+Airport,+Brewster+Road,+Newark,+NJ&t=m&z=14 https://maps.google.com/maps?q=Newark+International+Airport,... 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. Even better example: https://maps.google.com/maps?q=restaurants+around+Times+Square,+Broadway,+New+York,+NY&hl=en&sll=40.691572,-74.10347&sspn=0.235066,0.421257&oq=restaurants+around+times+square&hq=restaurants&hnear=Broadway,+New+York&t=m&z=16 https://maps.google.com/maps?q=restaurants+around+Times+Squa... 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.
- coldtea 13y ago
  >Well, Android does it. 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.
williamcotton 13y ago
What is broken about the security model?
- hcarvalhoalves 13y ago
  It's easier to ask what is not broken. Check this presentation: http://www.slideshare.net/jgrahamc/javascript-security-2064979 http://www.slideshare.net/jgrahamc/javascript-security-20649...
  - myko 13y ago
    Interesting, any idea how that applies to something like Dart, when Dart is running in the Dartium (i.e., not compiled to JS)?
    - Ygg2 13y ago
      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.
      - myko 13y ago
        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.
kgabis 13y ago
This should be getting more upvotes, not downvotes.
- Ygg2 13y ago
  Saying things like Moore law stopped gets a downvote from me. Moore law will stop, but it's not there yet. NOTE: Moore's law is concerned with number of transistors on a chip. That number has climbed, it's just split into several cores.
  - coldtea 13y ago
    >NOTE: Moore's law is concerned with number of transistors on a chip. That number has climbed, it's just split into several cores. We don't care about the pedantic interpretation of Moore law. We care about the mis-interpreation, that was a corellary of having single-core chips: that every 18 months computers got roughly twice as fast. This -- and this was the important attribute of Moore's law -- has stopped.
    - Ygg2 13y ago
      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.
      - coldtea 13y ago
        >Who's we? You and author/OP? Most people quoting Moore's law. That the misconception is more popular than his original statement, speaks for that.
        Ygg2 13y ago
        Yeah, marketing is a pita. It still doesn't negate the fact that even the corollary has slowed down, not stopped.

untog 13y ago

> 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.

hcarvalhoalves 13y ago
> Well, Android does it. With the difference it uses a proper language designed to run on a VM in the first place - which is not the case with Javascript.
- tracker1 13y ago
  I guess you missed that whole part of the article that discusses similar issues with GC and memory management with Android apps.
potatolicious 13y ago
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.
- zanny 13y ago
  My linux kernel has a url. file:/boot/vmlinuz-linux So does my init daemon! file:/sbin/init Which is a symlink, so let's just specify a familiar program, and just throw on the proper file extension. file:/usr/bin/firefox.elf Still a url. To a program. If your executor supported file URIs you could run that. I could host it on an http server, and if I mounted it using webdav as a davfs2, I could access anything on that server the same way. You could write a python interpreter that can take a url to a python script to run: pythor http://github.com/some_repo/foo/script.py http://github.com/some_repo/foo/script.py 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?
  - potatolicious 13y ago
    Not everything being a resource, for one, and not everything being naturally represented in a URI. It's possible to encode just about any information in a URI, it doesn't mean it isn't a kludge and a force-fit. Take a very, very simple (and common) use case: https://maps.google.com/maps?q=Newark+International+Airport,+Brewster+Road,+Newark,+NJ&hl=en&sll=40.697488,-73.979681&sspn=0.940177,1.685028&oq=newark+li&hq=Newark+International+Airport,+Brewster+Road,+Newark,+NJ&t=m&z=14 https://maps.google.com/maps?q=Newark+International+Airport,... 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. Even better example: https://maps.google.com/maps?q=restaurants+around+Times+Square,+Broadway,+New+York,+NY&hl=en&sll=40.691572,-74.10347&sspn=0.235066,0.421257&oq=restaurants+around+times+square&hq=restaurants&hnear=Broadway,+New+York&t=m&z=16 https://maps.google.com/maps?q=restaurants+around+Times+Squa... 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.
coldtea 13y ago
>Well, Android does it. 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.

williamcotton 13y ago

What is broken about the security model?

hcarvalhoalves 13y ago
It's easier to ask what is not broken. Check this presentation: http://www.slideshare.net/jgrahamc/javascript-security-2064979 http://www.slideshare.net/jgrahamc/javascript-security-20649...
- myko 13y ago
  Interesting, any idea how that applies to something like Dart, when Dart is running in the Dartium (i.e., not compiled to JS)?
  - Ygg2 13y ago
    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.
    - myko 13y ago
      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.

kgabis 13y ago

This should be getting more upvotes, not downvotes.

Ygg2 13y ago
Saying things like Moore law stopped gets a downvote from me. Moore law will stop, but it's not there yet. NOTE: Moore's law is concerned with number of transistors on a chip. That number has climbed, it's just split into several cores.
- coldtea 13y ago
  >NOTE: Moore's law is concerned with number of transistors on a chip. That number has climbed, it's just split into several cores. We don't care about the pedantic interpretation of Moore law. We care about the mis-interpreation, that was a corellary of having single-core chips: that every 18 months computers got roughly twice as fast. This -- and this was the important attribute of Moore's law -- has stopped.
  - Ygg2 13y ago
    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.
    - coldtea 13y ago
      >Who's we? You and author/OP? Most people quoting Moore's law. That the misconception is more popular than his original statement, speaks for that.
      - Ygg2 13y ago
        Yeah, marketing is a pita. It still doesn't negate the fact that even the corollary has slowed down, not stopped.