Comparing JVM alternatives to JavaScript

Re:Comparing JVM alternatives to JavaScript by tlrobinson on Sunday April 21, 2019 @11:48PM (#19716377)

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.

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by konsoletyper on Monday April 22, 2019 @04:03AM (#19717278)

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.

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by geezerjay on Monday April 22, 2019 @03:35AM (#19717190)

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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by tlrobinson on Monday April 22, 2019 @06:45PM (#19723808)

> 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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by blunte on Monday April 22, 2019 @03:31AM (#19717175)

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.

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by rat9988 on Monday April 22, 2019 @04:03AM (#19717279)

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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by runako on Monday April 22, 2019 @08:16AM (#19718291)

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.

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by brlewis on Monday April 22, 2019 @08:45AM (#19718441)

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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by runako on Monday April 22, 2019 @10:06AM (#19719012)

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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by brlewis on Monday April 22, 2019 @10:14AM (#19719077)

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

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by runako on Monday April 22, 2019 @11:28AM (#19719627)

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.

[ Parent | on HN ]

Re:Comparing JVM alternatives to JavaScript by novaleaf on Tuesday April 23, 2019 @12:13PM (#19729997)

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"

[ Parent | on HN ]