5 ms·

Great work on the tutorial. I'm sure it took a lot of time to setup, and it seems well written. However I simply won't believe that setting up a simple React a

• juddlyon 10y ago
  Exact same feeling here, well put. I recently started Tyler McGinnis' excellent React.js Fundamentals and the entire first section of the course is setting up Webpack, Babel, etc. Once you're set up there, then you need to decide how you'll handle routing, AJAX - and so on. The older I get the more I hate third party dependencies. You're asking for trouble.
• MatthewPhillips 10y ago
  Check out DoneJS which gives you everything you need: https://donejs.com/Guide.html https://donejs.com/Guide.html donejs add app my-app cd my-app donejs develop A full environment with hot module swapping included, code-splitting for production builds, etc. No configuration required.
  • Cyph0n 10y ago
    I might look at that for my next frontend project. Thanks for the link.
• RobertKerans 10y ago
  There are simpler ways; I don't mind webpack, I just find it hideously over complex at times; if a large % of React tutorials preface the part you want to read with long, differing, detailed explanations as to how to set Webpack up, I think there's something wrong. Brunch works well, for example this is simpler: npm i -g brunch brunch new myApp -s react cd myApp npm start // server starts on port 3333 That's just basic react app (here's an idea, why not add incrementally as things are needed???). Brunch doesn't do hot reloading ATM, but otherwise it Just Works, and is deployable and very extensible based on need. So normally I'd go nuts and put sass, JS' staging features, a test framework in for dev. And redux, a router, immutability for the app. But only the bit above this paragraph is needed to get started with an app, not a toy, pretend one, an actual app. v0v npm i --save-dev sass-brunch ava babel-preset-stage-0 npm i --save redux react-router immutable some-other-shiny-react-library
  • mikewhy 10y ago
    (Warning: shameless self promotion ahead) I wrote parched-tasks-webapp, heavily inspired by Brunch, but built on top of gulp and browserify. It does have hot reloading. Say you want to build a font from .svgs: npm install --save parched-webfont mkdir -p app/assets/glyphs/ Now you'll get an icon font from any SVGs in that folder. Here's an example app to try out: https://github.com/bravenewworlddev/parched-example-app https://github.com/bravenewworlddev/parched-example-app
  • Cyph0n 10y ago
    Brunch looks pretty cool actually.
    • RobertKerans 10y ago
      It's been around for ages (2011), and I still don't think anything else has it beat in terms of 'get developing an app immediately'. It hasn't really got any magic, and yet it mostly just works out-of-the-box without any configuration. Some of the stuff surrounding it is a little out of date (for example, the Sass package is a bit flakey at times, though that can generally be fixed by just blowing away node_modules and `npm i` reinstalling), but it's used as the frontend build system for the Elixir web framework Phoenix, so it's been getting quite a bit of TLC recently. It also only got proper, inbuilt NPM support near the end of last year (though that can occasionally be flakey), which I guess is one of the major reasons it hasn't had a lot of love vs Webpack, or Grunt/Gulp (w/Browserify) prior to that.
• BinaryIdiot 10y ago
  I completely agree with you and this is a large part of why I simply avoid Webpack, Babel and other, similar tools. Yes they can be useful but they are completely unnecessary. Yes I said it. Everyone wants to get into the latest and greatest ASAP and this completely disregards the entire project. I would love to use EMCAScript 6 too but you know what? I don't want all the additional dependencies of babel, the configuration and the setup to run my code through it constantly just to test my code. I will wait 5 years when it's available enough on the client machines that I work with and then I will use it. Sometimes I feel like the "old timer" complaining about all the new wizbang things but at the end of the day I don't even care because my build will run, with minimal dependencies, out of the box after cloning the git repo. It's reproducible. It takes seconds at most and it's debuggable without trying to figure out how to use source maps inside of chrome.
