Ask HN: Would the web be a better place with a CLR or JVM in the browser?
4 comments
Well, we had this. They were called "applets", and they were all the rage for awhile, but then they died off. I'd be interested in hearing thoughts on why applets failed, and how the current state of client-side web development is better or worse.
Applets were very segregated from the DOM. What the lingua-Franca of the web would require is first class DOM manipulation support, such that it doesn't require it's own UI toolkit.
Oh, and for it not to have horrid security bugs. That's what really killed applets ;)
Oh, and for it not to have horrid security bugs. That's what really killed applets ;)
I think that's it exactly.
For the many websites I've built I noticed that the biggest problems arise when the decision is made to do things in a 'custom' way. Custom back/forward functionality, custom scrollbars, custom 'widgets', and so on. Again and again it turns out more complicated than initially thought, and relying on the DOM and native interface elements would've been quicker and less error-prone.
For the many websites I've built I noticed that the biggest problems arise when the decision is made to do things in a 'custom' way. Custom back/forward functionality, custom scrollbars, custom 'widgets', and so on. Again and again it turns out more complicated than initially thought, and relying on the DOM and native interface elements would've been quicker and less error-prone.
I tend to disagree. As of today, Javascript is the least common denominator of all the advanced web technologies. If you know JS fairly well, you're able to understand nearly everything under the hood if you want to.
If you have CLR/JVM in addition, this just brings more problems to the table, especially when you have to deal with much more languages which do not "compile" to JS or when you have to deal with proprietary APIs/Libraries.
At the end of the day, "what can be written in Javascript will be written in Javascript", thus whatever functionality you want from other technology stacks will be available sooner or later, and is usable from your preferred "compiles to JS" language of choice. If you want a neat debugger, try Typescript maybe? If you like to think functional, give Livescript a shot. Only want class-based OOP and a fairly expressive syntax? Then just use Coffeescript. Or just use Javascript as is if you like it. When you need more performance, check out ASM.js if it fits.
Thanks to Emscripten you may even use languages like C++ for your web development.
If you have CLR/JVM in addition, this just brings more problems to the table, especially when you have to deal with much more languages which do not "compile" to JS or when you have to deal with proprietary APIs/Libraries.
At the end of the day, "what can be written in Javascript will be written in Javascript", thus whatever functionality you want from other technology stacks will be available sooner or later, and is usable from your preferred "compiles to JS" language of choice. If you want a neat debugger, try Typescript maybe? If you like to think functional, give Livescript a shot. Only want class-based OOP and a fairly expressive syntax? Then just use Coffeescript. Or just use Javascript as is if you like it. When you need more performance, check out ASM.js if it fits.
Thanks to Emscripten you may even use languages like C++ for your web development.
> If you know JS fairly well, you're able to understand nearly everything under the hood if you want to.
Your definition of "under the hood" is somewhat questionable. Yes, you can understand everything down to the JS layer which is basically the first step below the visible UI, but the full stack on which the JS runtime rests is of a dizzying height, and each one of its layers has performance implications.
> If you have CLR/JVM in addition, this just brings more problems to the table, especially when you have to deal with much more languages which do not "compile" to JS or when you have to deal with proprietary APIs/Libraries.
What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM?
Your definition of "under the hood" is somewhat questionable. Yes, you can understand everything down to the JS layer which is basically the first step below the visible UI, but the full stack on which the JS runtime rests is of a dizzying height, and each one of its layers has performance implications.
> If you have CLR/JVM in addition, this just brings more problems to the table, especially when you have to deal with much more languages which do not "compile" to JS or when you have to deal with proprietary APIs/Libraries.
What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM?
> What problems, more precisely? What's the difference between compiling C++ to JS and compiling C++ for an open VM?
Fair enough. Personally i see crosscompiler like Emscripten as a way to port already existing stuff over to JS. But i do not see the point why i would want to build a new application that targets JS in C++. You would loose the "native" performance of C++ and don't have the high-level language constructs to deal with common problems... even bread-and-butter string manipulation just takes more time (not too much, but just more) in C++ than for example in Coffeescript.
Fair enough. Personally i see crosscompiler like Emscripten as a way to port already existing stuff over to JS. But i do not see the point why i would want to build a new application that targets JS in C++. You would loose the "native" performance of C++ and don't have the high-level language constructs to deal with common problems... even bread-and-butter string manipulation just takes more time (not too much, but just more) in C++ than for example in Coffeescript.
> But i do not see the point why i would want to build a new application that targets JS in C++.
The main reasons I'd avoid writing any application that is either performance-sensitive or at least modestly complex are bad (or sometimes utterly inexistent) tooling, unstable and unpredictable environment and hidden complexity. Writing in C++ would alleviate at least some of the bad/inexistent tooling, but not much. I know this sounds strange to a web developer, but to someone coming from a hefty desktop/systems programming background, even the latest JS development tools are a joke. Coding for the web today feels worse than coding for X11 in 1996 (and we were equally enthusiastic about it).
What I would like to see for the web is exactly that: a language on which writing a codebase larger than a hundred lines isn't a piggybacked thing. Java had its problems (which were probably rooted in its far poorer integration with the web browser, compared to where JavaScript is today), but it had some nice features of its own: the stack behind your Java applet was a lot thinner (dear God, I thought I'd never live to say that!) than the JS environment and consequently a lot more predictable, even with its dreaded garbage collector, tooling was somewhere at the same level (but 15 years ago!) and the applets were in fact portable. Portable as in, they actually ran pretty much on anything that could run Java code (yes, regrettably that was in the form of a proprietary plug-in, but it need not be that way), as opposed to any JS trick that even begins to be impressive, which breaks on pretty much every other configuration.
The "native" performance of C++ is, IMHO, a poorly-stated idea in communities that like to call themselves "geek communities". If you were to write, in C++, a program that performs exactly the same functions, down to every abstraction layer (e.g. bytecode compiling, garbage collecting, decoding and rendering HTML etc.) and thus end up with exactly the same machine instructions, you'd arguably get a program that runs just as slowly, waiting for the same kind of I/O to complete and so on. You can get a performance equal to that of native-compiled C++ by compiling JS to native code. That, unfortunately, has its own problems, which we painfully remember from the days of ActiveX.
History doesn't repeat itself, but it rhymes so much!
Edit: personal rant:
I honestly think much of today's web application ecosystem exists because a lot of programmers were lazy, in a bad way. Back in the late 1990s, we were hoping that we'd use the web for awesome, collaboration- or communication-driven applications. That dynamic websites ("web app" is a misnomer IMHO) would be a better way of achieving some things because they'd let people communicate together.
But 90% of the "web apps" I see today literally don't do that, or do so with things that are utterly useless, like sharing todo lists with friends (unless it's a really jealous spouse, the amount of your todo list that you have to share really fits in the timeframe of a phone call...). Countless HTTP requests are made, but communication happens between a single client and a single server. It's like a native program, except all I/O operation are a few tens of thousands of times slower.
The problems they solve are entirely different, and in fact well within the capacity of "native" development tools: portability, accessibility and so on. I honestly think because, at some point, several million kids who learned HTML and some PHP from web tutorials wanted to make really useful things, but just didn't want to learn how to use more adequate tools and started beating the ones they had into submission.
The main reasons I'd avoid writing any application that is either performance-sensitive or at least modestly complex are bad (or sometimes utterly inexistent) tooling, unstable and unpredictable environment and hidden complexity. Writing in C++ would alleviate at least some of the bad/inexistent tooling, but not much. I know this sounds strange to a web developer, but to someone coming from a hefty desktop/systems programming background, even the latest JS development tools are a joke. Coding for the web today feels worse than coding for X11 in 1996 (and we were equally enthusiastic about it).
What I would like to see for the web is exactly that: a language on which writing a codebase larger than a hundred lines isn't a piggybacked thing. Java had its problems (which were probably rooted in its far poorer integration with the web browser, compared to where JavaScript is today), but it had some nice features of its own: the stack behind your Java applet was a lot thinner (dear God, I thought I'd never live to say that!) than the JS environment and consequently a lot more predictable, even with its dreaded garbage collector, tooling was somewhere at the same level (but 15 years ago!) and the applets were in fact portable. Portable as in, they actually ran pretty much on anything that could run Java code (yes, regrettably that was in the form of a proprietary plug-in, but it need not be that way), as opposed to any JS trick that even begins to be impressive, which breaks on pretty much every other configuration.
The "native" performance of C++ is, IMHO, a poorly-stated idea in communities that like to call themselves "geek communities". If you were to write, in C++, a program that performs exactly the same functions, down to every abstraction layer (e.g. bytecode compiling, garbage collecting, decoding and rendering HTML etc.) and thus end up with exactly the same machine instructions, you'd arguably get a program that runs just as slowly, waiting for the same kind of I/O to complete and so on. You can get a performance equal to that of native-compiled C++ by compiling JS to native code. That, unfortunately, has its own problems, which we painfully remember from the days of ActiveX.
History doesn't repeat itself, but it rhymes so much!
Edit: personal rant:
I honestly think much of today's web application ecosystem exists because a lot of programmers were lazy, in a bad way. Back in the late 1990s, we were hoping that we'd use the web for awesome, collaboration- or communication-driven applications. That dynamic websites ("web app" is a misnomer IMHO) would be a better way of achieving some things because they'd let people communicate together.
But 90% of the "web apps" I see today literally don't do that, or do so with things that are utterly useless, like sharing todo lists with friends (unless it's a really jealous spouse, the amount of your todo list that you have to share really fits in the timeframe of a phone call...). Countless HTTP requests are made, but communication happens between a single client and a single server. It's like a native program, except all I/O operation are a few tens of thousands of times slower.
The problems they solve are entirely different, and in fact well within the capacity of "native" development tools: portability, accessibility and so on. I honestly think because, at some point, several million kids who learned HTML and some PHP from web tutorials wanted to make really useful things, but just didn't want to learn how to use more adequate tools and started beating the ones they had into submission.
I wasn't suggesting any proprietary APIs or libraries - only that we get to use the /language/ of our choice.
Also I'm not talking about 'functionality [...] from other technology stacks' - I'm talking about getting to choose the programming language.
To current client code, everything would function exactly as before. It's just that you would be able to write new code in any language that can compile to the bytecode the VM understands.
The set of languages available through Emscripten doesn't compile most popular languages. If it did, it would likely fulfil what I'm hoping for, but I'd still be interested in whether it's the best option to compile to a subset of JS in order to run on a VM designed for JS.
Also I'm not talking about 'functionality [...] from other technology stacks' - I'm talking about getting to choose the programming language.
To current client code, everything would function exactly as before. It's just that you would be able to write new code in any language that can compile to the bytecode the VM understands.
The set of languages available through Emscripten doesn't compile most popular languages. If it did, it would likely fulfil what I'm hoping for, but I'd still be interested in whether it's the best option to compile to a subset of JS in order to run on a VM designed for JS.
<opinion>
I'd prefer the JVM/CLR-Stacks fading away alltogether. An exhaustive Toolchain like Java has + a fairly superior IDE like Visual Studio, both targeted especially for the JS-Stack, and everyone wins.
If there is enough desire, every possible language can be ported over to the JS-stack. For me it's contra-productive to have too much languages to choose from.
</opinion>
I'd prefer the JVM/CLR-Stacks fading away alltogether. An exhaustive Toolchain like Java has + a fairly superior IDE like Visual Studio, both targeted especially for the JS-Stack, and everyone wins.
If there is enough desire, every possible language can be ported over to the JS-stack. For me it's contra-productive to have too much languages to choose from.
</opinion>
> I'd prefer the JVM/CLR-Stacks fading away alltogether. An exhaustive Toolchain like Java has + a fairly superior IDE like Visual Studio, both targeted especially for the JS-Stack, and everyone wins.
How does everyone win by having everything on a stack that is inherently slower and has terrible support for concurrency?
> If there is enough desire, every possible language can be ported over to the JS-stack. For me it's contra-productive to have too much languages to choose from.
Having everything compile to JavaScript doesn't mean there will be fewer languages. It just means that implementing the languages and debugging your code will be significantly more awkward.
How does everyone win by having everything on a stack that is inherently slower and has terrible support for concurrency?
> If there is enough desire, every possible language can be ported over to the JS-stack. For me it's contra-productive to have too much languages to choose from.
Having everything compile to JavaScript doesn't mean there will be fewer languages. It just means that implementing the languages and debugging your code will be significantly more awkward.
Just out of curiosity, what's wrong with tools that compile to javascript? (i.e. CoffeScript, ClojureScript, pyjamas, and the like.)
No. I want a less dynamic, more content-driven web, not one that requires me to download more binaries.
No Common Lisp, no deal.
But agreed, we cannot settle on Javascript as the forever language.
But agreed, we cannot settle on Javascript as the forever language.
"we cannot settle on Javascript as the forever language."
We cannot, but thanks to the chicken-and-egg problem, we probably will anyway.
We cannot, but thanks to the chicken-and-egg problem, we probably will anyway.
Ha-ha, I may be older than you, I remember when COBOL was the forever language and VSAM the forever DB.
There exist dozens of languages and language enhancements designed to be compiled to JavaScript for running within a browser. While performance may be acceptable with modern browsers, the developer experience is still far from perfect: The debugger doesn't let you step through your original source and the languages available are limited.
If browsers were to build in a language runtime, such as a CLR, the choice of 'native' browser languages would expand greatly - and include languages such as : Java, C#, Python, Ruby, Haskell, Scala, Erlang and OCaml/F#. JavaScript would be supported on the same runtime of course!
An interesting 'feature' would be that tools like .NET Reflector could be developed to 'decompile' VM bytecode found in any page back to whatever language the developer preferred. Of course this wouldn't be perfect, but if you're used to working with C# and the original code was written in Scala, you would likely find that the decompiled version looked similar enough for you to work with it.
I'm leaning towards preferring a CLR rather than a JVM, as what I've read suggests that it's easier to get Java (the language) and JVM code (via IKVM) working on a CLR than C# and .NET code working on a JVM.