3 ms·

Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA te

by mythz 10y ago

Yep React's also culpable to npm's "micro module" madness, where often the scope of a npm package is wrapping a single function! Which explains why blank SPA templates requires 1000's of files. But I've got my choice SPA stack down to a solution I'm happy with, where a blank App is down to: - TypeScript (using Type Definitions in npm package or @types) - JSPM (package/dep management, module loader + bundler) - Gulp (automate all tasks in reusable scripts) - React JSPM `bundle` feature also lets you combine all React's deps into a single .js file which speeds up iterative dev workflow by combining the 100's of runtime dep requests down to 1 .js file. Also using jspm@beta means I don't have to configure a separate tool like Webpack as JSPM reuses your dependencies where its 'build' feature rolls up your app into a single stand-alone, minified .js file to give you an optimal packaged app for deployment. Using the TypeScript integration in VS.NET means I don't have to run any external processes or watchers as TypeScript automatically re-compiles every modified .ts file on save where it's ready by the time I reload the page. Unfortunately it looks like npm has passed the point of no return and every developer is stuck building on this complexity. Honestly if it wasn't for the potential of React Native I'd strongly consider moving to Vue.js (https://vuejs.org/v2/guide/ https://vuejs.org/v2/guide/) since it's still a modern well supported SPA fx, but lets you reference a single script include. Ideally React would offer a simplified solution where it also maintains a parallel "react-dev" npm package with no deps, but it's unlikely since it goes against npm's micro module madness trend - but it's something I'm keen on exploring if I ever get the free time.

magic_quotes 10y ago
> React's also culpable to npm's "micro module" madness I love comments like this. Ever heard of "modularity shaming"? Now it's React's fault apparently.
- mythz 10y ago
  It's not just React's fault, but they're also following the trend.
  - magic_quotes 10y ago
    No, that's simply not true.
    - mythz 10y ago
      > No, that's simply not true. Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective. Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!
      - magic_quotes 10y ago
        Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum. > Here I am thinking that 20k+ files This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind of jar-like packaging format. I'm surprised node.js/npm doesn't have something like that implemented yet.
        hizanberg 10y ago
        > Where exactly does it promote micro-modules? Start from any recommended starting React dev template and count the no of files, seperate tools, config files and runtime dependencies required to maintain an iterative dev workflow. The dependencies have gotten so out of hand Facebook's even developed their own package manager to manage it since npm has issues managing it properly. > For example, React was repeatedly criticized for not splitting virtual-dom... That's for production deployments, it doesn't represent the complexity and cognitive overhead required during development. > I'm surprised node.js/npm doesn't have something like that implemented yet. There's a number of bundlers available, it just requires integrating more tools and maintaining more config files.
        mythz 10y ago
        I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy. The fact there's so many deps mandates additional tooling to manage and bundle them down to a manageable number of deps during development. Facebook's recommendation for a hello world app [1] wants you to use their package manager, Webpack, Babel, Flow, a Linter, CSS preprocessor, their test runner, an embedded HTTP server just for starting off, building any meaningful App requires more dependencies where eventually you'll also consider a module loader. Then you're going to need to package/deploy your App and if you go off-script you'll need to manage and understand how all the different moving parts work together which you'll also need to know when wasting time chasing down dependency conflicts and tooling integration issues after package updates. Your point about their being only 2 dependencies is completely inconsequential for development and shows inexperience in the recommended state of the art React SPA development. [1] https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md https://github.com/facebookincubator/create-react-app/blob/m...

by mythz 10y ago

magic_quotes 10y ago

> React's also culpable to npm's "micro module" madness I love comments like this. Ever heard of "modularity shaming"? Now it's React's fault apparently.

mythz 10y ago
It's not just React's fault, but they're also following the trend.
- magic_quotes 10y ago
  No, that's simply not true.
  - mythz 10y ago
    > No, that's simply not true. Wow, really?! I stand corrected! I'm glad you took the time to bestow this illuminating perspective. Here I am thinking that 20k+ files for a Hello World App was a bit much but your response really cleared things up for me, thanks!
    - magic_quotes 10y ago
      Can we please stick to the facts? Where exactly does it promote micro-modules? For example, React was repeatedly criticized for not splitting virtual dom implementation into a separate npm package. That's completely opposite side of the spectrum. > Here I am thinking that 20k+ files This are separate files and not necessary as many separate modules. Different things, really. That's ought to be solved with some kind of jar-like packaging format. I'm surprised node.js/npm doesn't have something like that implemented yet.
      - hizanberg 10y ago
        > Where exactly does it promote micro-modules? Start from any recommended starting React dev template and count the no of files, seperate tools, config files and runtime dependencies required to maintain an iterative dev workflow. The dependencies have gotten so out of hand Facebook's even developed their own package manager to manage it since npm has issues managing it properly. > For example, React was repeatedly criticized for not splitting virtual-dom... That's for production deployments, it doesn't represent the complexity and cognitive overhead required during development. > I'm surprised node.js/npm doesn't have something like that implemented yet. There's a number of bundlers available, it just requires integrating more tools and maintaining more config files.
      - mythz 10y ago
        I've already made this clear, a blank Hello World App requires 20k+ files and 100's runtime dependencies. It literally takes minutes to download everything which I've had often fail. npm installs of SPA templates are one of the few things that can cause my MBP CPU to burn and HDD to thrash for long periods of time where I'd expect it to consume a non-trivial amount of energy. The fact there's so many deps mandates additional tooling to manage and bundle them down to a manageable number of deps during development. Facebook's recommendation for a hello world app [1] wants you to use their package manager, Webpack, Babel, Flow, a Linter, CSS preprocessor, their test runner, an embedded HTTP server just for starting off, building any meaningful App requires more dependencies where eventually you'll also consider a module loader. Then you're going to need to package/deploy your App and if you go off-script you'll need to manage and understand how all the different moving parts work together which you'll also need to know when wasting time chasing down dependency conflicts and tooling integration issues after package updates. Your point about their being only 2 dependencies is completely inconsequential for development and shows inexperience in the recommended state of the art React SPA development. [1] https://github.com/facebookincubator/create-react-app/blob/master/packages/react-scripts/template/README.md https://github.com/facebookincubator/create-react-app/blob/m...