I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS
> We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.”
What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'.
I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.
I've recently been looking at job boards, and "React" turns up a lot. As does Angular, but not as much as a year or two ago.
So it's not so much about whether a given tech works for your project or not (being honest, server-side rendering + dash of jQuery is probably more than adequate for a lot of sites going full-on React+Redux right now) but fear of your skills becoming obsolete. Given the shit-show hiring is right now with its resume filtering and whiteboard hazing (witness every other week on HN) that's not an unfounded fear. So in order to have something on our resume that we used React in our last job, we use React for our current project...and so contribute to the problem.
If you see a lot of jobs requiring React, or are fear becoming obsolete, then just learn React. It's very very simple - the API is like 5 functions, and the documentation takes like 20 minutes to read from start-to-end.
Don't learn anything else - just learn plain vanilla-React. The site has a onepager.html 'blueprint' to work from.
If people are getting anxious about this, its more than likely self-inflicted from trying to learn 30 things at once that you don't need.
It's not just React, there's a huge ecosystem developing around it that is undergoing constant churn - see react-router or babel for example. And then with Redux you have a whole subsystem around that - redux-form and sagas and react-redux-router (or is it react-router-redux?). Then we have the GraphQL/Relay train leaving the station. Oh, and I've not even touched testing tools yet, or webpack (a whole other ecosystem on its own). Or CSS modules or...
But let's say I did learn all that (in fact, I did recently for a personal side project). It doesn't matter a bit for applying for a job. Why? Because I don't have real work experience using these things. So in order to have that, I have to somehow leverage React into my current job so it can go into my resume.
Sure it does! When I interview people, I tend to give a fair amount of weight in their side projects, because it's something they were actually interested in.
But that's not standard industry practice. Nobody looks at your Github - except maybe at the final stages of the process. In the meantime you have to get through a lot of filters.
Well, maybe my viewpoint isn't the most common. But I can at least say that it does matter to some companies / interviewers.
My resume has a link to my github and I specifically call out 3 or 4 projects. If you want your side projects to count in an interview, that's probably a good place to start - if nothing else, you can at least use them for buzzword bingo to get past HR ;)
But you don't need to learn all of that! That's what I mean when I say self inflicted. If you feel the need to learn all this BS, no wonder you're feeling fatigued.
We just built and released a Very Big Project using React, Redux, and React-Router. Smooth sailing. Zero JS-Churn. No one had any issues being overwhelmed. We never went crazy and threw in every hot new library we heard about on Twitter.
You're missing the point. You're talking about what you used for your project. I'm talking about learning skills so I can walk into an interview for a job that says "we need React developers". They may use any number of these things I mentioned, or are thinking about using them, and will bring them up. As a "React developer" I have to be aware of the ecosystem. So it's not just "learn an API with a few functions".
And, as I said, it matters not whether I learned these things on my own: to Get the Job you need to demonstrate real-world experience.
I strongly disagree with the idea that you need to know how to use react-saga or react-redux-router to walk into an interview that name drops React.
Like, it would be a huge plus from a candidate if they even knew the name GraphQL/Relay, but I wouldn't want to work somewhere that expected me to know it completely.
I'm not anxious about it, because I don't have to deal with it, because I continue to focus on interesting problems which are almost entirely unrelated to building web sites. But I choose that in no small part because the world of web development appears to be an insanely unstable froth of fads and complication offering tons of tweaky API-fiddling and not much in the way of abstract design problems. Besides which I just don't see a lot of value in JavaScript and wish people would stop writing so much of it and trying to convince my computer to run it for me.
> We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.”
What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'.
I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.