This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just ramping up on whatever the new hotness happens to be?
> 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.
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.
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.
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.
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.
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.
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.
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.
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 ;)
It's also just got a lot faster (3.4 had huge speedups) supports HTML5 components and supports IE back to 7 (while that's not a requirement for me it's nice to know the tools you have will work if you need them to).
There are features in newer libraries I like but taken in balance I like been able to grab the code I wrote 2 years ago and have it still work with knockout's latest version, to me that is it's killer feature.
Also there is this http://knockoutjs.com/spec/runner.html
I've always approached it as "if the DOM is too slow, I must be trying to do far too much. Scale it back and re-think the problem"