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
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.
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 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
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.
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.
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....
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.
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.
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...
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...
I like programming, I like different languages. Just few days ago I was once again lurking on other languages' sites and forums just to find something new. I realized when looking at other languages that JS has come a far way and now offers so much that I really like JS. I got spoiled and the urge to try, find and need something better has faded.
The language itself made huge leaps with ES6 and the ecosystem is just incredible. I see that fast pace as something positive and the 'JS churn' is relative or rather exaggerated. Node itself is very stable and new versions do not break old stuff in general. Grunt and Gulp got replaced by Webpack, React + Redux redefine UI. That's it, these are the typical examples in mind when people talk about 'churn', not really a lot to be worried about. And these changes didn't happen over night but over years, e.g. the first React version was introduced two or three years ago.
A counter example to churn: Express is still the to-go web app server for many years (5?), it's doesn't have the most modern foundation and other stuff (e.g. http2 is problematic) . I wish that new web app servers like Koa, Express' successor, would gain more traction but that happens only slowly.
It's a little opinionated but aligns well with the decisions I independently made after spending way too much time on "build tool bullshit". That said, it's a little rough around the edges and development is not very active.
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.