Hacker News Reader

Comment by lwlml | Hacker News Reader

At this point, I really loathe adopting any facet of web-browser technology: there are too many broken APIs in too many browsers to maintain on both sides of the system: the browser developers have an insane number of combinations of features that need to be useful, secured and made reliable and developers for browsers are always at some weird disadvantage where they can spend months or years maintaining an application for the browser to find it rots out from underneath them.

Should you even be slightly successful in the use of an API, you always have to worry about deprecation when someone is no longer interested in doing the maintenance any more.

I am sure there were more than a few game developers that are are livid today about this announcement.

These things will go in cycles and I expect there will be an native-application cycle coming soon from browser-api-fatigue.

View on HN

If you used this at all, it was in a Chrome-only app; this is pretty far from mainstream.

A good rule of thumb seems to be to use what everyone else uses, and make sure you're always ready to ship another version. People expecting compiled apps to survive unchanged for years are out of luck.

It used to be worse: keeping an old Compaq or DOS box around just so one random business app would keep working.

"Used to be"? There are still places that do that. :-) It's especially prevalent in factory automation and process control. We're lucky in that many of those systems are actually so old that no one ever thought of connecting them to the Internet.

Not true. NaCl is pretty big in some areas of Consumer Electronics.

Can you provide some examples?

E.g. http://developer.samsung.com/tv/develop/extension-libraries/...

That's a controlled environment, though; Samsung almost certainly creates a customized build of Chromium for its TVs and can simply keep NaCl enabled if it wishes. They aren't beholden to the same policies that apply to the consumer Chrome releases.

Yes, it's a gradual decay, not a forced upgrade.

The problem is that you eventually end up stuck with an ancient version of Chromium without security fixes and incompatible with websites that use newer browser features.

> The problem is that you eventually end up stuck with an ancient version of Chromium without security fixes and incompatible with websites that use newer browser features.

Samsung can't even keep their flagship phones up to date, their TVs are not going to be kept updated regardless of what Google does with Chrome...

This is about Google Native Client not the crypto library.

Except if you mean this NaCL, this is hardly true:

https://en.wikipedia.org/wiki/Sodium_chloride#Miscellaneous_...

Deprecated APIs is the cost we pay for innovation. If we're going to get new APIs then it's reasonable to expect that old, little used and superseded APIs will be retired, since the browser vendors don't have unlimited resources.

Of course, it's understandable for those who are hit by a deprecation to be annoyed, but overall I think the tradeoff is worth it. It's definitely better than have unchanging APIs and having browsers becoming less relevant over time.

There needs to a middle ground. While it is true bad APIs need to go once in a while, a lot of them never should have come in the first place, and if some work had been put into getting them right in the first place they would still work just find today. Not perfect mind you, but just a little effort would be enough that we wouldn't have to deprecate them.

I think the Web is moving in this direction, though I don't know how well.

Flash is a zombie but not dead. You can still get an old swf working by clicking a couple of things in browser settings. The thing with google is they deprecate wayyyy to fast without proper thought to the alternative. It's like their projects commit suicide than die naturally.

Yeah. Wouldn't it be great if they just created a simple VM with well specified bytecode so that we could push the complexity into our tooling and just compile into the standard target?

And if that VM ran on over 2 billion devices, on every toaster out there?

In the end, this all is just reinventing the JVM, in slower, but more secure.

I think that's what parent commenter was implying.

(However, I don't agree. I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)

Is the horribleness of applets intrinsic in the concept of a common target?

It might be, because "common target" implies a lack of competition.

IMO: No. It was more of an implementation issue. When Java applets were first implemented, the web platform was still extremely limited -- HTML was still at version 2.0, CSS and the DOM didn't exist yet, and Javascript was still very new. So it made some sense, at that point, to have Java applets exist in their own "world", and not interact with other web content.

A modern Java applet environment would probably look very different. More of a focus on providing a bridge to the browser's DOM, less of a focus on building UIs using native Java frameworks (like AWT or Swing).

It's definitely a challenge trying to balance portability with support for platform specific features but I'd be a little hesitant to draw general conclusions from the two big examples since both Adobe and Sun were notoriously negligent platform maintainers addicted to haring off after some shiny whim before fixing what they had already built. Even simple things like if Sun cared about non-server performance in the 90s or if either of them had figured out how to properly package and ship updated before the 2010s could have improved their reputation immensely.

>I remember the horrible Java applets and I am thankful that I pretty much never encounter any of them these days.)