• hokkos 10y ago
  1. you don't need them all, but for using the latest ES future spec and ideas and hot reloading they are needed. es2015 : to use ES6, stage-0: all babel plugins: async/await, 22, trailing comma a(1,2,), spread {1, ...a}, and more : http://babeljs.io/docs/plugins/preset-stage-0/ http://babeljs.io/docs/plugins/preset-stage-0/ the react plugin is to transform the JSX syntax <component/>, and react-hmre is a preset for hot reloading. 2. we need webpack to bundle the js, jsx, css, images if they are small or use them as asset if they are big. With Gulp you have to re-create painfully what webpack already offer. Webpack is declarative configuration, gulp is complex plumbing. 3. Webpack is powerful, but i am pretty sure the average webpack config file is way less the size of gulps files. 4. PostCSS is more powerful and can strongly link your postcss and component class without having to invent a complex and tedious naming style. 5. PostCSS make terser and safer css. 6. this is exactly the use of plugins for webpack. 7. because you want to have a dev and production mode, in dev mode react test lot of thing like properties type and invariants, you don't want that in production mode because it slow things. Also if you want to make different variants of your project, webpack can at compile time use those env variables to remove some functionalities just put an if (env.CLIENT === "bigcorp") {...} and webpack with the help of uglify will remove or add the code in the then part. 8. each lib has a reason and is orthogonal to one another. 9. to load an asset json file as a parsed JS object with the syntax like you would import a module. very useful. 10.-> 13. webpack is used for all assets and to find the tests and to present them to mocha et al. lot of them a dev dependencies it means you can deactivate them and still ship your product.
  • Cyph0n 10y ago
    Wow, thanks for going through them one by one!
• mhink 10y ago
  To reiterate the top comment up above, the idea of this tutorial is to explicate everything a front-end dev might need to know. Furthermore, the tutorial is deliberately throwing in wrenches here and there (problems with loaders and such) in order to convey "how might one approach a similar problem". You're absolutely correct that most of this is, strictly speaking, unnecessary to get a basic React project off the ground. But one idea I don't think gets credit from folks not actively involved with front-end development is that medium-to-large scale front-end developers have very few choices regarding the runtime environment of their code- especially at B2C companies. Your scripts have to eventually be Javascript, and your stylesheets have to eventually be CSS. It's incredibly tedious to write reams of this stuff in a way which works across browsers. Moreover, libraries which abstract across browser differences (like jQuery) need to be transmitted to the client, and eat up runtime. If you're looking to just hack around with this stuff, try just using one piece at a time. It's relatively easy to just `npm install --save-dev babel-cli` and use it completely independently of Webpack- just letting it happily do its transformation thing. 1. Babel "presets" are basically just individually-packaged sets of syntax transformations that Babel can uses to transpile your code into ES5-compliant Javascript. If you don't give it a preset, Babel will happily transform your code into... exactly the same code. If you give it the ES2015 preset, it will transform ES2015 syntax constructs into equivalent ES5 constructs. If you also add the JSX preset (as is common in React projects), it will convert JSX syntax into the corresponding React function calls. For instance, <span className="hello" /> would be converted into React.createElement("span", { className: "hello" }). Various other presets apply other transformations, but the general idea is to allow developers to begin using language features in their codebase which don't have full support across browsers. 2. The thing with Gulp is that it's a great general-purpose Javascript build system, but its primary use case became transpiling and packaging assets for single-page applications. Integrating these build steps into a pipeline tended to be frustrating- there was a disconnect between what people wanted to do (I just want my assets transpiled, compressed, and bundled, kplzthx) and what they had to implement to do that (writing and wiring up Gulp tasks). Webpack kinda turns that on its head- it implements bundling via its various plugins. 3. Because this tutorial is using a lot of Webpack loaders, and until you kinda grok loaders, it's going to be unclear what's going on. 4. From my understanding (which is admittedly rather limited), postcss is very similar to babel: the idea is to allow you to transpile different syntaxes into "standard" CSS. The analogy goes sort of like "sass/less : postcss :: coffeescript : babel". Again, it's a power tool. Personally, I use Webpack's sass-loader, because I already know SCSS pretty well and I haven't had the time to really look into postcss. 5. How much CSS wrangling have you done in your career? Lemme tell you, CSS can be a massive pain to deal with once your app reaches a certain size, and that can't always be managed fully by methodologies like SMACSS. These are power tools which (are intended to) allow front-end developers to establish some amount of control over a language that's interpreted dozens of different ways, depending on the browser it runs on. 6. That bit did seem slightly extraneous- although I do appreciate that part of the tutorial is going into detail about how I might finagle Webpack to do exactly what I need it to do. 7. Because the output of these tools needs to be different for development vs. production. A comparison in systems languages might be building a C program at low optimization levels and with debugging symbols during a development build, and then a highly-optimized version during a production build. 8. Yes, so many libraries. Other languages (for better or for worse) have extensive testing frameworks, but fully testing web applications also requires means to simulate a browser so you have a good testing environment in the first place. Remember, this is a tutorial for a large-scale web application- automation and consistent testing is crucial unless you actually like paying tons of money for a bunch of QA engineers. 9. All this does is transform pure JSON files into Javascript modules. Literally, this all it does: "https://github.com/webpack/json-loader/blob/master/index.js" https://github.com/webpack/json-loader/blob/master/index.js". Any time you see a loader, what you're getting is a transformation from a source format into a Javascript module (which webpack then compiles into its Javascript bundle). 10. See 8.
