I'm no Javascript Boilerplate Fatigue apologist, but there are many comments in here that are treating this as a "Learn how to use React" tutorial. This is not what is advertised nor the stated reason this article was written.
From the first sentence: "we get a lot of questions about how to build large applications with React and how to integrate external APIs" Large application strucutre, external integrations...not "Hello World"
Of course there is no need for multiple environments, or a robust testing setup, or an icon font, or 6 different webpack loaders to learn the basics of React. This is not a tutorial on the basics of React -- this is written from the perspective of a large production level application. And that "overhead" and "insanity" are helpful for real projects that are staffed by more than one person and need to last more than a week.
It seems absurd that it might take you 2 hours to setup the environment before you get to hello world. But if you are planning to use this as the foundation of a 6 month long project, 2 hours to get everything setup in a sane way is not an issue.
There is absolutely churn in the JS world and some of it does seem unbelievable because things haven't contracted and settled into a steady-state. But don't just levy a blanket "lol fuck javascript tooling" every time you see a complicated setup process; you are doing yourself a disservice by not critically evaluating the choices the author of this post made and determining for yourself if they will benefit your project and/or learning efforts.
The problem with the massive amount of churn is that it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less. I think all programmers, especially ones who read HN, like to learn new things. It's fun to pick up new languages, learn new paradigms, and experiment with different technologies.
What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn.
Sorry, but even the “Getting Started” guide on React's website requires that you have a "CommonJS module system" installed which, if you don't, means you have to make an intelligent choice between Browserify and webpack, which means you have to do some minimal research into what those are (and probably research "babel-js", while you're at it), install one of them using npm, which may require that you install or upgrade node.js which, if you're on a Mac, may require that you install homebrew, which can sometimes open another, deeper can of worms...
And that's just to get your tool chain in place. When you actually get into the tutorial, it starts with "Running a server". Running a server?
I submit that writing even basic, toy applications in React requires a trip to dependency hell and back, unless you already use these tools on a regular basis and keep up with the ever-rapidly-changing debate around build scripts, dependency managers, language preprocessors, etcetera, etcetera.
I have no problem with the article or its goals, but my issue is why is so much configuration even necessary for a "large" frontend JS application?
Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process instead of using pre-made plugins?
We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!
I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded.
The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago.
A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.
It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.
I agree. We've started a project at work that we will maintain for years. We researched the setup for a few weeks and continue to tune it. Once you understand the small components and create a working setup reacct/webpack/babel is much less daunting. This type of article is great when you're trying to ensure you've chosen the most optimal setup for your project yet it isn't for everyone.
To me this epitomizes what I feel as I'm trying to explore options for different front-end frameworks. In this article I'm 30 screens down (literally 30 page down presses) and it's not even finished setting up the environment and dependencies.
Sure, this is something that you only do once, so if it then leads to much better development workflow it makes sense to have a solid investment upfront, but it makes it very hard to compare technologies and make informed decisions given how much up-front "glue" is needed to get a demo application up and running.
I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example.
In fact the whole process is so complex part of the process is "clone this package which has pre-configured parts of the process".
And all of this to glue together a couple of APIs.
This genuinely made me feel ill. The author has done a tremendous service to others - clearly and patiently listing the thousands of steps required to get a basic modern web app up and running. I agree with others that it is often difficult to find all the steps for a process like this in one place. At the same time, this is completely, totally fucking insane.
I feel this way about Node and React sometimes but I'm not sure other environments are necessarily better. In a way the fact that you can do all this in a bunch of text files is pretty elegant. Is installing and configuring Apache and PHP with a bunch of modules that much easier, or does it only appear easier because of apt-get, a2enmod, etc.?
You don't need all of them to create a modern js app. I use just browserify and watchify with node scripts under package.json. Simple to copy and modify for new projects.
I've built a multitude of websites/applications in my lifetime spanning many different programming languages, build systems, tools, etc. From PHP, to python, to golang, to java, and JS. It seems painfully obvious to me that the people complaining about this setup/build system do not fully grasp the power and beauty of the JS ecosystem, more specifically react, redux, time traveling, and hot module reloading. It is without competition, the best development experience I have ever had been apart of. There is no lag time between when I make a change in JS or CSS to when those changes get applied to the application. There's no compiling (even tho there is a compile step), no refreshing the page, no stepping through all your previous steps to get to that part of the application, your changes are patched in real time and available to you automatically.
I guess the saying is true, that haters are going to hate, but there really is no competition in terms of development experience once you grok the ecosystem.
The criticism here is really baffling in how it blames the js ecosystem for the complexity in building large production apps..
I wouldn't find fault with a similar tutorial for "how to set up a production, at scale, rails app with only sever side rendering and zero javascript". Between hosting, cacheing, deployment, worker queues, database provisioning, etc, LOL that tut would be gigantic and that makes sense!
If people are mad that making production client side applications isn't trivially easy, well that just isn't going to happen and that isn't because the js ecosystem is screwed up.
1. Those who know javascript and some major framework
2. Those who are unemployed
Yes we can build apps with just HTML and CSS and put it all in one file and serve it with a one line command, but if we want to be employed and have a website that actually scales we need to follow in the foot steps of the people who have done it.
I've dealt with many technology stacks. If this is the future, we're F#$$%.
Seriously, how can people be blasting older technology like Flash and Flex (which was GREAT), out of the water for not using web standards and then this Frankenstein of a "stack" is going so mainstream.
Sure, there is the VM problem, but the language was good and so was the framework. This looks horrendous and scary. Imagine maintaining this for the next 10 years when "the standards" will have moved on to you "next gen" javascript "framework".
My only way to write web apps has been using micro frameworks, jquery, and small libs that do one thing and one thing only. I can handle serving pages with Go thanks, and I don't need a routing system that looks like a vintage joke. Sorry if I sound jaded, I've been doing this for 15 years.
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 app requires so much overhead. Granted, I have no experience with React, and only marginal experience with frontend web dev.
As I read the tutorial, this is the list of questions I had:
1. Why do we need so many Babel presets? What do they do?
2. Why do we need Webpack exactly? Why not use a traditional build system like Gulp?
3. Why is Webpack so difficult to setup? Are there no pre-configured setups for React?
4. What the hell is postcss? Are Less and Sass out of fashion now?
5. And why all this added complexity to setup CSS? They are only stylesheets for God's sake!
6. Oh, so now we need to configure Webpack to support postcss? The definition of reinventing the wheel. Is there no plugin system for Webpack?
7. Why is it so complicated to setup multiple environments using Node and Webpack?
Phew, looks like we're done -- nope, we're not.
8. So many libraries just to setup a testing environment? I wouldn't be surprised if frontend apps aren't well tested...
9. Ah, we also need a "JSON loader", whatever the hell that is.
10. Great, another CLI tool for testing. And more configuration of course.
11. Webpack once more needs to be configured to support our new testing app.
12. We need a better spec reporter? Why? More configuration...
13. More Webpack configuration.. I'm already sick of it.
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?
I find this all weird because I have the habit of thinking very carefully about every single dependency when I'm writing software. Do I really need it i.e. can the same task be achieved using the standard library? If not, how active is the development of the library (recent activity, issue response time, number of contributors)? How many libraries does it depend on - the fewer, the better? And even with all this, it's still not guaranteed that things will go smoothly!
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/ 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.
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.
> 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.
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
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.
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". 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).
I've been on the fence for quite a while, but a couple of weeks ago I finally bit the bullet and taught myself webpack, ES6, React, CSS modules, Redux, and everything else that comes along with these tools.
It definitely felt like relearning my job (coming from working with Grunt, Backbone and jQuery) and it took a lot of time and effort to really get to understand everything (still learning many new things each day), but man was it worth it. I enjoy working with these tools very, very much and I am able to build apps significantly faster than I could before.
> a couple of weeks ago I finally bit the bullet and taught myself webpack, ES6, React, CSS modules, Redux, and everything else that comes along with these tools
Can you share how you did that? Was it a number of different resources you consulted, or is there some all-in-one resource you found?
This is a really great tutorial, it's rare to find pieces that step you through the whole process with dev/prod and tests without assuming you already understand the arcane setup.
It also shows what an arcane dependency-hell react is... how much boilerplate does it take to get up a map with a valid route? I hope this is something that becomes a bit more standardized/easier as the ecosystem evolves.
The setup required just to get a production-ready idiomatic `hello world` app in React is downright insane. Without the Facebook name behind it, I don't see how React could have ever made it this far.
Foolish of me to keep underestimating the pains that JS developers willingly tolerate.
The problem is that there isn’t really such a thing as an “idiomatic React app”. React is just a view-rendering layer with a small API. You have to put together all the other pieces of your application stack…
I also got frustrated by the setup time for a simple react app, so I make a starter repo that I just clone for all my new projects. It's made to be as simple, light, and understandable as possible while still being useful. Check it out and let me know if you have any questions! https://github.com/hammeiam/react-webpack-starter
First off. Great tutorial! I wish more frameworks their native documentation would come with more real world examples. Redux's fantastic documentation is a step in the right direction but still makes real world solutions a bit too much of a side note.
Regarding Javascript fatigue, I want to share something that greatly helped me.
I have written enterprise applications for Fortune 500s using PHP, Rails, Backbone, Angular, React, Node, Express, Grunt, Gulp, Webpack, Yeoman, Bower, Redux, jQuery, Coffescript, Prototype.js ( remember them!? ), LESS, SASS... Basically whatever was hot at the moment.
Long I've enjoyed learning new things, but after having made a solid investment in Angular only to find out none of it's SEO solutions were really commercially viable the fatigue hit me hard and I gave up on trying to learn new things for a while. I simply stopped caring.
Then I got approached by SpaceX for a JS full stack position. All they told me about the interview beforehand was that it would be very JS heavy, yet no details on what stack or framework they were working with.
To prep I brushed up hard on my basic JS skills. Codeschool.com their JS road trip was very useful. So were "Eloquent JavaScript" and "JavaScript: The Good Parts".
After making that tough but very rewarding investment, learning React, Flux, Redux, Elm etc. all became a breeze. I no longer have any attachment to any framework. They're all just different ways of using JS to me. And no matter what the future brings, no matter how many frameworks and build tools get thrown our way, I don't think ( hope? ) my heavy investment in Javascript will soon disappoint.
So for those of you out there trying to figure out what to invest in next, React, Elm, RxJS.. My advice would be to get a deep understating of pure Javascript first. Ideally, try to build your very own framework using vanilla JS. Once you do that you'll find each new framework is just a different opinion on how JS should be used.
Many frameworks have come and gone. But after more than a decade of investing in the Javascript language, it keeps rewarding.
The complexity of this tutorial reflects the current state of web app development more than the complexity of React. React by itself is actually rather simple on the surface.
Even though I don't need this tutorial to be productive, I think I'm going to go through it anyway to fill in holes in my knowledge. It looks well written.
The anger in this thread does not bode well for the future of React.
I predict big, complex, arcane React stacks will be a punchline in a few years, much like J2EE/EJB is today.
And yes, I know React itself is a small library - Java servlets were a small, simple API that formed the foundation for a ton of over-engineered abstraction on top.
I haven't finished reading, but so far this is an excellent walkthrough. This goes far far FAR beyond the 'Hello World' and 'TodoApp' tutorials and demos the amount of tooling you have to dedicate to keep things as seamless as possible.
I recently wrote that in a side project it does not appear to be worth the effort, but that applies to my side project and nothing else. Your next project may well look a LOT like this.
People should stop complaining about how "hard" it is to get started or how "complicated" React is.
React is simple. Its core abstraction is trivial (making views into pure functions).
If you want to, you can get started with React today without installing any software at all. Just include it from the CDN: https://cdnjs.com/libraries/react/
The rest is there because things like live-reloading are genuinely helpful. But you don't need to roll them yourself. There are dozens of great boilerplates you can base a new project off of.
Also, I've never had as much difficulty setting up a React environment as the constant struggle it is to get even a basic Java app to build from source.
I know there's a lot of dog-piling on this tutorial, but having gone through fullstack.io's Angular 2 book, if I wanted to learn React, I'd probably (and probably will) go with their title.
Cool tutorial, but first check if React is what you really need for your next thing. Facebook creates React to solve the problem of dealing with large applications with data that changes overtime. React became very popular to the point where the word gets spread saying this is the newest and coolest thing to learn. At this point the core idea and key aspects of why React is cool get misunderstood and we start assuming that React is the best choice for everything! and Virtual DOM is so cool and done!.
So now apps that could be done in 1/3 of the time if you just used a simpler library or even vanilla Javascript are being written with all these complex flows, dispatching actions and thunking async operations when all you really needed was display a list of things with ajax...... I'm not saying React is not cool. I'm just saying, understand why React is relevant today and decide if its the right thing for you project. Of course these tutorials are gonna be using simple examples that are unrealistic. They're meant to help you understand how things connect with each other, but are you building a project that is worthy of all this setup?.
I'm not sure about "large applications", but agreed about "data that changes". It's definitely not like dropping in a library like jQuery to spice up some interactions on a webpage.
The cool thing about react is that it doesn't try to do everything. Compared to Angular react is minimalist. So that's why react is used so much: because it doesn't try to do everything, it's basically just javascript and doesn't require you to re-learn web dev, and if you want to extend it you can easily do that. React can be made to fit most needs.
If all you're doing is serving a static web page then any framework is over kill, but then again, if all you're doing is serving static web pages you probably aren't a paid professional web developer.
To be a web dev professionally you need to know some framework, and react is really the best one. Angular tries to do too much but still makes you implement everything "the angular way" and meteor isn't a good framework for companies that want mix and match different technologies on their stack.
Then there are other alternatives that are non-javascript based, but in the end you still end up having to use javascript somewhere most of the time. Why take all the nastiness from the web-dev world and add even more convolution to it?
React isn't perfect but it's the best we have. And this is coming from someone who hates facebook and was once an angular dev.
I think most everyone agrees that the amount of work to get all these pieces glued together before you can even start is ridiculous- a problem that Meteor set out to fix years ago. It faltered, of course, by being too opinionated. Now that Meteor fully supports React and npm, though, is there any reason not to use it? Sure does remove some pain points.
No real reason as of now, you can choose to not use MongoDB if you want and use Meteor as just the front end.
When Apollo comes out, RIP all these React boilerplate projects, you're going to be able to pick and choose the data stack you want with Meteor making it nice to use.
[+] [-] swanson|9 years ago|reply
From the first sentence: "we get a lot of questions about how to build large applications with React and how to integrate external APIs" Large application strucutre, external integrations...not "Hello World"
Of course there is no need for multiple environments, or a robust testing setup, or an icon font, or 6 different webpack loaders to learn the basics of React. This is not a tutorial on the basics of React -- this is written from the perspective of a large production level application. And that "overhead" and "insanity" are helpful for real projects that are staffed by more than one person and need to last more than a week.
It seems absurd that it might take you 2 hours to setup the environment before you get to hello world. But if you are planning to use this as the foundation of a 6 month long project, 2 hours to get everything setup in a sane way is not an issue.
There is absolutely churn in the JS world and some of it does seem unbelievable because things haven't contracted and settled into a steady-state. But don't just levy a blanket "lol fuck javascript tooling" every time you see a complicated setup process; you are doing yourself a disservice by not critically evaluating the choices the author of this post made and determining for yourself if they will benefit your project and/or learning efforts.
[+] [-] fbonetti|9 years ago|reply
What's not fun is learning 10 different ways to handle promises, 4 different build tools, several frameworks, and dozens of new libraries over the course of a year just to keep up. By the time you reach a level of mastery over one of these tools, it's already been replaced by something else! I mean it's great that the tools are getting better, but it's really painful to deal with the constant churn.
/rant
[+] [-] jimmytucson|9 years ago|reply
And that's just to get your tool chain in place. When you actually get into the tutorial, it starts with "Running a server". Running a server?
I submit that writing even basic, toy applications in React requires a trip to dependency hell and back, unless you already use these tools on a regular basis and keep up with the ever-rapidly-changing debate around build scripts, dependency managers, language preprocessors, etcetera, etcetera.
[+] [-] Cyph0n|9 years ago|reply
Why don't we see this kind of configuration hell in other major languages? Look at Python, or Scala, or Go, or even Rust. Do you see projects requiring 10 dependencies just to setup a testing environment? Or having to manually integrate every piece of the build process instead of using pre-made plugins?
We don't even have to talk about the extremely low average lifetime of libraries in the JS world; it's like a perpetual popularity contest!
[+] [-] greenspot|9 years ago|reply
I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded.
The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago.
A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.
[+] [-] tlrobinson|9 years ago|reply
It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.
[+] [-] alexquez|9 years ago|reply
[+] [-] eterm|9 years ago|reply
Sure, this is something that you only do once, so if it then leads to much better development workflow it makes sense to have a solid investment upfront, but it makes it very hard to compare technologies and make informed decisions given how much up-front "glue" is needed to get a demo application up and running.
I'm not blaming react, everything else in the javascript space is just as bad right now. There's at least 4 different ways of loading modules (UMD, AMD, commonJS, es (babel) modules), 2 of which (require(), import .. from) are used within this example.
In fact the whole process is so complex part of the process is "clone this package which has pre-configured parts of the process".
And all of this to glue together a couple of APIs.
[+] [-] pjs_|9 years ago|reply
[+] [-] firasd|9 years ago|reply
[+] [-] ocean3|9 years ago|reply
[+] [-] ryanSrich|9 years ago|reply
[+] [-] pbreit|9 years ago|reply
I'm an acknowledged novice but I find "modern" web development to be completely insane.
[+] [-] qudat|9 years ago|reply
I guess the saying is true, that haters are going to hate, but there really is no competition in terms of development experience once you grok the ecosystem.
[+] [-] eagsalazar2|9 years ago|reply
I wouldn't find fault with a similar tutorial for "how to set up a production, at scale, rails app with only sever side rendering and zero javascript". Between hosting, cacheing, deployment, worker queues, database provisioning, etc, LOL that tut would be gigantic and that makes sense!
If people are mad that making production client side applications isn't trivially easy, well that just isn't going to happen and that isn't because the js ecosystem is screwed up.
[+] [-] zxcvcxz|9 years ago|reply
1. Those who know javascript and some major framework
2. Those who are unemployed
Yes we can build apps with just HTML and CSS and put it all in one file and serve it with a one line command, but if we want to be employed and have a website that actually scales we need to follow in the foot steps of the people who have done it.
[+] [-] keyle|9 years ago|reply
Seriously, how can people be blasting older technology like Flash and Flex (which was GREAT), out of the water for not using web standards and then this Frankenstein of a "stack" is going so mainstream.
Sure, there is the VM problem, but the language was good and so was the framework. This looks horrendous and scary. Imagine maintaining this for the next 10 years when "the standards" will have moved on to you "next gen" javascript "framework".
My only way to write web apps has been using micro frameworks, jquery, and small libs that do one thing and one thing only. I can handle serving pages with Go thanks, and I don't need a routing system that looks like a vintage joke. Sorry if I sound jaded, I've been doing this for 15 years.
[+] [-] Cyph0n|9 years ago|reply
However I simply won't believe that setting up a simple React app requires so much overhead. Granted, I have no experience with React, and only marginal experience with frontend web dev.
As I read the tutorial, this is the list of questions I had:
1. Why do we need so many Babel presets? What do they do?
2. Why do we need Webpack exactly? Why not use a traditional build system like Gulp?
3. Why is Webpack so difficult to setup? Are there no pre-configured setups for React?
4. What the hell is postcss? Are Less and Sass out of fashion now?
5. And why all this added complexity to setup CSS? They are only stylesheets for God's sake!
6. Oh, so now we need to configure Webpack to support postcss? The definition of reinventing the wheel. Is there no plugin system for Webpack?
7. Why is it so complicated to setup multiple environments using Node and Webpack?
Phew, looks like we're done -- nope, we're not.
8. So many libraries just to setup a testing environment? I wouldn't be surprised if frontend apps aren't well tested...
9. Ah, we also need a "JSON loader", whatever the hell that is.
10. Great, another CLI tool for testing. And more configuration of course.
11. Webpack once more needs to be configured to support our new testing app.
12. We need a better spec reporter? Why? More configuration...
13. More Webpack configuration.. I'm already sick of it.
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?
I find this all weird because I have the habit of thinking very carefully about every single dependency when I'm writing software. Do I really need it i.e. can the same task be achieved using the standard library? If not, how active is the development of the library (recent activity, issue response time, number of contributors)? How many libraries does it depend on - the fewer, the better? And even with all this, it's still not guaranteed that things will go smoothly!
[+] [-] sdnguyen90|9 years ago|reply
[+] [-] hokkos|9 years ago|reply
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.
[+] [-] BinaryIdiot|9 years ago|reply
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.
[+] [-] insin|9 years ago|reply
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
[+] [-] RobertKerans|9 years ago|reply
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
[+] [-] juddlyon|9 years ago|reply
The older I get the more I hate third party dependencies. You're asking for trouble.
[+] [-] MatthewPhillips|9 years ago|reply
[+] [-] mhink|9 years ago|reply
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". 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.
[+] [-] rvanmil|9 years ago|reply
[+] [-] duderific|9 years ago|reply
Can you share how you did that? Was it a number of different resources you consulted, or is there some all-in-one resource you found?
[+] [-] showerst|9 years ago|reply
It also shows what an arcane dependency-hell react is... how much boilerplate does it take to get up a map with a valid route? I hope this is something that becomes a bit more standardized/easier as the ecosystem evolves.
[+] [-] blueside|9 years ago|reply
Foolish of me to keep underestimating the pains that JS developers willingly tolerate.
[+] [-] firasd|9 years ago|reply
[+] [-] zxcvcxz|9 years ago|reply
https://gist.github.com/danawoodman/9cfddb1a0c934a35f31a
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] civilian|9 years ago|reply
[+] [-] hammeiam|9 years ago|reply
[+] [-] missing_cipher|9 years ago|reply
[+] [-] rvdm|9 years ago|reply
Regarding Javascript fatigue, I want to share something that greatly helped me.
I have written enterprise applications for Fortune 500s using PHP, Rails, Backbone, Angular, React, Node, Express, Grunt, Gulp, Webpack, Yeoman, Bower, Redux, jQuery, Coffescript, Prototype.js ( remember them!? ), LESS, SASS... Basically whatever was hot at the moment.
Long I've enjoyed learning new things, but after having made a solid investment in Angular only to find out none of it's SEO solutions were really commercially viable the fatigue hit me hard and I gave up on trying to learn new things for a while. I simply stopped caring.
Then I got approached by SpaceX for a JS full stack position. All they told me about the interview beforehand was that it would be very JS heavy, yet no details on what stack or framework they were working with.
To prep I brushed up hard on my basic JS skills. Codeschool.com their JS road trip was very useful. So were "Eloquent JavaScript" and "JavaScript: The Good Parts".
After making that tough but very rewarding investment, learning React, Flux, Redux, Elm etc. all became a breeze. I no longer have any attachment to any framework. They're all just different ways of using JS to me. And no matter what the future brings, no matter how many frameworks and build tools get thrown our way, I don't think ( hope? ) my heavy investment in Javascript will soon disappoint.
So for those of you out there trying to figure out what to invest in next, React, Elm, RxJS.. My advice would be to get a deep understating of pure Javascript first. Ideally, try to build your very own framework using vanilla JS. Once you do that you'll find each new framework is just a different opinion on how JS should be used.
Many frameworks have come and gone. But after more than a decade of investing in the Javascript language, it keeps rewarding.
[+] [-] hathawsh|9 years ago|reply
Even though I don't need this tutorial to be productive, I think I'm going to go through it anyway to fill in holes in my knowledge. It looks well written.
[+] [-] zeemonkee3|9 years ago|reply
I predict big, complex, arcane React stacks will be a punchline in a few years, much like J2EE/EJB is today.
And yes, I know React itself is a small library - Java servlets were a small, simple API that formed the foundation for a ton of over-engineered abstraction on top.
[+] [-] arenaninja|9 years ago|reply
I recently wrote that in a side project it does not appear to be worth the effort, but that applies to my side project and nothing else. Your next project may well look a LOT like this.
[+] [-] ErikAugust|9 years ago|reply
http://blog.getstream.io/react-redux-example-app-tutorials-p...
[+] [-] morgante|9 years ago|reply
React is simple. Its core abstraction is trivial (making views into pure functions).
If you want to, you can get started with React today without installing any software at all. Just include it from the CDN: https://cdnjs.com/libraries/react/
The rest is there because things like live-reloading are genuinely helpful. But you don't need to roll them yourself. There are dozens of great boilerplates you can base a new project off of.
Also, I've never had as much difficulty setting up a React environment as the constant struggle it is to get even a basic Java app to build from source.
[+] [-] bdcravens|9 years ago|reply
[+] [-] pacomerh|9 years ago|reply
[+] [-] firasd|9 years ago|reply
I wrote something about the 'Why' of React (with some related links that talk more about it): "Interface from Data... Rendering views as a function of state." https://medium.com/@firasd/interface-from-data-using-react-t...
[+] [-] zxcvcxz|9 years ago|reply
If all you're doing is serving a static web page then any framework is over kill, but then again, if all you're doing is serving static web pages you probably aren't a paid professional web developer.
To be a web dev professionally you need to know some framework, and react is really the best one. Angular tries to do too much but still makes you implement everything "the angular way" and meteor isn't a good framework for companies that want mix and match different technologies on their stack.
Then there are other alternatives that are non-javascript based, but in the end you still end up having to use javascript somewhere most of the time. Why take all the nastiness from the web-dev world and add even more convolution to it?
React isn't perfect but it's the best we have. And this is coming from someone who hates facebook and was once an angular dev.
[+] [-] drumttocs8|9 years ago|reply
[+] [-] sergiotapia|9 years ago|reply
When Apollo comes out, RIP all these React boilerplate projects, you're going to be able to pick and choose the data stack you want with Meteor making it nice to use.
[+] [-] patrickbolle|9 years ago|reply