Comparing JVM alternatives to JavaScript | Hacker News Reader

Comparing JVM alternatives to JavaScript

renato.athaydes.com

123 pointsbased276 comments

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

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.

The early part of his post listed the challenges in doing front end dev because of the many (and frequently changing) options and varying online guidance on how to do things.

Undoubtedly there exist better combinations of tools, but as someone just starting front end exploration, knowing what is the right combination is virtually impossible.

If you are using React, the best combination is to use the official recommendation. Install create-react-app.

I'm a longtime programmer, but I can see where at least some of the confusion arises.

Even if you make it to the create-react-app page, the official documentation doesn't make a recommendation among three separate build options (npx, npm, yarn) and two app start options (npm start or yarn start). Worse, there's no explanation of why one would choose one method over another.

My experience with React is this type of muddled guidance is very common throughout the ecosystem.

That's true if by "official documentation" you mean the Google search result page. Google Search Features gives a summary box that's as ambiguous as you describe. Click through to the actual page, though, and you get a single, simple set of startup commands.

https://github.com/facebook/create-react-app#quick-overview

EDIT: For reference, the URL where I see the ambiguous startup steps: https://www.google.com/search?client=firefox-b-1-d&q=create-...

The Github page you linked is the page I was referencing as "official documentation". From that page:

- "To create a new app, you may choose one of the following methods:" (then suggests npx, npm, or yarn)

- "npm start or yarn start

Runs the app in development mode."

- Even from right below the anchor you linked:

"(npx comes with npm 5.2+ and higher, see instructions for older npm versions)"

This is in reference to the overview commands of

npx create-react-app my-app cd my-app npm start

which add to the ambiguity further down the page...Should I use npm or npx? Can I mix them? The quick overview uses both.

This is all confusing to newbies. I have no idea why they don't pick one way to do things (or at least explain why one might choose one vs the other).

"(npx comes with npm 5.2+ and higher, see instructions for older npm versions)"

To me it seems obvious that you use npx unless you're stuck with an older npm version, or you're already using yarn.

Why would that be obvious to a person new to the ecosystem? npx and npm coexist. They have overlap in functionality. They are both referenced in the instructions the user is reading.

Why couldn't they just write that you should use npx if you have it? Or, since it works using npm too, why not just tell everyone to use npm?

There are so many non-obvious things here.

Why do we run some binaries via npm and others via npx? If you're going to use npm to run all the commands after create-react-app, why include npx in the document at all?

If you use npx to create an app per the directions, why does the animated output tell you to use yarn to start it (and not npm as in the text immediately above)? Why does the animation then ignore the output and use npm to start it?

The answers to these types of questions may be known to someone immersed in the ecosystem, but the presentation on the official page is definitely muddled and makes the answers far from obvious.

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

> 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

I'm an author of TeaVM. Currently, I don't do TeaVM as a replacement for React/Angular/Vue. There's a use case which is not covered by React at all: cross-platform CPU-bound applications. Java runs in Androd and Windows natively and on iOS with help of tools like MOE or RoboVM. TeaVM helps to run Java application in the browser (in Chrome OS in particular). Yes, JavaScript runs on all platforms as well, but it's performance (altough great nowdays) is still worse than Java. Having really large applications (0.5MLOC in our case) makes it nearly impossible to have separate code bases for every platform. Also, Java strict sematics makes it possible to perform various optimizations to generated JavaScript impossible with pure JavaScript.

Could you give a suggestion where to learn "modern" React best practices? It seems you have a good (right?) workflow, and I'd like to start learning modern React "the right way"

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.

Nice to see some lisp lovers in the frontend world. How does clojure handle types though, how would you argue with a typescripter for clojure rather than typescript ?

I wouldn't. I'd just finish the job and head off to the beach.

You get immutability for free with Clojurescript which is a bigger win than types but if you must have types there's Clojurescript spec now:

  http://cljs.github.io/api/cljs.spec.alpha/

