6 ms·

I think this is shortsighted. In 5-10 years browsers will be more Virtual Machine than Web Browser. You can almost argue that they already are. As browsers a

by rco8786 11y ago

I think this is shortsighted. In 5-10 years browsers will be more Virtual Machine than Web Browser. You can almost argue that they already are. As browsers and phones get more and more performant, the idea of emulating native apps in the browser won't have the performance stigma attached to it. This same thing played out with Java et. al. It was dismissed for being non-performant when compared to C/C++(aka native code) because it ran inside a heavy VM but nowadays the performance is just fine for an enormous amount of applications because the virtual machines and hardware got faster.

VLM 11y ago
Probably will be more like a URL link aware VNC viewer. That has some interesting implications for the back end WRT emulation.
JustSomeNobody 11y ago
Oh, so a dumb terminal. Ok. It's 1980 again.
- Klathmon 11y ago
  If it can do everything the user wants then what is the issue? Just because it's been done before it's the wrong answer?
  - JustSomeNobody 11y ago
    My reply was a bit ambiguous and snarky. I don't believe it's the wrong answer if it works. But people are commenting about moving the web forward to run apps in browsers and all and so there are parallels with what we did in the 80's. That's really what I was getting at. Nothing in computing is ever really new.
    - jmagoon 11y ago
      We're replacing a very nice custom SCO Unix backend developed at my work from 1980s onward (drops users into custom shell, multiple programs execute in the user context, leverages all the nice features of *nix) with a purchased desktop Windows ERP application and it makes me so sad. Literally we will move from having 1 to 2 admin who can manage 300 users, decades of automation, and totally instantaneous program execution (in C) with heavy user load on a single server to distributed, client based programs running on separate machines that all have to be patched, updated, troubleshot, etc.--(and the 5 person support team that has to go with it), communicating with a central program server and separate DB servers, etc.,etc., all because the console application is "too old looking".
      - tracker1 11y ago
        A web based application could have a very similar backend, and you could run pretty much any modern OS client on the front end... Though I think the development and training for your new front end will be a bit cumbersome no matter what you use.
- cwbrandsma 11y ago
  1. Dumb terminals never really left us. They are in active use all over. 2. The current web trend is using more of the browser CPU, as opposed to the server CPU. Heck, I have entire apps that don't call the server after load at all. I don't remember being able to execute code in a dumb terminal (possibly you could...I just don't remember it). Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.
teacup50 11y ago
The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applications because: 1) The long load time / hotspot JIT overhead when starting applications. 2) The large memory overhead of the Sun/Oracle GC's reserved heap. To some degree, Dalvik solved some of these issues, but has also retained the (very necessary) escape-hatch-to-native JNI. JavaScript is SO MUCH HARDER to optimize than JVM bytecode. Whereas you can even feasible AOT-compile JVM code, JavaScript's dynamism makes this all but impossible. On top of that, JS is welded to the DOM and CSS, the combination of which incurs huge rendering pipeline CPU and memory overhead for anyone doing anything as complicated as a "native" UI view hierarchy. Rather than enumerate all the failures, I'll note that it's not all doom and gloom. We've got a web bytecode in the works that's much saner than JS. Canvas and WebGL exist. Progress on those fronts may create a situation like you're describing, but -- and this is no great loss in my book -- it won't be the web.
- jebblue 11y ago
  Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.
  - kuschku 11y ago
    Yes, recently, Java actually became usable for a lot of seemingly native apps. And it does this a lot better than the browser.
  - teacup50 11y ago
    (non-casual) Games aren't generally known for fast load time, sharing resources on a multitasking system, or short playing sessions -- all of which plays to the JVM's strengths (or avoids its weaknesses). As far as fast load time; just launching my (JVM-based) build tool (sbt) takes 7 seconds on my laptop. Running 'Hello World' from an uncompressed class file takes 0.12s, and most software is quite a bit larger than a couple lines of bytecode in an single uncompressed class file. The C version, by comparison, completes in 0.005s.
- 11y ago
jeena 11y ago
But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons. I would rather see something like Ubuntu Touch tries where they write the frontend with QML and you can have backends in C++ for speed.
- marcosdumay 11y ago
  > But the only languages available are HTML, CSS and JavaScript... Eh, there is the canvas, and WebAsm. They make for a full blown VM if you don't mind shipping a several MB large interpreter with your page. Next step should be installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again. (Now, if somebody gets a way to do that full VM thing in a way that is compatible with the DOM, then we'll have some improvement.)
  - hodwik 11y ago
    >"Web ASM [...] installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again." That's ridiculous. Is Javascript "like flash" because most browsers ship a several MB interpreter for it?
    - marcosdumay 11y ago
      Javascript creating random elements on the canvas? Yep, just like flash.
- rpedela 11y ago
  > But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons. I would have completely agreed with that a few months ago. HTML/CSS/JS is fine for most websites which are primarily text, images, and a couple buttons. But it breaks down quickly when trying to build an application. Then React was invented. I don't know if React will be the thing people use to build web applications in the future, but I think the concepts it introduced will be. The reason is because React provides a foundation that makes it feel more like building a desktop UI or video game than building a traditional website. Performance will improve over time with faster hardware, faster networks, and software optimizations. Javascript V8 is already one of the fastest scripting languages especially for string handling.
Excavator 11y ago
You might be interested in the in the works WebAssembly, if you haven't heard of it already. https://blog.mozilla.org/luke/2015/06/17/webassembly/ https://blog.mozilla.org/luke/2015/06/17/webassembly/

