Hacker News Reader

Comment by neilv | Hacker News Reader

No slight against WASM (which I've promoted), but early Java people would be well-advised to sit down somewhere they can sob in privacy, before reading this article:

> ...you can't run Java code in a browser without a plugin...

> ...WASM, being memory safe and tuned for validation, also has security advantages over Java applets...

> ...explained the difference between WebAssembly and Java thus: "WebAssembly has been designed to scale from tiny devices to large server farms or CDNs...

> ..."That's how important it is. WebAssembly on the server is the future of computing. A standardized system interface was the missing link...

> ...But a write-once, run anywhere binary represents a worthwhile effort...

View on HN

>"WebAssembly has been designed to scale from tiny devices to large server farms or CDNs..."

What's ironic is that the "tiny devices" and even "high end professional desktop workstation and server devices" that Java was originally designed to run on when it was started in 1990 were MUCH tinier than the devices considered "tiny" today.

How many more times faster is a typical smartphone today (Raspberry Pi 3: 2,451 MIPS, ARM Cortex A73: 71,120 MIPS) that a 1990 SparcStation 2 pizzabox (28.5 MIPS, $15,000-$27,000)?

http://www.wikiwand.com/en/Instructions_per_second

Forget full computers, an official Java subset even runs on every GSM SIM card. It is incredible!

https://en.m.wikipedia.org/wiki/Java_Card

People keep bringing this up but Java Card is a really small subset of Java so you can't draw any conclusions. In particular it has no garbage collection, which is easily the heaviest part of Java.

> Many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).

To add on, here's a quick intro to the headache that goes into writing Java for GSM cards - https://youtu.be/31D94QOo2gY?t=607

But writing Javacard for ICCs is like writing another language and ecosystem entirely. The syntax is familiar but there the comparison kind of ends.

I am not surprised. As someone who cut his programming teeth on Java and .Net, modern web development feels really out of touch with reality.

I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel.

It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.

.NET ecosystem is fantastic right now. .NET Core is fast and efficient, asp.net is better, faster and more full-featured than ever, and MS is ahead of everyone with Blazor Components that finally provide a real alternative to JS frontend frameworks and can run either server-side or as WASM modules.

I agree largely from a development perspective, but the client-side javascript frameworks are ultimately more performant, particularly on mobile, and are not as bad as they used to be. Neither server-side nor WASM are ideal for mobile devices. Downloading many megabytes of .NET dependencies for a WASM app is obscene compared to like 30 kilobytes for React.

With 5g that won't be an issue anymore...

In 2026 maybe...

Until they decide that 5g is good enough to allow them to ship the browser with every website. Net speeds have been increasing every year and yet the websites take longer to load.

> “30 kilobytes for React” This is just not even close to being true.

There's 3kb Preact with almost identical API.

So what's the other 27KB+ for?

Fiber, support fo async rendering, suspense, hooks. A different VDOM algorithm.

Better error handling and messaging...

The compressed size is 31 kb, and other frameworks are smaller.

https://gist.github.com/Restuta/cda69e50a853aa64912d

It won't be megabytes, that's only in the experimental phase. Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

As far as performant, I agree it wont matter in most trivial interactions but large datasets with computations already see an impact (for example we have million row datatables to show sometimes).

> Binaries can shrink dramatically once run through a linker and trimmed down to only used APIs.

It's worth pointing out that .NET Core has an assembly/executable generator that can package only the .NET libraries that are actually used.

Rust-based WASM front-end libraries will likely be small and also high performance. Unfortunately, all of the existing ones are highly experimental right now.

IMO, server-side Blazor is a non-starter, basically just a proof-of-concept to get something up and running before the WASM version is usable, but definitely not something I would use in production.

Why not? Works fine in our tests, and a large part of .NET apps are internal apps that work great with this kind of framework.

I think the biggest issue is sending every interaction over the wire but there are ideas to separate the event handling or even split which components run server vs client-side. That would allow highly responsive inputs with no lag while the parent component can run all its logic on the server.

I mean, sure, if you have tens of internal users maybe (but then it could be argued that it could just as well be deployed as a desktop app -- I could buy the deployment method as an argument, mind you). But thousands? Call me sceptical. It just makes me think of `asp:UpdatePanel` all over again.

Are you referring to the session state and websockets connections? Both scale horizontally with minimal effort, I don't see the problem.

Asp:UpdatePanel was great for it's time, and no different than doing an XHR request now and replacing the contents of a div with the response. You can still get basically the same effect with libraries like Turbolinks which is what Github does.

MS and Oracle claimed copyrightability of APIs. Think about that. It surely didn't help accepting .NET and Java as worthwhile universal tools. Too bad for them. Good thing WASM avoided this pitfall.

