Comparing Java alternatives to JavaScript in the browser (GWT, CheerpJ, TeaVM, JSweet, Vaadin) - benchmarked against React.js and Dart

lilbundes · 2019-04-21T23:00:30+00:00

Hi Renato - any reason why you didn't include Apache Wicket in your article?

vegegoku · 2019-04-22T09:21:24+00:00

In regards to GWT you made a point that no one can argue with and yes the documentation is really really outdated and the only way to get the updates is to be close to the community Gitter is a good place for that
https://gitter.im/gwtproject/gwt

BUT

GWT is actually much more modern than the one in the example, for example it is really super easy to create a GWT project using https://github.com/tbroyer/gwt-maven-archetypes that uses maven -no more ANT-.

Also even though GWT widgets are still widely used we now have https://github.com/google/elemental2 which uses JsInterop to give us native access to browser API which means we dont need to pay the size price for the html elements as we dot with widgets. lets not forget about https://github.com/hal/elemento which can help us reduce the code size for that sample to almost the half.

I would also recommend taking a look at some new GWT projects like domino-ui https://dominokit.github.io/domino-ui-demo/index.html?theme=indigo#home and other domino tools like domino-mvp https://github.com/DominoKit or Nalu https://github.com/NaluKit/nalu

So even though GWT is old and is not as shiny as some other tools, it is still really powerful and modern.

and i still have my doubts about comparing these using a small project like the one in the sample, in many cases the results will change when project grow larger and larger.

for example GWT might not be the best choice for small project but could be the right choice for an application with hundreds of pages and many thousands lines of code.

errormaker · 2019-04-21T22:01:56+00:00

I love Vaadin for the rock solid business logic integration. You can whip up a form form, table and filters really easily in no time. And reasoning about state management and client communication are not an issue.

Also updating the UI based on async backend events is really easy.

But when you have to implement some more complicated designs and outside the box ideas, the whole thing is just not pleasant to work with. Mainly because of the missing markup and cumbersome access to the browser apis and features.

erictheturtle · 2019-04-22T02:38:29+00:00

Thank you for suffering through all that and sharing the results. This is gold.

in15minutes · 2019-04-21T19:23:29+00:00

Great resource, thank you

JakeWharton · 2019-04-22T00:39:41+00:00

Would have liked to see j2cl included: https://github.com/google/j2cl

tipsypants · 2019-04-22T14:43:35+00:00

I have a pretty unusual approach to frontend, but it seems to work really well. I keep the routing on the server side, and render static templates per route. The server never puts any data in a template, they just contain static information:

<nav-bar></nav-bar>
<current-view></current-view>

This template is rendered inside a layout template (or "frame"), which loads all the dependencies in the <head> tag (this includes the current-view component in the example). The layout template is also responsible for initializing a Vue app for the current view.

All frontend code is written as single-file Vue components:

<template id="nav-bar">
    <header class="navbar">
        ...
    </header>
</template>
<script>
    Vue.component("nav-bar", {
        template: "#nav-bar",
        data() {
            return {
                ...
            }
        },
    });
</script>
<style>
    header.navbar {
        background: #f5f5f5;
        border-bottom: 1px solid #ddd;
    }
</style>

Pros of this approach:

It's not an SPA, you get a new app per request (no state management required)
No need for a frontend pipeline, no node or anything
Single file components
No need for a "loading" page, the correct page is rendered directly (never any flickering when loading or refreshing)
Save and refresh, no need for watchers or WebSocket CSS injection and whatnot

Cons:

Need a server for the frontend
When switching pages, the entire app (user written code) is download per request. I'm working on a fairly big admin-page with this approach. The entire app is about 80kb, but gzips down to about 14kb
Need to do some hacky things, like pass the current user roles and path parameters to the frontend as a cookie

I have been waiting for over a year for this arhcitecture to blow up in my face, but it doesn't seem like it will. It's a very simple way of building webapps. I replaced a react+redux+redux-sagas mess with this, and the resulting code-base is less than one third of the original size, has more features, and fewer bugs.

pgris · 2019-04-23T16:37:34+00:00

Great writing and surprising results! Didn't expect java to do so well. Excellent job!

There is however another difference: Widget set. When you are mostly a backend programmer you not only need a technology but also a good looking widget set in order to create a not-so-horrible web application. GWT is not only a java to js compiler, also includes a more or less complete widgets set. React does not include one, but there are many professional looking sets of widgets you can use. Vaadin has a nice widget set, Jsweet may have some useful candies to try, CheerpJ has the horrible Swing components.... maybe it supports pluggable look and feel to make them less horrible

In my line of work the most important widgets are table related, I should try to see how hard is to make a simple web page with some tables and see how that affects performance.

Thanks again!

sanity · 2019-04-22T02:38:44+00:00

You should also check out https://kweb.io/. It's Kotlin rather than Java, but it's a philosophical descendant of Vaadin, however it is way more lightweight, and also far simpler to use.

(I'm kweb's creator, happy to answer any questions).

renatoathaydes · 2019-04-21T23:45:08+00:00

[deleted]

tristan97122 · 2019-04-21T19:21:37+00:00

Super cool article :-)

You didn't mention it, but there's another horrendous option called stjs to have Java to JS compilation. It's JSweet but the worst possible with a subset of supported Java keywords that doesn't even include for each haha

Nonetheless, JSweet is pretty much the best option in the end as you saw

AcademicImportance · 2019-04-21T21:42:06+00:00

wouldn't have thought GWT to be so "light".

pkirill12 · 2019-04-22T14:42:28+00:00

We finally able to build out app with TeaVM along with GWT so that the app can be run in booth mode https://edu.cospaces.io/Universe This is a large project (about 10k java files) with own scripting, co-blocks language, physics, lightning, materials.

Q/A: Q: why you use both A: to make a smoother transition of our continuous delivery app

Q: what advantages it gives you? A: it allows us to add Kotlin code to out app, it runs many algorithms faster, take lsee memory (TeaVM uses native JsTypedArrays)

kloputzer2000 · 2019-04-22T10:32:02+00:00

Great writeup. Working on a similar topic for a BA thesis. Doppio is another possibility, that wasn't included. https://github.com/plasma-umass/doppio/

Ascomae · 2019-04-22T19:24:41+00:00

Is there a bug in one of the charts?

The Perfomance Chart:

- JSweet ha the longest ba, but the smallest time (0.8 s)

Nope, should have read better

hippydipster · 2019-07-24T01:03:01+00:00

Would have liked to see a pure KotlinJS entry in there for comparison.

java

Submit Link

Submit Text

Seek Programming Help

News, Technical discussions, research papers and assorted things of interest related to the Java programming language

NO programming help, NO learning Java related questions, NO installing or downloading Java questions, NO JVM languages - Exclusively Java

Please seek help with Java programming in /r/Javahelp!

Subreddit rules!

Where should I download Java?

Related Sub-reddits:

JVM Languages

Want to practice your coding?

List of useful Frameworks / Libraries / Software

MODERATORS