Adding to your point, spec goes beyond the power of a (garden variety) type system, since it does its work at runtime. This of course incurs a performance hit, but you can easily exclude these checks in a prod build just by setting a compiler flag.

I've come to the realization that what we mean when we say "programming" must be fundamentally different categories of activity for different people.

I can't remember the last time I had a type error, or maybe if I did it was so trivial to fix that it's not sticking out. Type errors wouldn't even rate in the top ten categories of bugs that I make or encounter, so it seems odd to pick a programming language with that as a primary concern.

All else being equal, it does seem nice at some theoretical level to have a compiler that checks type correctness, but there's lots of other issues that would also be nice to have the compiler handle, which it often doesn't. For example, TypeScript seems to (like JavaScript, so far) not have any bigints, which seems to me a much worse flaw than lacking a type checker. What good is it for the computer to check my usage of types, if it can't even do arithmetic correctly with them?

But maybe this is just more of that nice feeling. I can't recall the last time I overflowed a fixint, either. (64 bits help with that -- or even 53 bits.) It's admittedly not a major practical concern in my daily programming life.

Maybe there are people who fret about type safety the way I fret about overflow. I assume it must be a concern among some styles of programming, because I keep hearing about how languages without compile-time type checkers are bad, even though my experience does not agree.

(Then people go and use languages where the type system is merely at the level of "Number" and "String", and it lets you pass a loop index to a function expecting a height in centimeters, and that's considered acceptably type-safe.)

If you mainly backend dev, you should just install Ember CLI, create a new Ember app and start building.

Super simple, super modern and easy to use. You will love it and forget those hyped madness what others do...

Additionally, Ember.js devs get the highest salary in frontend world. ;)

https://emberjs.com | https://yoember.com

Except that Ember is one of the heaviest front-end frameworks in terms of file size. Heavy file-size = more work for your mobile phone's CPU to deal with.

It changed a lot and you don't have to use all the feature if you don't need it. React with data support, router, etc can be super big... and latest Ember without Ember Data and tree shaking is small, so you win a lot of developer time and money and you end up with a well maintainable code, which can be understand by others in the first day, because of conventions over configurations. ;) IMHO Ember.js is still the best option for frontend, especially if you build a serious Web Application.

> Except that Ember is one of the heaviest front-end frameworks in terms of file size.

IIRC react requires nearly 300MB worth of npm packages just to get the hello world example to run. How does Ember fare in comparison?

NPM packages generally have nothing to do with the size of the built website. I don’t care if I need around 300mb of npm packages to build a 10kb website when ember itself is bigger.

Yeah Reagent is definitely the most productive front-end development flow. Just having hiccup vs JSX is a huge win. With JSX I spend most of my time chasing down syntax errors. With Hiccup I can simply use my IDE to navigate the code and syntax errors almost never occur and when they do it is obvious. Not to mention Hiccup is much more concise and can be read by macros.

Clojurescript truly is alien technology. Modern react has basically adopted Reagent's programming style with Hooks. Clojurescript/Reagent were 5 years ahead of the curve, truly amazing.

Clojurescript gives you a live repl, immutable data by default, core.async, macros, and an amazing consistent core library. None of these things are ever going to come to the javascript world

I had only heard (from afar) about Om; how does Reagent compare?

Reagent is a simpler abstraction around React, almost like a director's cut :) Om is a bit more oriented to react components. Both are mighty fine.

http://theatticlight.net/posts/Om-and-Reagent/

Yes, cljs is like frontend finally got its meds and everything makes sense again!

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.

This is why, after last year one of our consultant teams struggled with this very thing, I built Clojurice: https://github.com/jarcane/clojurice

Full-stack setup with Boot and hot reloading on both front and backend, with some basic SASS, DB, and configuration setup as well.

Have a look; even if it's not for you, it might give you some idea how to set up an application and dev environment.

This is my impression as well, we do need better landing page esque docs and more blogs

deps.edn, shadow clj, and regeant seems like what I would try and target at the moment unless trying to do full stack datoms