>I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel. It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.

I think it might have to do with people considering 40 as very old in Silicon Valley and those in their late 20s and early 30s have barely learned this lesson.

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective?

I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old analog instrument and there's generally wonder and curiosity. Show a computer science class a slide with a 1 MB hard drive compared to an 1TB SD card and there's generally ridicule and laughter. "Look how stupid they've been", not "we've learned many valuable lessons since".

> Do computer science curricula not include enough historical perspective?

Anecdotally speaking, the average web developer does not have any formal computer science education. Most are self taught or attend a bootcamp or two at most. They have excellent vocational skills, but little knowledge of anything in computing outside of their narrow path of learning.

People who develop webassembly are not your average web developers

Oh man, this is so true. An acquaintance of mine who had recently graduated a bootcamp was crowing about how much he knows. I asked him for the big-O performance of adding an item to a linked list. He looked at me like I was speaking Martian.

And a lot of times, these are the people writing confidently on the internet about web development. Problem with programming is most of the people in the community are amateurs and they communicate via the internet. And on the internet, no one knows you are dumb.

I wonder the same thing. I suspect the age of the field plays a role. While theoretical computer science is about 200 years old practical computers only exist for 70 years and are widespread for about 40 years. Many professors teaching computer science today couldn't study computer science back in their days because it simply wasn't offered.

This has wide reaching effects, one of the more obvious ones being that 20 year old knowledge seems ancient to most.

I feel like the world of computer programming is caught in a very fast iteration of the old adage, "Those who cannot remember the past are condemned to repeat it." Which oddly, I was curious about that quote's origins, so I just went and looked it up. The full quote in context is:

"Progress, far from consisting in change, depends on retentiveness. When change is absolute there remains no being to improve and no direction is set for possible improvement: and when experience is not retained, infancy is perpetual. Those who cannot remember the past are condemned to repeat it." - George Santayana (1863 - 1952) [The Life of Reason (1905-1906) Vol. I, Reason in Common Sense]

This neatly dovetails with the thoughts that were floating in my head. This part, is the explanation I believe, for the current state of programming, "when experience is not retained, infancy is perpetual."

You realize that the people behind Web Assembly, for example Dan Gohman, are some of the foremost world experts in compilers who have worked for literally decades in the field?

I don't think that GP was talking about the people who actually made web assembly, but about those who hype it. I'd be surprised if the former were not full of awareness of and respect towards the technologies that came before.

Your appeal to authority notwithstanding, yes I do realize that. I was not referring to, nor condemning the authors of WebAssembly for their work. I was proposing an answer to the question above, about why it seems like a lot of software development is re-inventing the wheel.

In other fields of engineering no one would ever think of calling themselves engineer after a 6 months bootcamp training.

Sadly on several countries this is a thing, which also contributes to a low level of expectation, regarding the quality of delivered work.

My Informatics Engineering degree certainly did include historical perspective of previous languages, operating systems and hardware architectures.

It may surprise you that the people behind Web Assembly are largely senior compiler developers who have certainly been around the block. Dan Gohman has forgotten more about compilers and VMs than 99% of the commenters here will ever know.

Sorry that was just replying to my parents on Web Development. I assume anyone who is doing compiler and VM development would be very senior and on a whole different level of expertise.

> It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems.

I hear that often in regard of programming languages. But I see a lot of value in remixing a lot of existing ideas in a new package. A wheel can only be so round and its interaction with the road is quite simple, but tech is different. Systems have widely different requirements. Old implementations have shortcomings and a hard time fixing those, especially due to backwards compatibility of complex systems. I cannot imagine how hard is to remove null from an existing programming language, as C# is currently trying. At some point it's just easier to start from a clean slate.

Is all the effort worth it? I don't know. But I wouldn't want to imply they are just doing it because their out of touch with reality.

Applying the "reinventing the wheel" meme to scenarios like this kind of misses that wheels actually have been reinvented numerous times resulting in major advancements in wheel technology.

Reinventing the wheel takes a lot of effort to be worth doing, because it takes a lot of effort to improve foundational technology, but it is sometimes worth doing if you are going to put an appropriate level of resources into it.

With proper versioning, I don't see why even major features like that would be a problem.

Null removal is completely compile-time anyway so it's complicated to compile but relatively simple to implement as a language upgrade at a certain version, and in this case it's also opt-in.

1. is true

2. Yeah, I read that and was super confused. Literally that was one of the main point of the Java language itself, enforced by the JVM itself.

3. I think this is more a matter of expected level of abstraction, but I agree this is fairly weak.

4. This just seems like standard "the new thing is vastly superior to the old thing", with a valid touch of "the JVM is too heavily abstracted from how computers work"