by rco8786 11y ago

VLM 11y ago

Probably will be more like a URL link aware VNC viewer. That has some interesting implications for the back end WRT emulation.

JustSomeNobody 11y ago

Oh, so a dumb terminal. Ok. It's 1980 again.

Klathmon 11y ago
If it can do everything the user wants then what is the issue? Just because it's been done before it's the wrong answer?
- JustSomeNobody 11y ago
  My reply was a bit ambiguous and snarky. I don't believe it's the wrong answer if it works. But people are commenting about moving the web forward to run apps in browsers and all and so there are parallels with what we did in the 80's. That's really what I was getting at. Nothing in computing is ever really new.
  - jmagoon 11y ago
    We're replacing a very nice custom SCO Unix backend developed at my work from 1980s onward (drops users into custom shell, multiple programs execute in the user context, leverages all the nice features of *nix) with a purchased desktop Windows ERP application and it makes me so sad. Literally we will move from having 1 to 2 admin who can manage 300 users, decades of automation, and totally instantaneous program execution (in C) with heavy user load on a single server to distributed, client based programs running on separate machines that all have to be patched, updated, troubleshot, etc.--(and the 5 person support team that has to go with it), communicating with a central program server and separate DB servers, etc.,etc., all because the console application is "too old looking".
    - tracker1 11y ago
      A web based application could have a very similar backend, and you could run pretty much any modern OS client on the front end... Though I think the development and training for your new front end will be a bit cumbersome no matter what you use.
cwbrandsma 11y ago
1. Dumb terminals never really left us. They are in active use all over. 2. The current web trend is using more of the browser CPU, as opposed to the server CPU. Heck, I have entire apps that don't call the server after load at all. I don't remember being able to execute code in a dumb terminal (possibly you could...I just don't remember it). Dang it, now I'm nostalgic for playing MUDs on a VT1000 in the 90s.

teacup50 11y ago

The JVM itself got faster -- and in many places, relies on native code for particularly expensive functionality -- but it's still unusable for end-user applications because: 1) The long load time / hotspot JIT overhead when starting applications. 2) The large memory overhead of the Sun/Oracle GC's reserved heap. To some degree, Dalvik solved some of these issues, but has also retained the (very necessary) escape-hatch-to-native JNI. JavaScript is SO MUCH HARDER to optimize than JVM bytecode. Whereas you can even feasible AOT-compile JVM code, JavaScript's dynamism makes this all but impossible. On top of that, JS is welded to the DOM and CSS, the combination of which incurs huge rendering pipeline CPU and memory overhead for anyone doing anything as complicated as a "native" UI view hierarchy. Rather than enumerate all the failures, I'll note that it's not all doom and gloom. We've got a web bytecode in the works that's much saner than JS. Canvas and WebGL exist. Progress on those fronts may create a situation like you're describing, but -- and this is no great loss in my book -- it won't be the web.

jebblue 11y ago
Minecraft alone shows your first two points are not valid. Write a hello world app in Java, the startup time is miliseconds, the memory is not humongous.
- kuschku 11y ago
  Yes, recently, Java actually became usable for a lot of seemingly native apps. And it does this a lot better than the browser.
- teacup50 11y ago
  (non-casual) Games aren't generally known for fast load time, sharing resources on a multitasking system, or short playing sessions -- all of which plays to the JVM's strengths (or avoids its weaknesses). As far as fast load time; just launching my (JVM-based) build tool (sbt) takes 7 seconds on my laptop. Running 'Hello World' from an uncompressed class file takes 0.12s, and most software is quite a bit larger than a couple lines of bytecode in an single uncompressed class file. The C version, by comparison, completes in 0.005s.
11y ago

jeena 11y ago

But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons. I would rather see something like Ubuntu Touch tries where they write the frontend with QML and you can have backends in C++ for speed.

marcosdumay 11y ago
> But the only languages available are HTML, CSS and JavaScript... Eh, there is the canvas, and WebAsm. They make for a full blown VM if you don't mind shipping a several MB large interpreter with your page. Next step should be installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again. (Now, if somebody gets a way to do that full VM thing in a way that is compatible with the DOM, then we'll have some improvement.)
- hodwik 11y ago
  >"Web ASM [...] installing the interpreter on the browser, for everybody to use... Then we can create Flash all over again." That's ridiculous. Is Javascript "like flash" because most browsers ship a several MB interpreter for it?
  - marcosdumay 11y ago
    Javascript creating random elements on the canvas? Yep, just like flash.
rpedela 11y ago
> But the only languages available are HTML, CSS and JavaScript which are just more than bad for application development because of so many reasons. I would have completely agreed with that a few months ago. HTML/CSS/JS is fine for most websites which are primarily text, images, and a couple buttons. But it breaks down quickly when trying to build an application. Then React was invented. I don't know if React will be the thing people use to build web applications in the future, but I think the concepts it introduced will be. The reason is because React provides a foundation that makes it feel more like building a desktop UI or video game than building a traditional website. Performance will improve over time with faster hardware, faster networks, and software optimizations. Javascript V8 is already one of the fastest scripting languages especially for string handling.

Excavator 11y ago

You might be interested in the in the works WebAssembly, if you haven't heard of it already. https://blog.mozilla.org/luke/2015/06/17/webassembly/ https://blog.mozilla.org/luke/2015/06/17/webassembly/