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.
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 is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React (what they actually want to do). I've seen plenty of people give up because they couldn't get their webpack set up right.
Also, for those making courses, consider just using browserify. It's much easier on the newbies.
> I'm not blaming react, everything else in the javascript space is just as bad right now.
Not Ember! A great example of a blackboxed, prebuilt build system that gets out of the way.
>>This is a pet peeve of mine when it comes to React tutorials. Why waste so much time making the user set up a dev environment? Just give him/her a prebuilt and "black boxed" environment and get on with learning React
And yet one of the most common criticisms of Rails is that it's too black-box and has too much "magic."
Rails is the actual framework. I can see why someone would hate the magic happening under the hood when attempting to get something done in Rails. When it comes to React, we're talking about the dev environment. I would love never having to configure webpack by myself ever again. Something like the rails scaffolding command would be excellent for working on React apps. I believe Ember has ember-cli to do this.
I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.
However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.
There is absolutely more of a startup cost to something like React and that makes it hard to evaluate its fit for your project, but I would suggest it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
You will find that Ember and Ember CLI are built on top of well-architected primitives; it's not that these things are hidden, it's just that understanding them isn't required to get started.
Seems like poor punishment to downvote Tom here. At the worst he made a blanket statement without backing it up, which is the exact same as what he was responding to.
> I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.
> However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.
I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months.
Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage.
And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second.
> it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction.
Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline.
tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal.
Completely agreed. I had the same frustrations when I was looking at things like meteor, angular, etc and I definitely got that vibe when I saw this page. And I am saying that as someone who has already built websites with React.
I really don't know that it needs to be (or feel) this complicated If it's a React tutorial it shouldn't require people to navigate through Karma, Webpack and Postcss, not least of all because they may already be comfortable using perfectly serviceable alternatives.
The thing is with Meteor I feel like I have to learn ALL of meteor to really expand/extend upon what it gives me or use some plugin, it feels like it takes away way too much control for me.
With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three comes out and the "Angular way" completely changes.
With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
Angular and Meteor try to do too much, this is why react is winning the framework wars.
Fair point, recent updates to Meteor (1.3) have made it much easier to use with the rest of the JS ecosystem (e.g. using react with meteor is as easy as using the default view library).
The reason you have all of this boilerplate setup with react is because it's only one small part of the equation, so you need to use and (ideally) understand a bunch of other libraries and tools to build something, hence these epic tutorials.
> I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
I find it odd that you feel that way given nearly every React tutorial absolutely does do things the "react way" including using mostly the same toolset.
Things like Flux, GraphQL, "Higher-order components" are not general web-dev knowledge you already have. React has it's own language, as much so as any other framework I've encountered.
You could def skip some of these steps though. Postcss seems like solution without a problem imo. Sass seems a bit saner. And you can skip the tests for most projects.
I've shared your frustration. The Hello World experience is a huge spectrum ranging from the 30 screens of setup you describe to the one-click Visual Studio installer.
The other thing to consider is what you assume from a reader in a tutorial. If you assume they have a full environment setup (or will be following another tutorial), you can put together a much more concise article.
Imagine the now-classic Rails Blog in 15 minutes screencast. For those at home -- even if you assume a unix-y environment -- you might have tutorial setup that looks like this:
* Install homebrew/update package manager
* Install ruby-build
* Install rbenv
* Install ruby-2.3
* Install git
* Create a git repository
* Install bundler
* Create a Gemfile that includes rails
* bundle install
* Install rails
* Install postgres via homebrew
* Setup postgres database
* Install javascript runtime (nodejs or ruby-racer)
* finally run `rails s` to see the blank hello world page
Sometimes there are a lot of steps involved in a full end-to-end guide. And sometimes we forget all the baked in knowledge and setup we had to do for our preferred tools/stacks that we are having to go through again as part of learning a new technology.
That's an unfair comparison. You are building the whole Ruby dev environment from scratch before coming to Rails. Which is not what is happening in the tutorial. Actually, if you have the typical ruby environment setup already (ruby, rubygems, bundler), then its only
gem install rails
rails new
rails s
You don't need postgres or any JS runtime to start off.
If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed. (or you'd be using system Ruby, which you generally shouldn't use: https://robots.thoughtbot.com/psa-do-not-use-system-ruby)
> If you were trying to learn Rails (which this story ostensibly is doing with React) you wouldn't have Ruby installed
Why? I went to Rails after I learnt Ruby. By that time, I already had rvm installed to manage Rubies.
I can agree that a lot of users jump to Rails without learning Ruby first, in which case the setup will be 4 commands longer. But that is not the case with React as you can't jump over JavaScript to React directly.
I really feel like this isn't a general problem, but rather a problem with a subset of development environments.
Node (backend) definitely doesn't have a similar problem. Want an express app? Install node -> npm i express --save -> node app.js.
Go doesn't have it either, whether you're using the base tool or GVM. Python requires a minuscule setup in virtualenv, but beyond that its straightforward. Elixir and Rust are straight-forward.
In fact, the only environments where I've ever thought "wow this is a configuration nightmare" are front-end web dev, Ruby, and in really complex python apps, obviously notwithstanding less common app environments like C/C++.
To be fair, the parent to your comment included lots of steps that assumed the user was starting from scratch. If we assume the same for the user making an Express app, the steps are much more complex:
* Install a C++ compiler (XCode or libssl-dev packages)
Really? This steps you just listed are similarly complex to what's in that React article? No No bruh.... 30 screens -- down-button-presses down and we're still seting up for a frontend sample app. This is so so an issue, Node(backend), Go and Rails and Py aint got.
I'm not comparing my steps to the React article. I'm comparing them to the steps in the comment I was responding to.
Anyway, measuring steps in terms of "screens" is woefully inaccurate. For example, the author of the post uses more than one screen on simply running `npm init`, because he includes unnecessary paragraphs and screenshots. Many other parts of his post are even more verbose.
I could rewrite the first 30 "screens" of his post in 1-2 "screens". Would that mean that the process is suddenly 30x easier?
Your examples aren't a front end application though... The tooling alone has a lot of options... same for desktop apps... are you going to go GTK, QT, Win32, some toolkit on top, what tooling do you need to construct your app, will you use an XML to language process? What about build constructs or third party libraries?
Front end applications of any kind of complexity are NOT simple... treating them as toys, and expecting them to grow in complexity doesn't work.
> 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.
I'm writing a tutorial right now for testing AngularJS and this is exactly what I'm running into. It's a tutorial but half of my first part is "install this, put this line in this configuration file, install this, add this one here, etc." It's easy to feel like I'm not writing a good tutorial but really that's just the current state of JS development.
I'm way out of my league, but would it be possible to distribute a Docker container with all the boilerplate? Tutorial users could run that at the start, then do the "fun stuff".
On the upside, it all seems clear (if somewhat laborious to go through in totality) and I definitely appreciate that the majority of those 93 page-downs were covering setting up testing and a testing strategy + framework. It seems most things of this type are more likely to either say "set up testing" without detail, OR are guides specifically for doing testing without going into great detail about the app being tested.
That's the first time he prints anything to screen, but the actual first "Hello world" text is at the beginning of the Routing section where he's just finished all initial boilerplate and testing setup and puts in his first route. Which is a little more representative.
I guess it depends what one thinks is representative of a hello world. His first print out of the literal "hello world" may be down that far, but in terms of "classical" hello world "standards" (just based off what hello world apps have traditionally looked like), the section I linked is more analogous in my opinion. It shows react operational and rendering.
If the bar is a yelp clone (which is already contrary to what a hello world is), then sure, maybe page 93 is more apt. But...you're building a yelp clone.
I am learning react. A few weeks ago I wrote a small app and based my work from a starterkit with a few thousand stars on github. I learned a lot from this app and the starterkit.
This week I decided to use what I learned at work, writing a small app that will be used only internally. When I cloned the same project at least 15-20% of the project was different.
Not just is a pain to set up a project but it's also changing very fast.
I feel the same frustration even though I am still at a point where I generally have a huge tolerance for this kind of stuff.
Slowly, however, things seem to be improving.
For one, Redux seems to be the preferred 'flux implementation'; that's an improvement over the countless implementations I had to choose from when I started about a year or two ago.
Then there are Rich Harris' Buble[1] and Rollup[2], which provide respectively batteries-included ES2015 transpiling and module bundling, and probably a bunch of other projects I'm not aware of that provide some sort of standardization or simplification in this process.
It's not happening as fast as I'd like, but it seems to be a move in the right direction.
This was the first thing I noticed as well. 40% of the tutorial is setup. It doesn't HAVE to be that painful just to get a working environment going, but it gets painful pretty quickly if you pile on Webpack and PostCSS and a testing setup and everything.
For true "Hello World", if all you just want is to play around with React without all the setup, try out quik[0] or react-heatpack[1]. I also wrote up a tutorial[2] using react-heatpack that gets a working Hello World in UNDER 3 page-downs :)
To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github.
A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.
I've no doubt Elm is simpler (considering it's more vertically integrated), but to be fair, if webpack is a maybe in Elm, lodash, immutable, isomorphic fetch, and webpack-hot-middleware would definitely be on my maybe list for React. Maybe maybes would include redux-thunk.
Vertical integration plays a part with blessed libraries for rendering, routing, and requests, but it's not just vertical integration: Elm completely obviates Immutable.js, TypeScript, Reselect, Redux-Thunk, and Lodash/Ramda by virtue of fundamental language design choices. The same goes for Haskell, OCaml, and PureScript. In that context, Redux becomes a design pattern, rather than a library.
Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)
Can you embed an existing js app (angular) with Elm? Doesn't need to be any real communication between them. Just have the Elm app decide if the angular app is displayed or not. Honest question as I'm embedding angular in react at the moment and there's quite a lot of library fatigue going on.
I wouldn't put lodash or immutible-js right away, and may gear towards axios as a client communication library.
The reason there's so much to do, is there are so many options... core parts of the tooling for modern js are fairly consistent... node is pretty much required, which brings npm.. understanding CJS and ES6 module syntax also required... a translator (babel|typescript|traceur) are pretty much required, as is a bundler (webpack|jspm+system|browserify). That'ss 1 x 3 x 3 potential configuration vectors without starting the application. Each has advantages and disadvantages... I'm webpack + babel myself.
From there you have React, you need an orchestration layer, which has started to settle on Redux for all but the most complex applications. If you need async workflows, you're probably going to need redux-thunk and a communication library (fetch or axios). Beyond that, it depends on your needs specific to the application. If you need more than one route, then react-router and binding to redux.
Everything beyond that depends on the specifics of your app and needs. There isn't a one size fits all.
I agree it's useful... however, it's far from a requirement if you're using React+Redux. Though there are some workflow changes if you are using Immutable.js with Redux. It's also the size (min+gz) of preact + redux combined. While still relatively small, depending on your needs it all adds up, and it really should depend on one's specific needs.
If you want to put together an Ikea chair, everything is in the box and the instructions are two pages long. If you want to put together a chair from scratch then you need the wood, hammers, nails, saws, a lathe, sandpaper (in multiple levels of coarseness), glue and a number of other tools. React is a lathe in this example, it's hard to put it in context without the rest of the tools but that doesn't make it complex.
>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.
Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-contained modules/files that depend on nothing -- not even on one another. Needless to say, it's not an approach that's very popular, but it works remarkably well for websites of moderate complexity. One thing I'm sure of: using those modules feels far more satisfying than using a framework.
As far as DRY, the worst aspect of no-dependencies approach is dealing with AJAX. The rest of it is actually not that bad. After some experimentation, I separated the functionality into "behaviors", which are fairly reusable across different pages and projects.
Screw this, use Meteor to build React apps. It's super smooth, no BS, and integrates everything that sucks about Javascript development into a cohesive Omakase package.
The real gut punch is many parts of this tutorial will probably be obsolete within six months. Fast forward a couple years and this will look like the equivalent of "Backbonejs tutorial - Step 1: bower install requirejs".
Sometimes I feel bad complaining about this. Things are evolving fast for a reason. Everyone is trying to make every part of this process better. The backbone joke above illustrates the point. Would you go back in time and freeze the evolution just to regain sanity for today's devs?
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 don't think it's fair to call his comment uninformed based on that link.
From your gist:
For ease of use, we are including the React, ReactDOM and Babel CDN
builds to make getting started as fast as possible.
In production, you'll want to instead look at using something
like Gulp, Grunt or WebPack (my personal recommendation)
to compile JSX into JavaScript. Also, check out:
http://facebook.github.io/react/docs/tooling-integration.html
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.
Sorry, I should have been more clear. What I meant was that your web app will never be as complex and resource demanding as Facebook. The reason why React is so complex is because it's intended for complex systems. If you want to quickly build a one off web app you shouldn't be using React imo. The length and complexity of this tutorial is a testament to that.
React is simple, not complex. Simplicity is like the main benefit of using React if your intention is to build a single page app. If that's not what you need, then yeah, use Rails.
Vacuum React is all you need for a small scale, real world app.
Ok, granted at some point you might want to pass your build through Browserify and Babel. No worries, both of those things are one liners in bash.
On the other hand, if you spend most of your time trying to make your build process the holy grail of hot-reloading webpack ES2020 isomorphic madness then you're not going to get much real work done. No one told you to do that though, and you can't blame React either. But even that isn't complexity. It's just annoying setup stuff. Real complexity grows with the scope of your app.
I disagree. React it's self is very simple. It's web development that is complicated. Other frameworks that try to do everything like angular are also complicated for the developers. The frameworks that do everything and are easy to use (like meteor) don't offer the extensibility of the more bare bones frameworks. Any web site that wants to grow needs a full control of the stack.
Of course, if all you're building is a static web page then I can see just using some HTML and CSS. But if you want to work professionally as a web developer then you need to know javascript and at least one major framework. You can not stay employed as a "full stack dev" if all you do is write an a couple HTML and CSS files and serve them with python httpSimpleServer.
React is complex because there are realms of new things you can do with it that you couldnt do before in a web app, and the best version hasnt been found yet.
React itself is a view library with a very small learning curve and narrow API. You can view all the documentation on their website. It's about 5 pages. This has nothing to do with Facebook's scale and Facebook didn't design this complexity.
Webpack isn't React, Redux isn't React, ES2015 isn't React. They're commonly used with React and add complexity to both your architecture and build step, but you're not required to use them.
This tutorial is getting a lot of negative replies because it's a tutorial on all those other things in addition to React. It takes 90 pages before you write React code because the author spent a lot of it explaining how Webpack configurations work.
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.?
What people refer to as boilerplate for setting up React, including in this article, is about installing and configuring node modules, build systems and other tools. React itself is just two modules (React, React-DOM.)
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.
Am I the only person who just doesn't get the appeal of Webpack over using something like Gulp? It just seems to me like Gulp is so much easier to use and setup.
Not that I have too much experience with either. But one example is having one webpack configuration with misc. loaders vs. reinventing it yourself and ending up with this mess:
Webpack isn't like Gulp at all. It's absolutely insane what Webpack can do. It can solve any asset-related problem imaginable. Compile SCSS into CSS into JSON and require it in your Javascript? Convert SVG images into data-URLs that work on all browsers? Manage async dependencies in your JS code without dynamic script tags or global variables? Automatically figure out exactly which assets you need on which page and chunk them all together? All of the above.
Probably worth a separate submission at that time. I guess you'd don't want to miss all the eyeballs talking about this React tutorial however, right? :-)
I have something VERY similar to this in production built with Angular, and let me tell you, I'm looking forwards to the day that I get to refactor it in React.
I get that it's frustrating to do a lot of setup. But that's the nature of the game. We're all standing on the shoulders of giants.
React is a pleasure compared to other ways of conceptualizing and practicing building user interfaces on the front end.
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!
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.
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
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.
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.
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.
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 ...
Totally! To tell the truth, I actually really appreciated that you started your comment off with a complimentary tone, even if you had your frustrations about the tech. Small bits of positivity go a long way. :)
"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."
Why do you want it to be anonymous in this context? I get you can drop the `return`, but I don't see how you gain anything (apart from a tiny reduction typing and a small increase in incomprehensibility) by using anonymous functions to define components (I know the pattern is used a lot in the wild, but there seems to be zero reasoning for it; lexical binding isn't really relevant here)
> There is nothing forcing you to use all the extra dependencies
This right here is a major problem with a ton of apologists. "You don't need to use X and Y, just start with barebones Z".
If you're doing your own side project, sure. Or if you're lucky to be developer #1 in a greenfield project. I can count on one hand the number of times in my career that's happened.
Most of the time, you're going to be maintaining someone else's work. They'll have a ton of dependencies and glue and workarounds, and you're really, really lucky if they've written tests or documentation. So all the complexity mentioned in the article? You get to deal with that, only not so neatly put together. More likely they'll have an out-of-date version of react-router that's incompatible with the library you're trying to install, upgrading react-router means rewriting a ton of code because they love to change their API every other release....
Now I like React, and I've built things with it. But there is a huge and growing PR problem with it right now, that for all its promise there is too much incidental complexity, too many ways to do it, a lack of standardization around things like build tools. Companies aren't overjoyed at having codebases that become impossible to maintain 6 months out, when the frontend devs jump ship. Whether the answer is a more structured framework like Ember or Angular, I don't know, but there is a lot of fatigue and frustration around trying to build and maintain a project out of lots of tiny pieces, and it's showing in this thread.
The extreme modularization is a huge, huge issue. There is a slight settling: the recommendation for state management shifting almost exclusively to Redux is IMO a very good thing, if only for the fact of how brutally simple it is, with almost zero chance there will be any API changes. Packages such as react-router, with constant API changes, are a nightmare though. Standardisation this year would be good: state management (Redux), a router (a settled react-router), immutability (Immutable), a method of dealing with asynchrony/promises that's well documented and easy for people to just pick up and use, a drop in test framework (personal bugbear is setting up the multifarious bits of test/coverage/complexity tools - Ava + NYC + Plato seems a very good build so far for this, but it's very young). But it's the configuration of build tools which is the killer
React itself is very simple, but then so is jQuery, and having to pick apart the twenty or thirty jQuery plugins + associated spaghetti the last dev dropped into a project is even less fun than the current situation, it just took a lot less of a deep understanding of JS; one of the issues I'm starting to get a lot more of is devs dropping in prebuilt components, which is just jQuery all over again, but in extremis.
Nifty! The config needed some fixes and tweaks (using `babel-loader`, `<MyRootComponent/>`, a `resolve` section) before it actually works out of the box, but it's a nice idea. I made a `git clone`:able version of the setup with fixes and a `Makefile` at https://github.com/johan/make-react-hack
> 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.
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).
> The new shiny seems to be using dependencies straight from git and vendoring them.
That's news to me, it's all npm and node_modules/ as far as I can see.
> 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?
You can get https://greenkeeper.io/ to watch your project and its dependencies - it creates Pull Requests to update dependencies with details of what changed in the description, and all the usual PR stuff like running whatever CI you've configured happens as a result of creating it.
If I don't have Greenkeeper set up (the PRs can get a bit noisy), I just run npm outdated --depth=0 any time I'm poking about in a project.
> If you decide you need to stay on an older version, is someone backporting fixes?
Depends entirely on the maintainers of that project. Babel 5 has had a couple of things backported, like support for Flow annotations, for example.
> Is there a curated set of packages that are known to work together?
Not curated as such, but you can just look at what people are successfully using and sharing, and tools people are creating. nwb is effectively my own curated package of development tools pre-wired together.
> When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems?
I usually check the diff between the release tags/changelogs between what I'm updating to before, but not specifically security auditing.
> Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features?
Well, people are talking about React and React tutorials here. Everyone has a different approach to teaching and learning, so this is a good place to share :)
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.
A large setup cost discourages you from creating many small projects; from creating experiments that may/may not pan out. This is why the browser/text editor flow of development will (eventually) win out. Hopefully people working in these toolchains are at least using some boilerplate projects or generators that cover 90% of cases.
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.
The solution is not trying so hard to keep up. Keep your ears open for the major improvements that rise above the noise, but don't feel like you have to be on the cutting edge. Much of the cutting edge is (almost by definition) misguided or overcomplicated.
The sweet spot if your goal is to actually build something is taking whatever architecture is currently hip and throwing out about 2/3 of it in exchange for a simpler approach. Then circle back for the fancier libraries a few months later if and when you have a need for them.
I hear you. Web Assembly just might save us all from this ridiculous JS drive to re-invent things. Pick a language you like to work with on the server side, learn the current best framework for the client side in that language and be happy ever after with enough free time for gardening and feeding goats.
>it just doesn't pay off to learn the new, cool thing when it's going to be obsolete in 3 months or less.
Does this actually happen? If you had learned Angular way back, you would still be in a comfortable situation. New stuff coming in, but it's compatible with the old stuff.
Same with React. Had you learned react when it was talked about, you would have gotten, what, at least 2 years worth of value by now?
And a lot of the build tools are independent of the tech. Grunt is still fine to use, and people release plugins for it all the time.
And here's the last thing: You don't have to spend 6 months to learn a thing. If you want to keep up, read about it for 15 minutes? That should be enough most of the time to get the philosophical differences between tools you know. And if it does intrigue you enough, engage with it.
This stuff is progress, if we went the other way we'd still be writing jQuery spaghetti code and having state integrity issues up the wazzoo from callback hell. You don't have to ride every train, but you can at least look at them as they go by.
Grunt is actually not still fine to use. I've been burnt by a lot of plugins coming out for Gulp only and now for webpack only. What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.
> What the GP says is true: if you start using any of these JS tools prepare to switch them out every 6 months.
As a full stack JavaScript developer, the tools I used over 6 months ago are also the tools I use today. Only difference is I left Angular for React. But my build tools are still the same. I use Gulp, SASS and Webpack.
You're talking out of your ass if you actually believe something can get to the popularity of Gulp or Webpack and then instantly be "old news" and "not worth using" within 6 months.
Grunt just released v1.0 and is still a great alternative. People fail to realize just because another way to do something comes out, doesn't mean all of the sudden the previous way is no longer a viable solution.
The problem is working with fanboys who refuse to use the tools that you've spend a year or two investing in. When the people you work with throw away your projects every couple of months, there's nothing you can do to keep using what works.
Maybe I'm not ahead of the curve enough. Still though, every 6 months? Did you start using Grunt only 6 months before running into this issue?
Maybe I'm reading this too literally, but personally I'm totally cool with using a tool for 2 years and then transitioning to another. 2 years is already a lot of good value.
My experience is that the decision to switch is often being made for you. I was perfectly happy with Grunt until some plugin maintainers didn't update the Grunt version and only worked on Gulp.
We started a brand new project in Ember (our second Ember project) in December; launched it in January. We've now started another project in Untangled because nobody wants to work in Ember anymore (apparently, it stopped being cool last year).
So, yes, this actually happens and it's incredibly painful for those of us who want to build a business not throw everything out and start over every few months.
> 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.
I feel your pain, but on the other hand:
- tools with enough users are not going away, even if they're less actively maintained
- it's not like sticking to HTML + jQuery is desirable if you need to build a complex UI
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.
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!
> 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!
This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not being used by anything in your Github, you're not getting called back.
Definitely true in general, but I think it's more noticeable in the JS world. Look at Java + Spring, C# + ASP.NET, Python + Django, Ruby + Rails: these are all examples of popular frameworks that have been around for much longer than any single JS library (except jQuery), and are all still in high demand.
This is primarily a JS thing. Many nontechnical people that look over your resume don't know that Node Backbone React Angular and the random data visualization libraries are all "Javascript"
What are you doing with python and go that "just works"? Writing scripts? It takes a lot more work to build a yelp clone with python than it does with react.
> What are you doing with python and go that "just works"?
Anything you want. Dependency management is taken care of by a simple `pip install flask`, or a requirements.txt. The rest depends on the packages you are using.
> It takes a lot more work to build a yelp clone with python than it does with react.
And why do you think that? I could build a simple and performant Yelp clone with full authentication, admin access, and persistence using only a handful of Python packages:
* Flask: web app microframework
* Jinja2: view templating language
* SQLAlchemy: database ORM
* Psycopg: Postgres database driver
* Flask-SQLAlchemy: Flask plugin for SQLAlchemy
* Flask-Login: authentication, accounts
* Flask-Admin: administration
Of course, just like in the case of React, you'd need HTML + CSS for styling, and JS in case you'd like interactive elements. And finally, to run the app in production, I'd use Nginx + uWSGI.
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.
Any language or environment has it's hoops that you have to jump through in order to use it, in some cases these happen to be installed for you so it's less noticeable.
Submission largely accepted but you aren't making a real point with what you've submitted. I say "largely" because I agree with gp that 2 hours is hardly hell for a larger project but agreed that is pointless for basic/toy applications. This isn't really a solid indictment against React and webpack however. If you are really making a tiny/toy app, and not doing so for educational reasons, then yeah probably you should just use jquery and edit js/html/css (vs ES6/JSX or Jade/SASS + redux, testing, etc, etc which is not trivial).
Neither the homepage, Getting Started, the tutorial, nor the downloads page mentions CommonJS. If you do choose to use browserify or webpack, you'll want Node and npm, but Node's homepage doesn't suggest using Homebrew so I'm not sure why that would be necessary. (Besides, in my experience, most programmers using a Mac have Homebrew already.)
> When you actually get into the tutorial, it starts with "Running a server". Running a server?
We included this as a sample because most people write clients against an app server so we thought it instructive to show how to fetch and post data via AJAX. Nothing about it is inherent to React and people make React apps without any server component all the time. It sounds like this was misleading to you, which is good feedback for us. I was thinking about revamping the tutorial soon anyway and my new example wasn't going to have any server component.
My comment was based on notes I took from a little over a month ago, when the Getting Started guide said "We recommend using React with a CommonJS module system like browserify or webpack."
By the same note, you likely won't be writing a complex desktop application without some tooling installed, with similar pre-requisites. I don't know why people get so irritated at "JS tooling is hard". Try writing an (INSERT FRAMEWORK HERE) app outside the browser.
People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer.
That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start.
My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general.
What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling.
Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.
I didn't say that Maven wasn't complex. I said there are fewer tools and less churn. The advantage of Java dev is that you can justify the intellectual investment in the tools because there are fewer of them and they are going to be around for a long time. The same cannot be said about client-side development at this time.
Grunt still exists, npm has been a common point for close to half a decade now... it's pretty solid... everything else builds from there. If you've gotten used to npm and cjs modules, that's been very consistent for a number of years now.
And go doesn't have a package manager? It doesn't need any other modules to create gui apps? Aren't there wrapper bindings that would be simpler than direct api calls?
Speaking for myself, I have used many platforms ranging from embedded to desktop and I also proud myself to be a competent old skool web developer - one who has avoided node.js, angular, amber and similar. React caught my attention and I tried to learn using it... What pain! What parent is saying about tooling is totally true. But maybe I just missed a simple hello world tutorial... I will check it out in a year or so, if it's still around by then.
This is why I like Ember: you get setup in 2 seconds. Sure, I don't like all of the decisions they've made in the framework but it does work really well out of the box.
I think having a cli will become standard for JS frameworks. You just need to have the batteries included to capture the newb mindshare.
I prefer mocha to qunit and I'm a fan of coffeescript (ES6 can wait. I love the existential operator). My company had made a few decisions before ember-cli that weren't on the Ember Happy Path. I've tried to stick to those decisions to avoid making people learn a different stack. It's not that easy to rip and replace pieces of Ember.
A decent toolchain of various libraries and build tools is an opportunity to avoid bigger problems and nasty, subtle bugs when you are working on large codebases. I continue to have my share of them, which tend to be in areas of the codebases I worked on that is principally jquery spaghetti or undisciplined Backbone code.
I'd rather deal with the dependency hell; that's an opportunity cost. I'd rather deal with my current toolchain than having to tell stakeholders that a particular aspect of bad code is beyond repair and needs to be replaced badly, at the cost of a large time sink.
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.
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.
The React ecosystem for developing non-trivial apps is not at all easy and rather complex. Both for new developers and experienced web folks to relearn "the React way".
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
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.
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.
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.
Sure- that's the article I was thinking about when I mentioned that it faltered. It still has quite the dedicated base, and with 1.3, has corrected many of the complaints (npm support, etc)
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.
Lots of complaining but no one offers a better solution. Any article detailing how to build a yelp clone is going to be kind of long. It's really not that bad compared to doing something like this with LAMP. Much simpler than Angular too.
With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three is coming out and the "Angular way" completely changes.
And then what are the non-javascript alternatives? It really doesn't matter much because I'll have to interface with javascript anyway if I'm a professional webdev, so why would I add even more clutter to the already cluttered web dev world?
With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
Interesting... he needs to include his webpage config from each stage. He linked the full one but that will not work when you are still in the starting parts.
There is something wrong with me but I can not/refuse to use command line. It has no discoverability and no visible system state information. Every time I try to use it I start to panic because I can not see my files, I can not see the state of my task, I can not see anything. Maybe I have some form of dyslexia. Anybody out there with similar symptoms? Anybody knows a remedy to my problem please?
I would start with using a better shell that gives you more of the context you are asking for. I would recommend zsh and using Oh My Zsh for easy setup
257 comments
[ 4.3 ms ] story [ 254 ms ] threadIt 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.
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.
Also, for those making courses, consider just using browserify. It's much easier on the newbies.
> I'm not blaming react, everything else in the javascript space is just as bad right now.
Not Ember! A great example of a blackboxed, prebuilt build system that gets out of the way.
And yet one of the most common criticisms of Rails is that it's too black-box and has too much "magic."
So you're damned if you do, damned if you don't.
However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.
There is absolutely more of a startup cost to something like React and that makes it hard to evaluate its fit for your project, but I would suggest it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
> I think this is somewhat of a deceptive trap that people fall into. It's difficult to trial something like React unless you set up all the tooling around it, so Ember appears easier because it is blackboxed and sets things up for you.
> However, that means that six months in, when your app has outgrown the constraints of the blackboxed starter, you are trapped.
I have not seen a single company outgrow Ember-CLI. Imagine for a moment a big company with a huge app- Yahoo or LinkedIn or Twitch. These companies have apps that push the limits of Ember-CLI for sure, and have delved into the internals to add cutting edge features like lazy loading or optimized module loading, however none of them have abandoned it after six months.
Ember CLI has a public API for making changes to your build pipeline. Advanced users often reach for direct manipulation of Broccoli trees, another open source documented API with lots of example usage floating around. The "black box" referenced is non-existent. Ember-CLI is more like a car with a good manual. You don't need to understand fuel injection timing to get it out of the garage.
And Ember-CLI is fast. Out of the box it has great performance on Windows, Linux and OSX and there is even more room for improvement. Six months down the road, you will not find out it takes five seconds to rebuild your app. It will still be sub-second.
> it pays ridiculous dividends to understand the stack you're going to have to maintain for the next X years instead of having it hidden away from you.
We share software (proprietary or open) because it spreads the cost of maintenance. As a web developer I have plenty of work already, maintaining my own build pipeline is no more desirable than maintaining my own rendering engine or my own operating system. We always solve problems atop a certain level of abstraction.
Ember-CLI is the result of a concerted effort by individuals and the community that started in 2013. The project is clearly a massive success, demonstrated by its overwhelming adoption by Ember users (well over 90%, it isn't that popular because it sucks). It is a disservice to Ember-CLI to blow it off as "not scaling past six months" and to yourself as a developer to disregard Ember-CLI's hard-won lessons about how to build a good common build pipeline.
tl;dr please don't presume Ember-CLI is flawed because it "appears easy", making the hard look easy is a worthy goal.
[edit]: formatting :-p
I really don't know that it needs to be (or feel) this complicated If it's a React tutorial it shouldn't require people to navigate through Karma, Webpack and Postcss, not least of all because they may already be comfortable using perfectly serviceable alternatives.
The main strength of Meteor is the speed you can get up and running
will set you up with a full stack application, running locally, with zero configWith Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three comes out and the "Angular way" completely changes.
With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
Angular and Meteor try to do too much, this is why react is winning the framework wars.
The reason you have all of this boilerplate setup with react is because it's only one small part of the equation, so you need to use and (ideally) understand a bunch of other libraries and tools to build something, hence these epic tutorials.
I find it odd that you feel that way given nearly every React tutorial absolutely does do things the "react way" including using mostly the same toolset.
Things like Flux, GraphQL, "Higher-order components" are not general web-dev knowledge you already have. React has it's own language, as much so as any other framework I've encountered.
If this web page were a book it would be about 30 pages.
What framework is there that allows you to build full scale web-apps in less time?
Certainly not Angular, an Angular tutorial would be at least twice as long and you wouldn't even use half the features of Angular.
Meteor? Sure, but meteor isn't a good choice for people who need a lot of control of what's going on under the hood.
The other thing to consider is what you assume from a reader in a tutorial. If you assume they have a full environment setup (or will be following another tutorial), you can put together a much more concise article.
Imagine the now-classic Rails Blog in 15 minutes screencast. For those at home -- even if you assume a unix-y environment -- you might have tutorial setup that looks like this:
* Install homebrew/update package manager
* Install ruby-build
* Install rbenv
* Install ruby-2.3
* Install git
* Create a git repository
* Install bundler
* Create a Gemfile that includes rails
* bundle install
* Install rails
* Install postgres via homebrew
* Setup postgres database
* Install javascript runtime (nodejs or ruby-racer)
* finally run `rails s` to see the blank hello world page
Sometimes there are a lot of steps involved in a full end-to-end guide. And sometimes we forget all the baked in knowledge and setup we had to do for our preferred tools/stacks that we are having to go through again as part of learning a new technology.
* install rails
* run 'rails s'
https://robots.thoughtbot.com/psa-do-not-use-system-ruby
gem install rails
rails new
rails s
You don't need postgres or any JS runtime to start off.
Why? I went to Rails after I learnt Ruby. By that time, I already had rvm installed to manage Rubies.
I can agree that a lot of users jump to Rails without learning Ruby first, in which case the setup will be 4 commands longer. But that is not the case with React as you can't jump over JavaScript to React directly.
Node (backend) definitely doesn't have a similar problem. Want an express app? Install node -> npm i express --save -> node app.js.
Go doesn't have it either, whether you're using the base tool or GVM. Python requires a minuscule setup in virtualenv, but beyond that its straightforward. Elixir and Rust are straight-forward.
In fact, the only environments where I've ever thought "wow this is a configuration nightmare" are front-end web dev, Ruby, and in really complex python apps, obviously notwithstanding less common app environments like C/C++.
* Install a C++ compiler (XCode or libssl-dev packages)
* Run the NVM install script
* Use NVM to install Node.js
* npm install express-generator -g
* express myapp
* cd myapp; npm install
* Install or update Homebrew
* Install git
* git init
* Install Mongo (or your db of choice)
* Install Mongo packages via npm
* npm start
Anyway, measuring steps in terms of "screens" is woefully inaccurate. For example, the author of the post uses more than one screen on simply running `npm init`, because he includes unnecessary paragraphs and screenshots. Many other parts of his post are even more verbose.
I could rewrite the first 30 "screens" of his post in 1-2 "screens". Would that mean that the process is suddenly 30x easier?
Front end applications of any kind of complexity are NOT simple... treating them as toys, and expecting them to grow in complexity doesn't work.
I'm writing a tutorial right now for testing AngularJS and this is exactly what I'm running into. It's a tutorial but half of my first part is "install this, put this line in this configuration file, install this, add this one here, etc." It's easy to feel like I'm not writing a good tutorial but really that's just the current state of JS development.
On the upside, it all seems clear (if somewhat laborious to go through in totality) and I definitely appreciate that the majority of those 93 page-downs were covering setting up testing and a testing strategy + framework. It seems most things of this type are more likely to either say "set up testing" without detail, OR are guides specifically for doing testing without going into great detail about the app being tested.
https://www.fullstackreact.com/articles/react-tutorial-cloni...
I think it's a good guide btw.
If the bar is a yelp clone (which is already contrary to what a hello world is), then sure, maybe page 93 is more apt. But...you're building a yelp clone.
I am learning react. A few weeks ago I wrote a small app and based my work from a starterkit with a few thousand stars on github. I learned a lot from this app and the starterkit.
This week I decided to use what I learned at work, writing a small app that will be used only internally. When I cloned the same project at least 15-20% of the project was different.
Not just is a pain to set up a project but it's also changing very fast.
Slowly, however, things seem to be improving.
For one, Redux seems to be the preferred 'flux implementation'; that's an improvement over the countless implementations I had to choose from when I started about a year or two ago.
Then there are Rich Harris' Buble[1] and Rollup[2], which provide respectively batteries-included ES2015 transpiling and module bundling, and probably a bunch of other projects I'm not aware of that provide some sort of standardization or simplification in this process.
It's not happening as fast as I'd like, but it seems to be a move in the right direction.
[1]: https://gitlab.com/Rich-Harris/buble [2]: http://rollupjs.org/
For true "Hello World", if all you just want is to play around with React without all the setup, try out quik[0] or react-heatpack[1]. I also wrote up a tutorial[2] using react-heatpack that gets a working Hello World in UNDER 3 page-downs :)
[0] https://www.npmjs.com/package/quik
[1] https://www.npmjs.com/package/react-heatpack
[2] https://daveceddia.com/test-drive-react/
To create a proper React single page app, you need React, Redux, lodash, react-router, webpack, Immutable.js, babel, npm, redux-thunk, isomorphic-fetch, webpack-hot-middleware, and ton of boilerplate and configuration (which everyone does differently). You can try to assemble this yourself, or choose one of hundreds of starter projects on Github.
A comparable Elm app is a lot simpler. It consists of Elm, a router such as elm-transit-router, and maybe webpack if you want to watch and minify your compiled javascript. Especially now with the new 0.17, Elm forces you to use the standard Elm Architecture, so you don't waste any time thinking about how to structure your app and there's very little boilerplate as a result. On top of this, Elm is statically typed, functional, and simply a joy to work with.
Ultimately, it feels like React's best practices and associated libraries try to bludgeon JavaScript into acting like a functional, immutable language. If that's the right model, I'd rather just use a language that was intentionally designed to be functional and immutable from the start. :)
The reason there's so much to do, is there are so many options... core parts of the tooling for modern js are fairly consistent... node is pretty much required, which brings npm.. understanding CJS and ES6 module syntax also required... a translator (babel|typescript|traceur) are pretty much required, as is a bundler (webpack|jspm+system|browserify). That'ss 1 x 3 x 3 potential configuration vectors without starting the application. Each has advantages and disadvantages... I'm webpack + babel myself.
From there you have React, you need an orchestration layer, which has started to settle on Redux for all but the most complex applications. If you need async workflows, you're probably going to need redux-thunk and a communication library (fetch or axios). Beyond that, it depends on your needs specific to the application. If you need more than one route, then react-router and binding to redux.
Everything beyond that depends on the specifics of your app and needs. There isn't a one size fits all.
Personally, I got so frustrated with ever-increasing complexity of tools and growing networks of dependencies that whenever I can I try to package my JS code in self-contained modules/files that depend on nothing -- not even on one another. Needless to say, it's not an approach that's very popular, but it works remarkably well for websites of moderate complexity. One thing I'm sure of: using those modules feels far more satisfying than using a framework.
No, React is particularly bad here. RactiveJS for example can be used in a minute: http://www.ractivejs.org/60-second-setup
Sometimes I feel bad complaining about this. Things are evolving fast for a reason. Everyone is trying to make every part of this process better. The backbone joke above illustrates the point. Would you go back in time and freeze the evolution just to regain sanity for today's devs?
* lein new figwheel hello-world
And done. Say lein isn't installed, it is a simple script you download and run once.
Foolish of me to keep underestimating the pains that JS developers willingly tolerate.
https://gist.github.com/danawoodman/9cfddb1a0c934a35f31a
From your gist:
He did specify "production-ready", after all.Of course I also like to stay employed and react is the most in demand framework right now.
Ok, granted at some point you might want to pass your build through Browserify and Babel. No worries, both of those things are one liners in bash.
On the other hand, if you spend most of your time trying to make your build process the holy grail of hot-reloading webpack ES2020 isomorphic madness then you're not going to get much real work done. No one told you to do that though, and you can't blame React either. But even that isn't complexity. It's just annoying setup stuff. Real complexity grows with the scope of your app.
Of course, if all you're building is a static web page then I can see just using some HTML and CSS. But if you want to work professionally as a web developer then you need to know javascript and at least one major framework. You can not stay employed as a "full stack dev" if all you do is write an a couple HTML and CSS files and serve them with python httpSimpleServer.
Webpack isn't React, Redux isn't React, ES2015 isn't React. They're commonly used with React and add complexity to both your architecture and build step, but you're not required to use them.
This tutorial is getting a lot of negative replies because it's a tutorial on all those other things in addition to React. It takes 90 pages before you write React code because the author spent a lot of it explaining how Webpack configurations work.
I'm an acknowledged novice but I find "modern" web development to be completely insane.
1) You still get a config file, neat right https://github.com/mgechev/angular2-seed/blob/master/tools/c...
2) And this boilerplate https://github.com/mgechev/angular2-seed/tree/master/tools/t...
http://blog.getstream.io/react-redux-example-app-tutorials-p...
I get that it's frustrating to do a lot of setup. But that's the nature of the game. We're all standing on the shoulders of giants.
React is a pleasure compared to other ways of conceptualizing and practicing building user interfaces on the front end.
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!
The older I get the more I hate third party dependencies. You're asking for trouble.
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
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:
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
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.
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.
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.
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 ...
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
This right here is a major problem with a ton of apologists. "You don't need to use X and Y, just start with barebones Z".
If you're doing your own side project, sure. Or if you're lucky to be developer #1 in a greenfield project. I can count on one hand the number of times in my career that's happened.
Most of the time, you're going to be maintaining someone else's work. They'll have a ton of dependencies and glue and workarounds, and you're really, really lucky if they've written tests or documentation. So all the complexity mentioned in the article? You get to deal with that, only not so neatly put together. More likely they'll have an out-of-date version of react-router that's incompatible with the library you're trying to install, upgrading react-router means rewriting a ton of code because they love to change their API every other release....
Now I like React, and I've built things with it. But there is a huge and growing PR problem with it right now, that for all its promise there is too much incidental complexity, too many ways to do it, a lack of standardization around things like build tools. Companies aren't overjoyed at having codebases that become impossible to maintain 6 months out, when the frontend devs jump ship. Whether the answer is a more structured framework like Ember or Angular, I don't know, but there is a lot of fatigue and frustration around trying to build and maintain a project out of lots of tiny pieces, and it's showing in this thread.
React itself is very simple, but then so is jQuery, and having to pick apart the twenty or thirty jQuery plugins + associated spaghetti the last dev dropped into a project is even less fun than the current situation, it just took a lot less of a deep understanding of JS; one of the issues I'm starting to get a lot more of is devs dropping in prebuilt components, which is just jQuery all over again, but in extremis.
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
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.
That's news to me, it's all npm and node_modules/ as far as I can see.
> 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?
You can get https://greenkeeper.io/ to watch your project and its dependencies - it creates Pull Requests to update dependencies with details of what changed in the description, and all the usual PR stuff like running whatever CI you've configured happens as a result of creating it.
If I don't have Greenkeeper set up (the PRs can get a bit noisy), I just run npm outdated --depth=0 any time I'm poking about in a project.
> If you decide you need to stay on an older version, is someone backporting fixes?
Depends entirely on the maintainers of that project. Babel 5 has had a couple of things backported, like support for Flow annotations, for example.
> Is there a curated set of packages that are known to work together?
Not curated as such, but you can just look at what people are successfully using and sharing, and tools people are creating. nwb is effectively my own curated package of development tools pre-wired together.
> When an update comes in, do you audit it to make sure nothing malicious makes it on to your systems?
I usually check the diff between the release tags/changelogs between what I'm updating to before, but not specifically security auditing.
> Or does one have to wait until this stuff stabilizes and baked it's easy into linux distributions before one gets these nice features?
That's not going to happen :)
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.
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
The sweet spot if your goal is to actually build something is taking whatever architecture is currently hip and throwing out about 2/3 of it in exchange for a simpler approach. Then circle back for the fancier libraries a few months later if and when you have a need for them.
Does this actually happen? If you had learned Angular way back, you would still be in a comfortable situation. New stuff coming in, but it's compatible with the old stuff.
Same with React. Had you learned react when it was talked about, you would have gotten, what, at least 2 years worth of value by now?
And a lot of the build tools are independent of the tech. Grunt is still fine to use, and people release plugins for it all the time.
And here's the last thing: You don't have to spend 6 months to learn a thing. If you want to keep up, read about it for 15 minutes? That should be enough most of the time to get the philosophical differences between tools you know. And if it does intrigue you enough, engage with it.
This stuff is progress, if we went the other way we'd still be writing jQuery spaghetti code and having state integrity issues up the wazzoo from callback hell. You don't have to ride every train, but you can at least look at them as they go by.
As a full stack JavaScript developer, the tools I used over 6 months ago are also the tools I use today. Only difference is I left Angular for React. But my build tools are still the same. I use Gulp, SASS and Webpack.
You're talking out of your ass if you actually believe something can get to the popularity of Gulp or Webpack and then instantly be "old news" and "not worth using" within 6 months.
Maybe I'm reading this too literally, but personally I'm totally cool with using a tool for 2 years and then transitioning to another. 2 years is already a lot of good value.
So, yes, this actually happens and it's incredibly painful for those of us who want to build a business not throw everything out and start over every few months.
I feel your pain, but on the other hand:
- tools with enough users are not going away, even if they're less actively maintained
- it's not like sticking to HTML + jQuery is desirable if you need to build a complex UI
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.
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!
This is the awful truth of programming in general today. Sadly, it's a train not many of us can jump off of because of employ-ability. If popular tool/framework/language/etc is not on your resume, you're not getting called back. If popular tool/framework/language/etc is not being used by anything in your Github, you're not getting called back.
Anything you want. Dependency management is taken care of by a simple `pip install flask`, or a requirements.txt. The rest depends on the packages you are using.
> It takes a lot more work to build a yelp clone with python than it does with react.
And why do you think that? I could build a simple and performant Yelp clone with full authentication, admin access, and persistence using only a handful of Python packages:
* Flask: web app microframework
* Jinja2: view templating language
* SQLAlchemy: database ORM
* Psycopg: Postgres database driver
* Flask-SQLAlchemy: Flask plugin for SQLAlchemy
* Flask-Login: authentication, accounts
* Flask-Admin: administration
Of course, just like in the case of React, you'd need HTML + CSS for styling, and JS in case you'd like interactive elements. And finally, to run the app in production, I'd use Nginx + uWSGI.
And what if I want to use multiple versions of a given library for my development? Suddenly I'm learning virtualenv...
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.
And seeing a JSFiddle link that is fully configured to work and zip file that includes all necessary files.
What am I missing?
What you are missing is that you probably don't want to develop by putting your code in JSFiddle.
You could probably build a tutorial around generator-react-webpack-redux.
Started to implement the Todo App in this branch => https://github.com/stylesuxx/generator-react-webpack-redux/t...
Neither the homepage, Getting Started, the tutorial, nor the downloads page mentions CommonJS. If you do choose to use browserify or webpack, you'll want Node and npm, but Node's homepage doesn't suggest using Homebrew so I'm not sure why that would be necessary. (Besides, in my experience, most programmers using a Mac have Homebrew already.)
> When you actually get into the tutorial, it starts with "Running a server". Running a server?
We included this as a sample because most people write clients against an app server so we thought it instructive to show how to fetch and post data via AJAX. Nothing about it is inherent to React and people make React apps without any server component all the time. It sounds like this was misleading to you, which is good feedback for us. I was thinking about revamping the tutorial soon anyway and my new example wasn't going to have any server component.
https://web.archive.org/web/20160411175140/https://facebook....
https://github.com/facebook/react/pull/6148
People assume that writing an APPLICATION for a browser is easy, which is why people get stuck maintaining monstrosities that are disorganized, not composed and tens of thousands of lines of spaghetti. Writing an application in the browser deserves just as much respect as one would give towards setting up the database & schema or creating a service layer.
That lack of respect for front end code is a big reason as to why front end projects have crappy code. React is a real break from this on so many levels... Yes, you'll need (webpack|jspm|browserify) with (babel|typescript), and likely (postcss|less|scss) in place closer to the start than the end. Much like if you're writing code for a desktop application you'll likely need at least an IDE installed, and potentially several libraries close to the start.
My current tooling of choice is webpack + babel, depending on the project I may bring in scss or less, and react tooling as needed. Using CSJ or ES6 style module syntax means cleaner code that's easier to restructure. Using webpack means being able to bundle resources in a logical flow. Working on a project without webpack + babel is just painful by comparison... I'm working on an ng1 app at work that's less than 6 months old, and feels like it was written in 2011... having to add .js files to some common point, and not being able to easily refactor services/controllers/directives/components into discrete modules is pretty painful in general.
What does it take to get a Java application going? Maven, some build system, some other tooling, and understanding the component/class hierarchies? It's not any easier than working with any new tooling.
Is there some churn, yes... is it that bad, not really... going to browserify mainly means that you can have references from a starting point into your application's code... each piece requires in its' dependencies. From there going to webpack adds in other dependencies and custom loaders. Babel is a translation layer... these tools generally build on or are supersets of the tools that came before.
With C++ I can just download Visual Studio, or the Qt SDK. No other dependencies.
With Go, I download Go (a single installer) and also my Go IDE of choice - LiteIDE (a single zip).
I don't have to install an installer installer or any nonsense like that.
I think having a cli will become standard for JS frameworks. You just need to have the batteries included to capture the newb mindshare.
I'd rather deal with the dependency hell; that's an opportunity cost. I'd rather deal with my current toolchain than having to tell stakeholders that a particular aspect of bad code is beyond repair and needs to be replaced badly, at the cost of a large time sink.
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.
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.
If you're jumping through hoops to build an app that looks and feels like a traditional web site, you're doing it wrong.
Yikes.
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.
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.
https://github.com/nanote-io/nanote-web
No need to mess around with plumbing because honestly, who cares about that stuff.
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.
With Angular I feel like I have to re-learn web development and do everything the "angular way", and who knows when Angular three is coming out and the "Angular way" completely changes.
And then what are the non-javascript alternatives? It really doesn't matter much because I'll have to interface with javascript anyway if I'm a professional webdev, so why would I add even more clutter to the already cluttered web dev world?
With React, I can learn a small framework that's highly extensible and basically pure javascript. I don't feel like I have to re-learn everything I know about web-dev when using react like I do with Angular.
http://intercoolerjs.org
https://github.com/kay-is/react-from-zero