5. Yeah, this was also weird.

I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s.

Java was the solution that would provide a robust, symmetric (server+client), secure, highly capable, and portable platform for complex web applications.

Early Java folk weep because Java failed so badly on the client, and something else is stepping in to do what Java could not.

Java has been quite successful on my client devices running on my pocket, TV and tablets.

Also on client devices running on my credit card, factory management client screens and couple of car infotainment systems.

And on client devices across many corporations still safe from Electron madness.

Java applets are how a depressingly large amount of CC processing happens.

(I think Java Card maybe? is responsible for CC handling in all the magic CC features in phones)

Sorry, which point were you referring to? (I recognize the article as bad, I'm just not sure which problem you're referring to :D )

I think the article author knows exactly what they're doing. "Write once, run anywhere" was literally Java's strapline.

Thank you for clarifying that.

Also, one thing less-known than that Java applets were in the popular Web browsers at one point (when JavaScript was said to be just a glue language to invoke the Java applet), was that Sun already had a richer, Java-centric Web browser, which used Java for content-type handlers. Imagine providing content as data of some type/format, and the browser would automatically download an appropriate UI for that type, on the fly, and integrate it into UI, and it would all be secure.

(I first saw Java when it was called Oak, and Sun had great people doing major things, Java only one of them. When Java applets first hit conventional Web browsers, most people thought they were for replacing animated GIFs, thanks to a demo program. I probably wrote some of the first Java desktop application code outside of Sun, partly to demonstrate that Java was a real applications development language. Well, the language was there, and in many ways a huge improvement over the C++ that most shrinkwrap and technical desktop application developers were moving to, though the library support took a while to catch up, and performance took longer.)

You mention it in your last sentence, but most of these tales forget to mention it at all: java was slow. I mean, slooooooooooooooow. And that reputation stuck for much longer than it was actually true. Java applets were an abomination and you wanted to repeatedly stab yourself in the head while using even a simple one. On a then-average p166 with 24mb of ram, your browser would go unresponsive while loading, jumpy mouse cursor, os starting to swap, and then some irregular annoying hangs while the GC did its thing. Not to mention how ugly awt and swing looked even back then.

Modern web is a joke regarding resource usage and complexity etc., but java was a shitshow in practice, except on beefy servers.

> On a then-average p166 with 24mb of ram, your browser would go unresponsive while loading, jumpy mouse cursor, os starting to swap, and then some irregular annoying hangs while the GC did its thing.

Reminds me of client-side JS frameworks. Or Electron apps.

> Not to mention how ugly awt and swing looked even back then.

Web UI is still as ugly as ever, of course. Peak UX usability was native UIs in the 1990s and early 2000s, after that it was nothing but steady decline.

> Reminds me of client-side JS frameworks. Or Electron apps.

Even big framework web apps on a core 2 duo running old Firefox, that is nowhere as bad as early Java trying to run something as a web applet.

I remember staring at that crazy Java applet load spinner and hating Java, and this was already in the early 2000s (on the first white iBook running Mac OS 9). It would have been much worse 7 years earlier.

It was really just the JVM’s startup time and the clunky AWT-based UI that made Java lose on web clients. Flash easily dethroned Java there because it started almost instantaneously and could do fancy animations (recall dial-up speeds meant video wasn’t an option).

Thanks for teaching me something totally unrelated on accident today. I was under the impression that all of the post-clamshell iBooks were OSX-only and had to check everymac. Now I'm slightly wiser on a topic that no one gives a shit about.

"Now I'm slightly wiser on a topic that no one gives a shit about." - I'm taking this quote and integrating it into my life.

Who is downvoting this?

>Peak UX usability was native UIs in the 1990s and early 2000s

So much this. Give me Win2K and Office2K style applications - multiple tiled or overlapping windows, modeless views, regular menus and toolbars, context sensitive right click menus, etc. over this single pane with a hamburger button and search box crap any day of the week.

I’d argue that Mac OS (9/X) hit peak usability in the mid to late 2000s, when they were still trying to dethrone Windows.

> I think what he means is that these were literally the same promises that were made about Java and the web back in the early 1990’s.

And as a whole (except for run in browser without plugin, which was never promised, AFAIR), they were all true or Java, relatively speaking, compared to what was available before.

I'm so often confused by these comments.

Are you saying that we could stick a JVM in the browser and ship Java applets around to be progressively/streaming loaded and executed in browser?

I don't know much about the JVM but it seems the goal of WASM and the JVM were quite different, no? And yes, WASI has overlap with JVM, but if WASM catches on and people like it, how does WASI make any less sense?

Are you advocating we have WASM and JVM but no WASI? Is that better? Not sure why anyone is crying here..

