
Comparing JVM alternatives to JavaScript - based2
https://renato.athaydes.com/posts/comparing-jvm-alternatives-to-js.html
======
tlrobinson
This is a pretty unfair comparison for React. He uses the "JavaScript has
complex toolchains" excuse to not use best practices like JSX and a bundler,
then claims React is verbose and slow compared to other solutions that use
complex toolchains?

First of all, Parcel is a dead simple to use bundler that supports JSX, hot
reloading, code splitting, and various file types (including TypeScript) out
of the box: [https://parceljs.org](https://parceljs.org)

Second, that React code is much longer than it needs to be, mostly due to
formatting, but if you use function components and React "Hooks" it can be
extremely short:

    
    
        const Counter = () => {
          const [count, setCount] = useState(0);
          return (
            <div>
              <p>The current count is {count}</p>
              <button onClick={() => setCount(count + 1)}>Increment</button>
              <button onClick={() => setCount(count - 1)}>Decrement</button>
            </div>
          );
        };
    

With the imports and call to "render" it's about 15 lines of code, which is
much shorter than all of his other examples.

The class version (written how I'd do it) is about 25 lines, which still
shorter. Here it is without JSX, using Preact's HyperScript-style `h` instead
of `React.createElement`:

    
    
        class Counter extends Component {
          constructor(props) {
            super(props);
            this.state = {
              count: props.count || 0
            };
          }
          increment() {
            const { count } = this.state;
            this.setState({ count: count + 1 });
          }
          decrement() {
            const { count } = this.state;
            this.setState({ count: count + 1 });
          }
          render() {
            const { count } = this.state;
            return h("div",
              h("p", "The current count is " + count),
              h("button", { onClick: () => this.increment() }, "Increment"),
              h("button", { onClick: () => this.decrement() }, "Decrement")
            );
          }
        }
    

And of course these are toy applications, which aren't even representative of
real applications. I'm not sure I can go back to imperative UI toolkits like
GWT, etc.

The application size seems approximately accurate, but if you really care
about bundle size you could use Preact (which supports most of React's
features). The brings the bundle size down to about 10KB, which is also much
smaller than his examples.

Load time is also unfair due to lack of bundling.

~~~
geezerjay
> He uses the "JavaScript has complex toolchains" excuse to not use best
> practices like JSX and a bundler

Those are best practices if your goal is to stick with javascript no matter
what, which is not the goal of the comparison. Resorting to a transpiler which
adds whole new complexity dimensions and failure points to your build, and
doing so while aiming to introduce a complex workflow that requires half a
dozen modules to become manageable is far from the ideal solution.

~~~
tlrobinson
> Resorting to a transpiler which adds whole new complexity dimensions and
> failure points to your build, and doing so while aiming to introduce a
> complex workflow that requires half a dozen modules to become manageable is
> far from the ideal solution.

What? The entire post was about comparing JavaScript to alternatives which
use... compilers/transpilers:

    
    
       GWT - Java-source-to-JS, server and client-side framework
       TeaVM - Java-bytecode-to-JS compiler
       JSweet - Java-source-to-JS (and TypeScript) compiler with library ecosystem
       CheerpJ - Full JVM implementation on the browser
       Vaadin Flow - Java-source-to-JS-source, server and client-side framework
       Bck2Brwsr - Java-bytecode-to-JS compiler

------
kgwxd
After 20 years of traditional JavaScript, I recently got a chance to use
ClojureScript on a decent size project, it's the only way I'm ever doing
JavaScript from now on. It's a beautiful way to use React, no JSX or HTML
strings in site, it's all generated using the same stuff used to write
application logic. Yes, there's still a lot of tooling behind it, but I very
rarely had to directly deal with any of it, Leiningen does most of the work
with package management and builds, and ClojureScript itself takes care of
utilizing Google Closure for its dead code elimination and other
optimizations, without me having to write a single ugly annotation.

~~~
blunte
If only the Clojure(script) community would keep an up-to-date full guide on
how to do modern web development with Clojure+ClojureScript...

I'm 1000% sold on Clojure (and have done some production back-end tools with
it), but every time I try to do front end or mobile, I struggle without
outdated guides or books and relative lack of other current online resources
to get me reasonably down the road toward success.

Apparently people who successfully use these tools are happily working and not
having the time to educate new people. Of course it's not their
responsibility, but it does seem that the Clojure community is far less
involved in nurturing new users than many other languages/toolkits/frameworks.

~~~
yogthos
Luminus provides ClojureScript support out of the box along with documentation
on how to use it. It's been around for years now, and the primary goal is to
provide a smooth beginner experience:

[http://www.luminusweb.net/docs/clojurescript.html](http://www.luminusweb.net/docs/clojurescript.html)

You can create a new project with Clojure/Script support by adding different
flags. For example, for a re-frame project:

    
    
        lein new luminus myapp +re-frame
    

This will generate the needed boilerplate and configuration. You can now start
the server by running:

    
    
        lein run
    

The server will start a nREPL that you can connect the editor to on port
`7000`, this is defined in the `my-dev-config.edn` file. The typical workflow
is to connect to the REPL, and run your code as you're writing it.

Next, you start ClojureScript compiler in a separate terminal with:

    
    
        lein figwheel
    

The front-end workflow typically involves having figwheel running while you
write the code, and it will automatically push changes to the browser. You can
also connect to the nREPL started by Figwheel from the editor. This port is
specified in `project.clj` under `:figwheel` with the `:nrepl-port` key. The
default is `7002`. Once you connect the editor you run `(cljs)` function to
switch to the ClojureScript REPL. You can now evaluate any code that's running
in the browser. Note that Figwheel has to be started, and the page loaded in
the browser first.

The project is set up to keep all the code in the same repository, and you
have three separate source paths:

* `clj` - server-side code * `cljc` - code shared between the server and the client * `cljs` - client-side code

Packaging the app is done by running

    
    
        lein uberjar

------
wwweston
Interestingly, even as a one time front-end specialist, I'm leaning the
something same direction this author did: the complexity introduced along with
front-end frameworks/tooling treads near (and in some cases beyond) a border
past which I stop feeling like working with JS itself is a win. The more the
development process treats the browser as a runtime target for generated code,
the less point I see in sticking with JS -- or even augmented versions of it
-- as a source language. And I _like_ JavaScript.

Of course, I don't much like Java, so that's not where I'm likely to go, but I
am struck with what the author demonstrated here regarding that as an option.
Like the author, I'm very curious about something like Elm; if I'm going
somewhere with a type system, I'd like to go further along the spectrum of
benefits types can provide.

And I'm also not sure we've reached the apex of possibilities of working more
directly with HTML/CSS/JS, but that's highly domain/application dependent and
another topic.

------
nercht12
The sad part is, even with all these complex toolkits and yada yada, I still
haven't seen much of an improvement in the UI, which is, from the user's
perspective, the primary ( if not only) thing that matters. Sites just get
slower, break more easily, and look comical when you turn the JS off. Maybe
some backend helps ease some pains, but if you have to spend hours and hours
reading about how to do X in framework Y cooperating with framework Z did you
really save any time or make your site more robust than including and using a
few tools from a lightweight library? Not that I make anything big, but it
seems websites aren't any better than before; just the toolkits are getting
bigger.

~~~
muxator
How true. Lately I am also starting to have problems with my default Firefox
setup, which blocks 3rd party cookies and trackers. The result? A lot of (in
my opinion) lazily coded websites break, without ever catching a single error,
because they were put together assembling external services and skimming on
testing.

Normally everything more or less works with my fallback chrome in its default
configuration, but then I feel we are more or less back to "optimized for ie6"
days.

------
Twirrim
It's interesting seeing GWT producing small javascript. I must admit I have
been somewhat biased against it given prior experience. It _used_ to be used
for the AWS console all over the place, on the theory that it would be easier
for the service devs to also write the console code. That got eventually
overhauled to the far superior form it is now.

The Javascript that used to be produced was enormous, and of course on a per-
service basis, and it had a big overhead on the parsing and running stakes. If
any of you was using the console maybe 5 or so years ago, you'll know what I
mean about the console loading experience (it was fine once the javascript got
processed).

~~~
skybrian
AdWords is a huge service. It was the largest GWT app out there and always
pushing the limits. It was entirely rewritten when they moved to Dart. It's
hard to say how much of the improvement was due to better language-level tools
versus having learned a lot since then.

The GWT team at Google went on to write the j2cl compiler, and based on Github
commit history, they're still working on it:

[https://github.com/google/j2cl](https://github.com/google/j2cl)

------
symlinkk
He doesn't like JavaScript development because the tooling is too complex, but
then he pulls in behemoths like GWT?

~~~
not_kurt_godel
GWT is incredible. Admittedly the tooling is a bit clunky but it's really no
worse than your run-of-mill webpack/yarn/grunt/gradle/whatever JS build. Such
a shame it's kind of been semi-abandoned, it just blows TypeScript/React out
of the water on so many fronts. Hard to pick what I like best about it but I
think the number one gap that TS et. all will have trouble reaching is
compilation to asm.js. It's really hard to overstate just how much more
performant GWT apps are pound-for-pound due to this and a few other
performance-related features/hacks that seem a long way off, if not downright
impossible, to match as long as the source language is JavaScript.

~~~
invokestatic
Have you tried Vaadin? Apparently, it's based on GWT and still actively
developed. I'd really like to try the GWT style development model for an
upcoming project and Vaadin looks like an appealing solution.

~~~
not_kurt_godel
I have not, but I have met the Vaadin guys at a conference and seen demos. I
would agree it does look quite appealing overall.

------
lemming
I'm a bit mystified why OP didn't include Kotlin on their list. It's very
accessible for Java devs, works brilliantly with tools they are probably used
to (IntelliJ, Gradle etc) and compiles natively to JVM and JS (and Native
these days, if you care about that). It seems like the ideal candidate.

~~~
skybrian
Kotlin's JavaScript support has been around for a while but I was under the
impression that it wasn't used much. Is there a community using it now and is
it getting much support?

~~~
cutler
Kotlin may be a nice language but its HTML library:

    
    
      https://github.com/kotlin/kotlinx.html
    

... is an abomination.

------
itslennysfault
This is a crazy argument IMO. JavaScript tooling is stupid simple if you know
what you're doing. Learning something new is always hard so if you're new to
JavaScript (and have a JVM background) of course it'll seem hard at first.

I love node 'cause it "just works" (but really it does). The app I work on is
node TypeScript Nest.js backend and TypeScript Angular frontend. The set up
process for a new dev is install node (takes like 10 seconds), clone the repo,
npm install, npm start. Ready to start developing.

TypeScript is as simple as installing typescript, and running tsc from the
command line. With ts-node you can simply make your npm start script "ts-node
./index.ts" and you're off and running.

~~~
cutler
The trouble with Typescript is that the corporates have gotten their hands all
over it as a means of turning JS into Java. TS turns lean, functional JS into
an over-engineered smorgasbord of classes, interfaces and general OOP
nonsense. JS was designed primarily as a functional language.

~~~
Gene_Parmesan
Right, because functional languages aren't known for having highly expressive
type systems at all. And anyways, while Eich's original dream was to bring
Scheme into the browser, it's obvious that forces at Sun, by telling him to
make it more similar to Java, changed the nature of the language in a core
way.

It's absurd to say JS was designed primarily as a functional language when
there is mutation everywhere, inconsistent use of equivalence, and one of the
looser type systems still in existence.

Either way, I'm surprised that that's been your experience, because I have
found it to be the opposite. I've found TS to be most of what I like about
C#'s typing (interfaces are an incredible, foundational tool) with much less
of the ceremony. I still prefer C#, but I find TypeScript's flavor of OOP to
be one of the lightest (in terms of enterprise-OOP, langs like Smalltalk
obviously still take the overall cake).

~~~
BrendanEich
Hi, just for the record, Netscape management as well as Sun insisted that JS
look like Java. Java was supposed to be the big language on the client side.
That didn't pan out, but JS got big and begat WebAssembly thanks in part to
the asmjs.org latent static type system (another part: WebGL typed arrays).

------
pcj-github
Add [https://github.com/google/j2cl](https://github.com/google/j2cl) to the
mix if you're looking for java development for front-end work.

------
paglia_s
The problem with this post is that React, an UI library, is being compared
with toolkits that in some cases are simply Java-to-JS compilers. To make a
fair comparison there should also be a plain js example

------
acjohnson55
Scala.js is also an option.

[https://www.scala-js.org/](https://www.scala-js.org/)

It skips the JVM altogether and complies Scala to Javascript. I haven't used
it for anything significant, but I've heard nothing but good things.

~~~
threeseed
I am using it now and it's solid. Recommend combining it with:

Slinky React ([https://slinky.dev](https://slinky.dev))

JSON RPC ([https://github.com/shogowada/scala-json-
rpc](https://github.com/shogowada/scala-json-rpc))

Diode ([https://github.com/suzaku-io/diode](https://github.com/suzaku-
io/diode))

Scalably Typed
([https://github.com/oyvindberg/ScalablyTyped](https://github.com/oyvindberg/ScalablyTyped))

Being able to use almost every React library but with full types and code
completion is amazing. And with JSON RPC you can treat Client -> Server as
though it's just another method call.

------
jarym
For all that people wanted to run away from Java’s ‘complex’ toolset it seems
modern JS has managed to recreate most of it.

I wonder if we’ll do a loop with JSON and end up back at XML

~~~
doctorpangloss
We did, GraphQL is the new XML.

~~~
goatlover
Yeah, I don't understand the love for GraphQL. It seems over-engineered and
difficult to get started with.

~~~
geezerjay
GraphQL gets a lot of love because it presents itself as a solution to a
considerable and all too frequent problem: get the front-end/client teams to
coordinate with the back-end teams. This is more of an organizational ans
project management problem than a technical problem, thus their advocates are
ok with the trade-off.

------
truth_seeker
GraalVM is also an alternative. It might be able to run your existing NodeJS
project on JVM.

[https://github.com/graalvm/graaljs](https://github.com/graalvm/graaljs)

------
cromwellian
J2cl (successor to GWT) produces even smaller code.

------
theptip
In a similar vein, I have been idly wondering about the viability of using
Python for building browser apps recently:

Http://brython.info Http://pypyjs.org

No idea what the performance is going to look like for webasm, but might be a
worthwhile sacrifice if the developer productivity gains were good enough
(using the same language for FE and BE makes many things easier).

~~~
aitchnyu
Here is Mozilla bringing Python to Browser via WASM, a few science benchmarks
run faster in WASM than CPython, others get upto 12x slower.

[https://hacks.mozilla.org/2019/04/pyodide-bringing-the-
scien...](https://hacks.mozilla.org/2019/04/pyodide-bringing-the-scientific-
python-stack-to-the-browser/)

------
ralusek
Use `create-react-app` you absolute maniacs.

------
xx4xx4
oh, i know now

------
torqueTorrent
It can be useful to keep it simple and try to stay exclusively with HTML-
latest + ES-latest + CSS and avoiding external JS libraries as much as
possible. Using the latest versions of just the basics (HTML, ES, CSS) can
help minimize what only recently required the addition of external JS
libraries.

