Hacker News Reader

Comment by felixgallo | Hacker News Reader

One wonders how we get out of this mess. You'd have thought that Microsoft/Google/Apple/whomever would have at least tried to include a better alternative language in their browser by now. What stops them besides inertia?

View on HN

I want browsers to support a bytecode language designed from the ground up specifically for this purpose instead of just being a quick hack that by a fluke of history happened to get wide adoption. It would be more like .NET and the JVM in the sense that it would be designed for a specific purpose (a language suitable as a target language for compilers from a wide variety of high level languages). But we should not confuse that last sentence to mean that it should be similar to .NET or the JVM. I think two main design goals should be efficiency and good support for high level languages. This means proper support for tail call optimization so that functional languages like Haskell, Clojure, etc can generate efficient code. It might also mean some special considerations for garbage collection that I'm not knowledgable enough to comment on...amongst other things. WebAssembly sounds like the right idea but if they miss important things like TCO, then it's still not acceptable.

Regarding TCO on WebAssembly: "Yes, proper tail calls will be supported, but likely not in MVP."

https://github.com/WebAssembly/design/issues/189

https://github.com/WebAssembly/design/blob/master/FutureFeat...

X, Flash, Swing, JavaFX, SilverLight, AWT and more were all attempts to offer a GUI over TCP. The important question is why they all failed. This is a complex issue and many good essays have been written that address parts of the question. Still, I think most of it can be boiled down to 3 things:

1.) some were closed-source and proprietary

2.) some were needlessly verbose, or enforced a workflow that made it difficult to interact with designers

3.) some depended on HTTP for at least the initial handshake

What the world needs is an open-source GUI technology that is fun for designers to work with and which uses a protocol other than HTTP.

My own bet would be that when we finally get such a technology, it will come from the world of gaming, where they already do amazing GUIs, and where they often abandon both HTTP and TCP and use UDP instead.

Did X fail?

Yes. It's not in my browser.

That's an excellent response, but it leads to the question, why are we using HTML if X was successful? HTML over HTTP is now routinely used to deliver a GUI for TCP, even though HTML was originally designed to deliver structured documents, and HTML comes with a great deal of baggage that muddies its ability to function as a GUI. It's become common to use a mountain of Javascript to try to overcome that baggage. Clearly, a fresh start is warranted.

One was killed by Apple.

If you are talking about flash let's be clear. Flash was killed by mobile (and being generally shitty).

It's not like Apple said "Flash is the worst" and everyone said "Hey, you know I never thought about it like that". In fact I'm sure battery was a major reason not allowing flash, IIRC that (plus general indifference) was what was the nail in coffin for even android phones flash.

> My own bet would be that when we finally get such a technology, it will come from the world of gaming, where they already do amazing GUIs, and where they often abandon both HTTP and TCP and use UDP instead.

Ever hear of scaleform[0]?

[0]: http://gameware.autodesk.com/scaleform

Scaleform is a barely-maintained Flash implementation.

Then I wouldn't put much hope in the world of gaming coming up with a GUI solution, then. From what I understand, Scaleform is considered best in breed for cross-platform GUIs in the gaming world.

It's fun you say that, Valve just ditched Scaleform (industry-standard, based on Flash) for their own GUI stuff called 'Panorama' in DOTA2, which is XML, CSS and JS.

They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.

Typescript transpiles to Javascript - its purpose is to allow static type-checking of regular Javascript code by dev tools, prior to transpilation.

AFAIK It has no features which would benefit from being used at runtime and there's never been any intention to run it straight in the browser. (If I'm wrong please correct me)

That takes out Microsoft and Google from that list. Also, ‘whomever’ already had its opportunity with Java.

So one could conclude the wait is for Apple with Swift. But would they want that? I think they would rather see people write iOS-specific apps in Swift.

Of course there may be another 'whomever'. Facebook with Hack, perhaps? Their advantage may be that they aren’t big in hardware or operating systems, but I still think they are too big and therefore deemed too dangerous by the likes of Apple, Google, and Microsoft.

I think the only way is for some small player to come out of nowhere and somehow take the world by storm, probably, as you say, by riding on top of WebAssembly.

(by the way, I don’t think WebAssembly will be the leveller that allows everybody to pick his own language to develop in for the web. I think we will see some high-level API in WebAssembly develop that fits one language better than others. Of course, we could again choose to make “C” that language and that way allow almost any language interface with any other language through a crude interface, but I would hope we can do better by now)

If WebAssembly doesn't get proper support for tail call optimization, then IMO it's not the way forward. Right now it's listed as a future feature[1] so color me skeptical.

[1] https://github.com/WebAssembly/design/blob/master/FutureFeat...

At the end of the day, you'll still be tied to the DOM, tied to poorly specified and poorly implemented HTML specifications (e.g, ContentEditable), tied to browser incompatibilities, and tied to CSS.

So the problem isn't just the lack of a viable JavaScript alternative. The problem is building on top of a weak, fractured foundation that was designed for an entirely different application than we now want.

I'd like a distributed app VM that's completely separated from the browser. Every time I think about this, I'm brought back around to this thought: why not java? Minecraft was a good proof of concept and it shows you can make a complex distributed application using java. So why are we tethering ourselves needlessly to the browser?

I think you missed Dart. In any case, everyone agrees at this point that compiling arbitrary languages to Javascript or a Javascript-derived compile target is the way forward. Write ClojureScript.

Funny thing: JavaScript was actually supposed to be Scheme, not once but twice, and both times it was scrubbed because Netscape was in fierce competition with Microsoft.

One must wonder whether Netscape greenlighting the addition of a Scheme dialect simply would have caused Microsoft or another party to implement some flavor of ALGOL or BASIC in return and leave the hypothetical SchemeScript going the way of the dodo, much like Netscape's JavaScript Style Sheets that almost no one remembers today.

Reply on news.ycombinator.com