Hacker News Reader

Comment by acemarke | Hacker News Reader

Note that the listed discussion is specifically about projects generated by the Create-React-App tool, not React itself. React has always been usable by just adding a pair of `<script>` tags to any HTML page.

Dan Abramov pointed out [0] that:

> in terms of feature set (test runner, devserver, compiler with support for bundle splitting and optimizations, error overlay with editor integration, static code checker) it’s comparable to a small Xcode.

> It’s valid criticism that tools like Xcode are installed once whereas react-scripts is per project. But the upside is you never have the “different projects demand different Xcode versions” problem. And everything runs on CI thanks to full encapsulation.

> I’m hoping approaches like Yarn Plug’n’Play will give us best of both worlds. Shared install for the same versions between projects but with isolated and versioned tooling.

[0] https://twitter.com/dan_abramov/status/1097309141075456000

View on HN

The bigger issue is less about weight (most of that doesn't end up in the final bundle anyway) and more about the fact that each of those dependencies is a point of possible a) breakage and b) security compromise. The latter in particular has been a rising issue with NPM's micro-packages trend.

I don't know how that problems is going away. Javascript doesn't have a great standard library and it's hard to impose restrictions on which packages/features/functionalities should be the "defacto" ones.

The strength of JavaScript is also the problem: it's really easy to create and distribute really flexible and dynamic code. This encourages a massive, vibrant ecosystem of packages which are extremely modular and flexible, and often tiny. So you end up building sandcastles out of thousands of grains of sand instead of LEGO houses.

What we probably need to do is walk that back a bit at a cultural level, and make our libraries just a bit more cohesive and self-contained. There are a few libraries like Lodash and Ramada that aim to be general-purpose toolkits, and Vue and Angular are good examples of reactive libraries that come with their own state management, plus some other stuff. Of course, the latter probably (I'm not actually positive) carry their own big lists of npm dependencies.

And for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.

> I’m hoping approaches like Yarn Plug’n’Play will give us best of both worlds. Shared install for the same versions between projects but with isolated and versioned tooling.

TBH, I personally am not too concerned with the duplication/disk usage, but the number of dependencies it pulls is a pretty big one.

> React has always been usable by just adding a pair of `<script>` tags to any HTML page.

Yes but good luck with React.createElement(). React without JSX is really a pain to use (or Preact, Inferno, etc).

Vue is much more straightforward for those simpler cases where you don't need/want to setup Babel, Webpack, etc.

There's a number of options available if you don't want to use JSX.

For example, if you prefer to use small wrapper functions like `h(MyComponent)` and `div()`, there's `react-hyperscript-helpers` [0].

More recently, Jason Miller published `htm` [1], which provides near-JSX syntax using ES6 template literals, and no build step required. It appears to be a very viable alternative to JSX in many ways.

[0] https://github.com/jador/react-hyperscript-helpers

[1] https://github.com/developit/htm

You know that jsx just compiles down to those calls right? Heck if all you need is just the transpile of jsx, typescript's compiler will do it just fine from the command line, no config to setup.

Obviously, but you are missing the point.

> Yes but good luck with React.createElement(). React without JSX is really a pain to use (or Preact, Inferno, etc).

What's painful about it? I prefer it without JSX, personally; JSX is a pretty simple syntax transform that doesn't really gain you anything that I can see, makes manipulating props a lot clumsier, and needs extra tooling. Most of the time it's almost identical with or without JSX, but when there is a difference, I've always found without to be smoother and clearer. You definitely want to assign React.createElement a shorter name, though.

totally agree.

Not just because it's harder to use without JSX (and JSX is a great idea), but also because every Stack Overflow answer assumes you're using Webpack and JSX. For a beginner, choosing not use JSX or Webpack, etc just makes the learning cliff steeper.

Just FYI, you can easily include a @babel/standalone script to get JSX in your script tags.

https://reactjs.org/docs/add-react-to-a-website.html#quickly...

Oh this is good!

How is the browser support for this?

Note that running the transform in-browser on anything more than a "hello world" is going to be relatively slow. It's only useful for cases like a "single HTML file React example, with JSX syntax capability", and is _not_ recommended for any kind of production use.

Thanks, I saw that after writing my comment.

It seems Vue is definitely the simpler choice to write reactive components in projects without a build chain.

As I wrote up-thread, Jason Miller's `htm` library seems to be a very nice alternative to JSX that does not require a build step:

https://github.com/developit/htm

That might work in some use cases, but unfortunately tagged template literals require greenfield browsers. Vue 2 works in anything that runs ES5.

It works well, but so slowly. I tried it for a real project, decided against it. Precompiling JSX into ES6 works fine, and the result is incredibly fast.

In addition to Yarn PnP, the folks at npm are still working on tink[0] which is early but useable right now.

[0]: https://blog.npmjs.org/post/178027064160/next-generation-pac...

Yep. I've glanced briefly at both PnP and Tink. Both sound neat conceptually, I just haven't dug far enough to know what the differences are in terms of actual approaches and implementation. Also haven't had a chance to play with either yet.

Long-term, stuff like the size of `node_modules` seems very solvable.

Simultaneously with that, I do think that there'd be benefit if some of the larger JS build tools started evaluating their own transitive dependencies and submitting PRs to inline some of the smaller pieces somehow [0].

[0] https://twitter.com/acemarke/status/1073593305378754560

Unfortunately, the ts compiler neither supports yarn pnp or rink right (and angular doesn't either). It's the biggest blocker for me personally - but I've played with yarn pnp and it's great.

Sounds like a job for Blazor! https://blazor.net/

Reply on news.ycombinator.com