• sdnguyen90 10y ago
  This is how I start off a React app: $ npm install --save react react-dom $ npm install --save-dev webpack webpack-dev-server babel-core babel-preset-es2015 babel-preset-react react-addons-test-utils /webpack.config.js module.exports = { entry: 'src/index.js', output: 'dist/bundle.js', module: { loaders: [{ test: /\.jsx?$/, exclude: /node_modules/, loader: 'babel', query: { presets: ['es2015', 'react'] } }] } } /src/index.js import React from 'react'; import ReactDOM from 'react-dom'; const MyRootComponent = (props) => { return <div>Hello World</div> }; ReactDOM.render(MyRootComponent, document.getElementById('react-app')); /static/index.html ... <body> <div id="react-app"></div> <script src="bundle.js"></script> <body> ... start the web server $ webpack-dev-server --content-base static/ There is nothing forcing you to use all the extra dependencies. You can build a full app without them.
  • Cyph0n 10y ago
    Yep, that looks much cleaner and easier to reason about. Thanks for the sample config file.
  • dan15 10y ago
    Out of curiosity, why did you write the function like this: const MyRootComponent = (props) => { When it's shorter and more obvious what's happening if you write them like this: function MyRootComponent(props) {
    • alaskamiller 10y ago
      "An arrow function expression has a shorter syntax compared to function expressions and lexically binds the this value (does not bind its own this, arguments, super, or new.target). Arrow functions are always anonymous." https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
      • throwanem 10y ago
• insin 10y ago
  > So many things to keep in mind, so many dependencies, so very many points of failure. If just one of these libraries is abandoned, or has a breaking change, your entire development environment is dead. Is this the current state of frontend web dev, or are these guys just overdoing it for the sake of the tutorial? This tutorial is trying to guide you over the initial hump with the tooling by letting you hit the issues you'd hit if you were learning it on your own (like dependencies which need tweaks to your Webpack config to work properly like sinon, enzyme, moment...). They _could_ have handed you a completely pre-baked config and got to Hello World in step 2, but you wouldn't have learnt anything about the tooling. In terms of a development library you depend on being abandoned or broken, I've extracted my React development environment out into a separate npm package [1] and it's still using Babel 5, auto-prefixer loader (which is deprecated in favour of using PostCSS directly) and is working around every version of babel-runtime v5 after 5.8.29 containing a broken version of an important module. By pinning your dependencies, you can keep using old or deprecated versions of things until you're ready to upgrade, and by managing development tools in an external module you can upgrade your projects when you're good and ready by bumping a version number. If you do that, starting a React project (or any other project which gets tool-heavy for apps of any size) can be a 1-step proceess you can have an understanding of the tooling, and you have a way to keep it manageable over time. [1] https://github.com/insin/nwb#nwb https://github.com/insin/nwb#nwb
  • jjnoakes 10y ago
    I am not a front end dev so this is a serious question. The new shiny seems to be using dependencies straight from git and vendoring them. Presumably new versions come out because they fix bugs or security issues. How do you keep your projects up to date? Do you manually check every dependency in your project once in a while? Do you have some automation which alerts you to security issues in a dependency of yours? If you decide you need to stay on an older version, is someone backporting fixes? Is there a curated set of packages that are known to work together? When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems? Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features? (Which basically isn't easy to do with how fast the landscape is evolving). I'm curious about solutions to these problems.