

Ask HN: Would the web be a better place with a CLR or JVM in the browser? - rikkus

While I don&#x27;t mind coding with JavaScript, I&#x27;d much rather use the language of my choice both within the browser and in server-side code.<p>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&#x27;t let you step through your original source and the languages available are limited.<p>If browsers were to build in a language runtime, such as a CLR, the choice of &#x27;native&#x27; browser languages would expand greatly - and include languages such as : Java, C#, Python, Ruby, Haskell, Scala, Erlang and OCaml&#x2F;F#. JavaScript would be supported on the same runtime of course!<p>An interesting &#x27;feature&#x27; would be that tools like .NET Reflector could be developed to &#x27;decompile&#x27; VM bytecode found in any page back to whatever language the developer preferred. Of course this wouldn&#x27;t be perfect, but if you&#x27;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.<p>I&#x27;m leaning towards preferring a CLR rather than a JVM, as what I&#x27;ve read suggests that it&#x27;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.
======
projectileboy
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.

~~~
girvo
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 ;)

~~~
mercer
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.

------
anonyfox
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.

~~~
weland
> 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?

~~~
anonyfox
> 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.

~~~
weland
> 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.

------
debacle
No. I want a less dynamic, more content-driven web, not one that requires me
to download more binaries.

------
kennethtilton
No Common Lisp, no deal.

But agreed, we cannot settle on Javascript as the forever language.

~~~
yen223
"we cannot settle on Javascript as the forever language."

We cannot, but thanks to the chicken-and-egg problem, we probably will anyway.

~~~
kennethtilton
Ha-ha, I may be older than you, I remember when COBOL was the forever language
and VSAM the forever DB.