In which case Fulcro looks like the future there just very complicated to learn I think I need to learn graphql first to help my understanding

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

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

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.

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.

Quite right, but then Web FE devs will tell you how HTML/CSS are so much better than native toolkits, as if.

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.

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

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

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

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.

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.

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.

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.

Probably because it's not Java. Yeah, it's similar to Java and runs on the JVM, but it ain't Java. Confusingly, the author uses the term "JVM" in the title but then discusses strictly Java in the article itself.

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?

Kotlin may be a nice language but its HTML library:

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

... is an abomination.

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.

> JavaScript tooling is stupid simple if you know what you're doing.

Do you mean simple, or easy? I think the latter. The JS tooling seems well optimized for the novice user, but I think it's hard to argue that it isn't complicated behind that friendly face.

Also, I think most things seem easy once you know what you're doing. Almost tautologically so.

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.

This runs counter to my experience. I've found that TS will confirm to any style of programming you prefer to use. If you want to avoid classes and inheritance, just type your functions and data structures and call it a day.

>lean, functional JS into an over-engineered smorgasbord of classes, interfaces and general OOP nonsense

Aka "code that someone other than you can understand"

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

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

Javascript tooling is incredibly complicated compared to other languages.

Lets compare Java and Angular 6 (using your example)

Java Build system: Maven, javac Java module system: Class files

Typescript Angular Project: (as of Angular 6): Typescript compiler, Angular compiler, Babel, Webpack, Npm/yarn (which are not always interchangeable). Now if you have a complicated CSS setup you might have to run multiple CSS post processors. If you are using webpack they might be css-loader and sass.

Module system: CommonJS, AMD, UMD, ES6.

Javascript isn't difficult - it is needlessly difficult.

I bet it would take most front end developers over a day to set up all the dependencies for a "modern ES6 react-redux project" from scratch. That is why templates like "create-react-app" are popular- there is way too much plugin configuration and boilerplate necessary to get the toolchain working.

Both Clojurescript and Elm have much saner development workflows on the front end for example. (Both have their own compilers and a better package ecosystem)

Try Parcel: https://parceljs.org/

I use parcel every day at work, and have used it for side-projects as well. In many ways Parcel is worse - Parcel is a giant monolith, so when things work it is great. For simple projects it is often fine. However when you are trying to do something complicated, it can be very difficult to debug. Parcel overrides node's module resolution with its own algorithm, and parcel does not use the same plugins as Webpack for all tasks. This means that Parcel. has it's own category of bugs and you will have to figure out if the problem (vs webpack) lies in the different plugin, or parcel's use of the plugin.

I recognize that you're just being helpful, and I do appreciate that, and also my comment is half-facetious, but..

Responding to someone complaining, "The tooling for X is too complex, there's too much of it" by saying, "Here's the answer -- another tool," is maybe just a little bit silly.

The parent comment was complaining about the number of tools and configuration necessary. Parcel wraps a bunch of those tools up in an easy to use package, and requires zero configuration for many use-cases.

Uh, I don't know how it is now, but back (10 years ago) when I used Maven on a day to day basis, it was a complete nightmare. Editing XML "human readable" files to get into a working configuration was tedious and time consuming. Same with Ant.

I won't say that JavaScript is amazing (I don't like it myself), but even reading the name Maven brings me back painful memories.

Here's what modern ClojureScript setup and workflow looks like: https://github.com/ClojureTO/JS-Workshop

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

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

Scala.js is also an option.

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.

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

Slinky React (https://slinky.dev)

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

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

Scalably Typed (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.

I reimplemented flux example in scala.js a few years ago. It really looks great, not so different from the js code but all strongly typed. https://github.com/forty/scala-js-flux-example

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

We did, GraphQL is the new XML.

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

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.

How so?

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

https://github.com/graalvm/graaljs

J2cl (successor to GWT) produces even smaller code.

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

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

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

oh, i know now

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.

Reply on news.ycombinator.com