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.
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.
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.
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.
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.
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 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.
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.
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.
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.
> 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".
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?
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.
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.
>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.
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.
> 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.
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.
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.
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 :)
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.