Yeah, yay for progress and horrible Electron apps..

Electron apps are not really relevant when talking about Java applets. Java applets embed in the browser, so compare Java applets with HTML5, CSS3, JavaScript and WebAssembly.

I much prefer the latter (HTML5 + CSS3 + JS + WebAsm).

> In the end, this all is just reinventing the JVM, in slower, but more secure

More secure?

Probably the biggest cause of security bugs in Java applets is the fact that the applet execution environment is a full JRE, with all the APIs involved in desktop JRE instances available, with "insecure" ones being locked down on an as-needed basis. So if a developer forgot to insert a security check in the JVM, the applet becomes able to subvert its sandbox. The browser VMs don't have these APIs available in the first place, so getting undesirable access to things like the filesystem is much more difficult than "spot the API with the missing check."

Were you around in the 90s when people actually did try to use the JVM for this?

Do you remember the part where everyone started using JavaScript instead because of all the deficiencies of Java Applets? (Slow to load, resource intensive, no interaction with the surrounding page)

I was, and I wasn't saying that WebAssembly is bad — but I'd have preferred compatibility with Java bytecode, even if it'd offer different APIs.

It's reinventing the good part of the JVM (the JIT and the bytecode), better than the JVM (unsigned ints and value types are supported), without the bad parts of the JVM on the Web (the libraries, including the slow graphics stack, etc.)

What's not to like?

What do unsigned ints bring to the table? I'd use them in C to avoid undefined behaviour, but that's not a problem on the JVM. Value types sure, I guess, but they don't seem super important.

Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

Without unsigned types you have to use the next larger type and mask. It's ugly, a pain, and slower. You run into this problem a lot when dealing with binary data.

You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?

I appreciate that e.g. particular image formats are defined in terms of unsigned integers of particular sizes, but parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).

> parsing binary formats seems like a specialized use case that's not worth distorting the whole language over (and it already involves fiddling with endianness, so you can't directly use the "standard" version of a given-sized integer when parsing).

You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".

> You're begging the question, assuming you have to represent a particular unsigned type to start with. What's the problem that you're trying to solve?

1. Compiling existing C++ codebases.

2. Multiplication and division are not identical for unsigned and signed values. Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!

> You call it "distorting the language", I call it "exposing the capabilities of every single CPU manufactured in the last 15 years".

There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag) or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.

> Say I have a memory address on 32-bit (note that this applies equally well to 64-bit) and I'm doing pointer arithmetic. I'd better not be doing a signed multiply, or else values above 2GB will be corrupted!

I don't really see how this works (pointer arithmetic, not that one should be doing it at all, would generally involve adding or subtracting small offsets to pointers, I can't see any use case where you would want to multiply a pointer?), but in any case it doesn't apply equally well to 64-bit in any practical sense? If you happen to need an amount of memory between 2GB and 4GB or between 8EB and 16EB then maybe using unsigned pointers lets you use a smaller pointer, but that seems like a pretty narrow use case.

> There are plenty of CPU capabilities that languages don't exploit fully (e.g. most languages won't give you direct access to the carry flag)

Sure they do: the carry flag is the > operator.

> or only allow you to access via a specialized interface rather than making them a first-class part of the language (e.g. SIMD instructions). This seems entirely normal.

So if you want to argue that unsigned multiplication/division should be encoded as a magic intrinsic (as Java 8 does) instead of as a primitive operation, then I still think it's a bit silly to make such common operations require such verbose encodings, but I could be convinced either way.

> pointer arithmetic, not that one should be doing it at all

The point of wasm is to be a compilation target for languages like C and C++. So pointer arithmetic is very important here.

I don't think this is a "begging the question" fallacy. General purpose programming language often need to deal with binary data. This can be anything from documents, compressed files, images, audio, video, network data, a video framebuffer, and so on. Dealing with binary is in no way a "specialized use case" of programming; I'm honestly a little incredulous at your insinuation.

Further, this "distortion" amounts to adding 4 types and defining bitwise behavior, and since unsigned shifts are easier than signed shifts, no problem. I wouldn't call that a distortion, especially not compared to things like for-in and lambdas.

But really, can you explain your disdain for unsigned numbers? I've never heard someone argue for their exclusion from Java -- I thought we all accepted it was a mistake.

