5 ms·

Except with C++ instead of Java and the DOM instead of Java API's.

by bobajeff 11y ago

niccaluim 11y ago
That doesn't sound like an improvement.
- pmelendez 11y ago
  It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.
  - niccaluim 11y ago
    Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
    - RyanZAG 11y ago
      At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.
- coldtea 11y ago
  Well, considering it was: - isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year) it does sound as a great improvement. Except in case you weren't there and can't remember.
  - niccaluim 11y ago
    I was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.
    - jacobolus 11y ago
      Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target. I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.
    - dikaiosune 11y ago
      Rust in the browser?
toyg 11y ago
Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."
- pmelendez 11y ago
  Not sure why you think a GC is a good thing. Deterministic object disposal is to me way more convenient and safe than a GC (haven't you ever experienced a race when the GC dispose your memory too soon or not soon enough?)
  - mrec 11y ago
    If you're hitting race conditions based on when GC runs, I'm pretty sure you're doing it wrong. Java does deterministic destruction of resource-holding objects via try-with-resources, not GC.
  - pinealservo 11y ago
    There are definitely reasons for manual memory management to still be a thing, but if a GC disposes of memory "too soon", i.e. when there are still live references to the memory, then it is a bug in the GC or in some FFI code that didn't manage interaction with the GC correctly. GC is generally a good thing precisely because it prevents use-after-free errors and enables programming at a higher level without worrying about memory management. There is often a performance cost to this, it's true, but for large classes of programs it's a cost that's worth paying.
  - pjmlp 11y ago
    Deterministic object disposal is quite easy to do in GC languages, provided they support higer order functions. It is no different than imposing a programming pattern like RAII.

Except with C++ instead of Java and the DOM instead of Java API's.

niccaluim 11y ago

That doesn't sound like an improvement.

pmelendez 11y ago
It is actually... It is going straight to native and built in on the browser instead of a call to a plugin and then a VM and finally to native.
- niccaluim 11y ago
  Java runtimes generate machine code just like V8 does, and there's no functional difference between "built-in" code and a plugin. A plugin is just a shared library.
  - RyanZAG 11y ago
    At the time Java was being used in browsers, it had a lot of problems with that machine code generation. It took a long time for the JIT to kick in. The JITed x86 code it produced was poor. The startup time to load in the various libraries required by the applet tech was incredibly slow. It only started downloading the actual java code to run after the applet itself had finished loading everything. And more issues. There problems were never truly about the idea being bad: it was the implementation that was terrible and was hindered even further by the Sun-Microsoft lawsuits, etc. If everyone is on board with a technology and work to make it usable instead of 'feature complete', then it is very easy to make this work where Java applets failed. It's actually easy to make Java applets work where Java applets failed if you were to re-implement the idea with the correct focus and buy-in. It's not technology - it is politics.
coldtea 11y ago
Well, considering it was: - isolated (outside of DOM) - non standard (not everywhere) - third party (proprietary) - alien (uncanny value of different UI style) - bloated (even compared to the web stack, Spring was an over-engineered badly designed mess of a GUI API) - insecure (full of exploits to this very day, tons of them closed just last year) it does sound as a great improvement. Except in case you weren't there and can't remember.
- niccaluim 11y ago
  I was very much there, and I'd sooner eat my cat than go back to that era of Java. But C++? Is that really the best we can do? Everyone's so afraid of breaking backwards compatibility but I don't see any other way out of the never-ending accretion of hacks Eich left us with.
  - jacobolus 11y ago
    Not C++ per se, but anything that can compile to WebAssembly, which should right away include anything with an LLVM toolchain, and should down the line include any compiled language for which someone puts the work in to add WebAssembly as a compile target. I’m also hoping it winds up being friendly enough to hand write WebAssembly for small chunks of numerical code. With asm.js, that’s currently kind of a pain.
  - dikaiosune 11y ago
    Rust in the browser?

toyg 11y ago

Not sure if serious... This comment translates to "except without garbage-collection, and with a loose set of inconsistent and constantly-changing interfaces instead of One Sanctioned Spec."

pmelendez 11y ago
Not sure why you think a GC is a good thing. Deterministic object disposal is to me way more convenient and safe than a GC (haven't you ever experienced a race when the GC dispose your memory too soon or not soon enough?)
- mrec 11y ago
  If you're hitting race conditions based on when GC runs, I'm pretty sure you're doing it wrong. Java does deterministic destruction of resource-holding objects via try-with-resources, not GC.
- pinealservo 11y ago
  There are definitely reasons for manual memory management to still be a thing, but if a GC disposes of memory "too soon", i.e. when there are still live references to the memory, then it is a bug in the GC or in some FFI code that didn't manage interaction with the GC correctly. GC is generally a good thing precisely because it prevents use-after-free errors and enables programming at a higher level without worrying about memory management. There is often a performance cost to this, it's true, but for large classes of programs it's a cost that's worth paying.
- pjmlp 11y ago
  Deterministic object disposal is quite easy to do in GC languages, provided they support higer order functions. It is no different than imposing a programming pattern like RAII.