7 ms·

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 lang

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?

tim333 11y ago
They've tried Typescript and Dart. No massive uptake to date. WebAssembly may be a way forward.
- davnicwil 11y ago
  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)
- Someone 11y ago
  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)
- mightybyte 11y ago
  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/FutureFeatures.md#signature-restricted-proper-tail-calls https://github.com/WebAssembly/design/blob/master/FutureFeat...
natrius 11y ago
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.
TeMPOraL 11y ago
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.
- vezzy-fnord 11y ago
  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.
lkrubner 11y ago
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.
- jacquesm 11y ago
  Did X fail?
  - copperx 11y ago
    Yes. It's not in my browser.
  - lkrubner 11y ago
    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.
- pags 11y ago
  One was killed by Apple.
  - joshstrange 11y ago
    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.
mightybyte 11y ago
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.
- icebraining 11y ago
  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/issues/189 https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#more-expressive-control-flow https://github.com/WebAssembly/design/blob/master/FutureFeat...
freyr 11y ago
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.
PopeOfNope 11y ago
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?

tim333 11y ago

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

davnicwil 11y ago
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)
Someone 11y ago
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)
mightybyte 11y ago
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/FutureFeatures.md#signature-restricted-proper-tail-calls https://github.com/WebAssembly/design/blob/master/FutureFeat...

natrius 11y ago

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.

TeMPOraL 11y ago

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.

vezzy-fnord 11y ago
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.

lkrubner 11y ago

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.

jacquesm 11y ago
Did X fail?
- copperx 11y ago
  Yes. It's not in my browser.
- lkrubner 11y ago
  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.
pags 11y ago
One was killed by Apple.
- joshstrange 11y ago
  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.

mightybyte 11y ago

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.

icebraining 11y ago
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/issues/189 https://github.com/WebAssembly/design/blob/master/FutureFeatures.md#more-expressive-control-flow https://github.com/WebAssembly/design/blob/master/FutureFeat...

freyr 11y ago

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.

PopeOfNope 11y ago

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?