I view extra primitives as very expensive because they add a whole bunch of extra cases in the language itself; I like small languages where as much as possible can be moved into libraries. I just don't see the use cases for unsigned ints as being widespread enough to justify having them in the language; I've worked across a number of industries and I think I've seen them used once (when fixing a bug in ffmpeg), whereas for-in and lambda are used absolutely everywhere. I'm not especially anti-unsigned; if I was designing a JVM-like bytecode I'd remove short, and perhaps even (single-precision) float and int as well.

> Can't we just make DOM bindings for the JVM and reuse the huge existing library base?

Almost nobody is asking for this, compared to the huge number of people asking to compile C++ codebases.

What's not to like? Why couldn't we just create a system compatible with Java bytecode, and just replace the APIs over which it interacts withthe system (as Android has done)?

That'd make it even possible to reuse old applets with just a tiny shim around them.

And it'd keep compatibility with a huge environment of libraries and languages.

> Why couldn't we just create a system compatible with Java bytecode

Because Java bytecode is not a good target for many languages, such as C and C++, for one. It lacks unsigned and value types.

> just replace the APIs over which it interacts withthe system (as Android has done)?

That still leaves a whole bunch of APIs that are duplicated.

> That'd make it even possible to reuse old applets with just a tiny shim around them.

The number of people who want to do that is far, far less than the number of people who want to compile existing C++ codebases.

> And it'd keep compatibility with a huge environment of libraries and languages.

While sacrificing compatibility with the even huger existing JS environment.

Much harder than it sounds. Java, Adobe, and Google pumped a few hundred million dollars into previous attempts and they all failed. WASM learns from two decades of previous attempts and we are finally getting something sustainable[0].

0: https://brendaneich.com/2015/06/from-asm-js-to-webassembly/

Have you been doing this for any amount of time? Because today browser compatibility is just excellent compared by historical standards. The only differences are usually that some new feature doesn't appear in all browser engines at the same time.

Makes sense, if you consider a thing only Google implemented as "web-browser technology".

Yeah, we were looking at browser stats for our website today and during the last 30 days 20% of our distinct users were using IE 6, 7, 8, 9, 10, or 11. Of course most were on IE 11, but when you still have a significant number of people still using ancient versions of IE, I despair at ever being able to use modern web technologies.

The only way to move forward is to ignore them. Put up a message that advises to install Chrome or Firefox and get rid of all the cruft that supports browsers older than 5 years. Most probably already have a modern browser installed but use IE out of habit. I see it at large corporations all the time. I even heard "I wish it would remind me to just use Chrome"

Chrome and Firefox probably dont run on their OS.

Then they have bigger problems that they should be getting on top of urgently.

I agree, but simply telling user to download a better browser could be a pretty condescending attitude. Falling back to a css-less html 4 would be more responsible for everyone.

It could sound condescending, but the amount of people really limited to IE9 or IE10 without an alternative is really, really small.

Can I live in your world where you can just tell customers to go away.

Unfortunately that isn't an option for us. We are mandated to support everyone. And those people on IE are retail sales associates using our site on hardware that simply cannot be upgraded. It must be replaced to get a newer browser. But the replacement cycle is measured in decades.

> And those people on IE are retail sales associates using our site on hardware that simply cannot be upgraded.

I'm sooooo glad I'm not you. I've literally halted all personal projects using JS until they get modules implemented natively.

I don't quite get your numbers, because 20% * IE6, 7, 8, 9, 10, 11 = 20% * 6 > 100%.

Or, alternatively, the 20% for all of them combined don't prove your point that "people are using ancient versions", because, as you point out yourself, "most were on IE 11".

FWIW IE 11 is around 3% globally, all other IE is around 0.5%, combined: http://caniuse.com/usage-table

> FWIW IE 11 is around 3% globally…

Out of all browsers, including on mobile devices -- which skews the results pretty significantly.

If you only consider desktop browsers, MSIE comes out between 9-10%, including about 7% on MSIE11. That's not counting Edge, which is another 3% or so.

20% of our user base is on some form of IE (6-11). The other 80% are on Chrome, Firefox, Edge, Safari, etc.

Or, you could just stick with those at IE11 (which are most) + the other 80%, and ignore those < 10% of users.

When was the last browser-api-fatigue?

Reply on news.ycombinator.com