> Are you saying that we could stick a JVM in the browser

More or less. I mean, that used to be a thing you know.

> the goal of WASM and the JVM were quite different

WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

JVM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

> More or less. I mean, that used to be a thing you know.

I did not know Java applets can be stream loaded (ie, optimized for the web).

> WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

Not at all.. at least, not in my view. WASM is optimized for platform issues specific to the web. That is to say, how it behaves on load is the first priority.

I never got that impression from the JVM. If you say it is, then it seems to be a failure in marketing of the JVM or something.

Since you seem to feel WASM is a waste, what are your thoughts on the failure of the JVM? Ie, why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc?

If JVM truly does have all of these WASM-web oriented features then it is an impressive failure on JVMs part. Quite curious

> ...why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc?

The JVM is not a true VM. It's heavily coupled to the Java object model and the Java GC.

And yet so many posts here cry of history repeating itself and seem to imply we should just be using the JVM.

I'm honestly puzzled. Am I the one missing something? Why is the JVM crowd seemingly upset here?

> Why is the JVM crowd seemingly upset here?

Nobody is upset, really. Java web client lost a very long time ago to Flash.

But imagine, if 25 years ago you poured your heart and soul years ago into a project because it promised to be a particular kind of great (but later failed), it can sort of drive the knife deeper and throw extra salt in the wound when your project's ugly red-headed stepchild (i.e. JavaScript) grows up into something great and gives birth years later to a beautiful standard (asm.js, later WebAssembly) that becomes what your project thought it would be, and much more. Or something like that.

Java certainly has a well-established place in software, no doubt about that. But its original promises had it (combined with AWT/Swing, applets, and XML, ... umm yeah) becoming the ultimate "write once run everywhere" platform that could scale up to massive servers and down to tiny embedded chips, and every client platform in between. In retrospect, C# and .NET would have done well not to attempt to emulate Java's initial scope.

I'm not anti-WASM. Actually, I think it's pretty cool.

And I have no particular JVM love. I use it exceedingly rarely.

It's just that you're being kind of a frustrated, pedantic tool right now.

The only difference is that WASM will be available ( I assume ) in most PC Chrome Browser within 2 - 3 years of releasing, that is 800M+ assuming Chrome with stable market shares. Along with Android, that is a potential of 2-3B devices, assuming stable upgrade cycle and shipment.

That is more penetration than Java could ever get on Desktop and Mobile.

Although Java is actually doing ok in embedded space, I am not entirely sure how WASM would work for that segment.

> Android [...] assuming stable upgrade cycle and shipment

Good one.

Maybe my sarcasm detector is failing, but:

Java is the most used programming language in the world (https://www.tiobe.com/tiobe-index/)

It not only powers all kinds of desktop things, it is foundational to Android, which currently powers ~85% of all mobile devices.

How can you get more penetration than "most used programming language" and "foundational to the largest mobile OS"? I mean there isn't even a category that fully encompasses the degree of dominance of Java. The next step, I assume, would be to rename "Programming" (all of it) to "Java".

I should have use the word JVM rather than Java. My Apology.

From TFA:

>> Mozilla this week announced a project called WASI (WebAssembly System Interface) to standardize how WebAssembly code interacts with operating systems.

This is just another implementation of holes that allow web sites access to the rest of your system. It really is supposed to be the operating systems job to manage resources and what can be accessed. The problem is this functionality keeps getting re-implemented by others with different agendas.

I thought the point of WASI was to give you an API that allows you to bring your WebAssembly apps out of the browser and run on the OS itself, not to allow deeper integration of the app in a browser to the underlying OS.

Edit: words

> This is just another implementation of holes that allow web sites access to the rest of your system.

Well, unlike systems designed in the 90s, it's designed for the modern "everything-is-a-threat" mindset rather than the optimism of the 90s that everything would be safe.

What? No. WASI isn't meant to be implemented by the browser. It's meant for WASM runtimes outside of the browser, like Lucet and Wasmer.

People have been experimenting with "WASM outside the browser" for a while now, and WASI is just an API for making OS calls that a runtime can implement.

> WebAssembly has been designed to scale from tiny devices to large server farms or CDNs

Has it, though? What we have now is an MVP, and easily 90% of the features aren’t there yet.

When WASM gets garbage collection, will it still be able to run on tiny devices? We don’t know yet.

I would hope it's opt in for those scenarios. If the host is too "tiny" to carry around GCs, then a whole host of languages are not viable anyway. Requiring a GC wouldn't do them any favors.

Hard to say without reading all the specs/proposals: https://webassembly.org/docs/future-features/

But yeah, even specification itself is WIP

Reply on news.ycombinator.com