4 ms·

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 a

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 https://twitter.com/dan_abramov/status/1097309141075456000

sisk 8y ago
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-package-management https://blog.npmjs.org/post/178027064160/next-generation-pac...
- acemarke 8y ago
  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 https://twitter.com/acemarke/status/1073593305378754560
- swsieber 8y ago
  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.
pier25 8y ago
> 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.
- acemarke 8y ago
  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 https://github.com/jador/react-hyperscript-helpers [1] https://github.com/developit/htm https://github.com/developit/htm
  - pdimitar 8y ago
    Sure, but your claim of "you just need a pair of <script> tags" is no longer true then, is it? I can start building a house with a hammer and a shovel. Doesn't mean I can build the entire house with them alone.
    - acemarke 8y ago
      My claim of "you only need two script tags to write a working React app" is entirely accurate. That _does_ limit you to just `React.createElement()`, which is the core React API. If you don't want to call `React.createElement()` every time (whether or not you alias to to something like `h()`), then you either use JSX (and a build step), or one of the other options like the ones I listed. Pointing at that, and then claiming it's insufficient for "building an entire house", makes it look like there's some goalposts being shoved down the field.
      - pdimitar 8y ago
hdra 8y ago
> 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.
_bxg1 8y ago
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.
- arvinsim 8y ago
  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.
  - _bxg1 8y ago
    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.
    - _bxg1 8y ago
      And for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.
ratdiary 8y ago
Sounds like a job for Blazor! https://blazor.net/ https://blazor.net/

sisk 8y ago

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-package-management https://blog.npmjs.org/post/178027064160/next-generation-pac...

acemarke 8y ago
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 https://twitter.com/acemarke/status/1073593305378754560
swsieber 8y ago
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.

pier25 8y ago

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

acemarke 8y ago
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 https://github.com/jador/react-hyperscript-helpers [1] https://github.com/developit/htm https://github.com/developit/htm
- pdimitar 8y ago
  Sure, but your claim of "you just need a pair of <script> tags" is no longer true then, is it? I can start building a house with a hammer and a shovel. Doesn't mean I can build the entire house with them alone.
  - acemarke 8y ago
    My claim of "you only need two script tags to write a working React app" is entirely accurate. That _does_ limit you to just `React.createElement()`, which is the core React API. If you don't want to call `React.createElement()` every time (whether or not you alias to to something like `h()`), then you either use JSX (and a build step), or one of the other options like the ones I listed. Pointing at that, and then claiming it's insufficient for "building an entire house", makes it look like there's some goalposts being shoved down the field.
    - pdimitar 8y ago

hdra 8y ago

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

_bxg1 8y ago

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.

arvinsim 8y ago
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.
- _bxg1 8y ago
  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.
  - _bxg1 8y ago
    And for a tooling example, VSCode is basically a much more cohesive and holistically-designed version of Atom.

ratdiary 8y ago

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