Hacker News Reader

Comment by bobajeff | Hacker News Reader

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

That doesn't sound like an improvement.

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.

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.

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.

Rust in the browser?

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.

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.

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.

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

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?)

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.

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.

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.

Reply on news.ycombinator.com