3 ms·

https://github.com/Jon-Biz/simple-static-react-firebase/blob/master/package.json#L21-L32 https://github.com/Jon-Biz/simple-static-react-firebase/blob... Sorry,

by xuejie 10y ago

https://github.com/Jon-Biz/simple-static-react-firebase/blob/master/package.json#L21-L32 https://github.com/Jon-Biz/simple-static-react-firebase/blob... Sorry, but with those many dependencies, I could hardly call that minimal.

WalterSear 10y ago
The boilerplate you have to write (and handle) is minimal. This is more important to me than the number of packages I have to install for development. And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)
- Klathmon 10y ago
  Yeah, how is this a lot of dependencies? babel-core, babel-loader, babel-polyfill, babel-preset-es2015 and babel-preset-react can be considered one dependency (it's babel...). react and react-dom are another. webpack, the dev server, and 3 webpack plugins can be considered a 3rd. That's 3 "real" dependencies. If that's a lot, then i'd love to see a "real" minimal setup. Just because javascript dependencies tend to take the unix philosophy to the extreme doesn't mean that each of those should be treated equally.
  - pavlov 10y ago
    JavaScript dependencies are to Unix philosophy as C++ is to object-oriented programming... In name only, and seemingly in complete misunderstanding of the concept.
    - Klathmon 10y ago
      Can you expand on what you mean? IMO JS hits all of the points of the unix philosophy: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. 3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. 4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill). If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed. it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.
chvid 10y ago
Should some of those not be dev-dependencies?
- pietro 10y ago
  Yes, the ones related to Babel and Webpack.
  - diggan 10y ago
    Well, in fact all of them should be devDependencies because the artifact of a build would contain everything, none of those things would be needed at runtime.
- WalterSear 10y ago
  Pretty much all of them, except for React. Sloppy setup by me :(
girvo 10y ago
Most of those should be "devDependencies", as they're used for build-tooling not for the actual codebase, but I'll be honest I'm right there with you: my major drama with modern front-end dev at the moment is the sheer amount of dependencies that are "required" in a traditional toolset. That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce. There's a balance to be struck here, and it's a hard problem, I think. [0] https://github.com/garthenweb/bubleify https://github.com/garthenweb/bubleify [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html
- xuejie 10y ago
  I dunno, I think what you are describing is a practical stack, not a minimal one. For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code. But in that sense I might be trolling here since nobody actually does that :)

by xuejie 10y ago

WalterSear 10y ago

The boilerplate you have to write (and handle) is minimal. This is more important to me than the number of packages I have to install for development. And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)

Klathmon 10y ago
Yeah, how is this a lot of dependencies? babel-core, babel-loader, babel-polyfill, babel-preset-es2015 and babel-preset-react can be considered one dependency (it's babel...). react and react-dom are another. webpack, the dev server, and 3 webpack plugins can be considered a 3rd. That's 3 "real" dependencies. If that's a lot, then i'd love to see a "real" minimal setup. Just because javascript dependencies tend to take the unix philosophy to the extreme doesn't mean that each of those should be treated equally.
- pavlov 10y ago
  JavaScript dependencies are to Unix philosophy as C++ is to object-oriented programming... In name only, and seemingly in complete misunderstanding of the concept.
  - Klathmon 10y ago
    Can you expand on what you mean? IMO JS hits all of the points of the unix philosophy: 1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features". 2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input. 3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them. 4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them. Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill). If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed. it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.

chvid 10y ago

Should some of those not be dev-dependencies?

pietro 10y ago
Yes, the ones related to Babel and Webpack.
- diggan 10y ago
  Well, in fact all of them should be devDependencies because the artifact of a build would contain everything, none of those things would be needed at runtime.
WalterSear 10y ago
Pretty much all of them, except for React. Sloppy setup by me :(

girvo 10y ago

Most of those should be "devDependencies", as they're used for build-tooling not for the actual codebase, but I'll be honest I'm right there with you: my major drama with modern front-end dev at the moment is the sheer amount of dependencies that are "required" in a traditional toolset. That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce. There's a balance to be struck here, and it's a hard problem, I think. [0] https://github.com/garthenweb/bubleify https://github.com/garthenweb/bubleify [1] http://ramdajs.com/0.21.0/index.html http://ramdajs.com/0.21.0/index.html

xuejie 10y ago
I dunno, I think what you are describing is a practical stack, not a minimal one. For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code. But in that sense I might be trolling here since nobody actually does that :)