In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?
But honestly, I'd go with React if you can. The reason is, if the app starts taking off, and you end up with a team maintaining your app, you're much less likely to end up with an unmaintainable mess in two years than if you use just jQuery.
All applications, especially websites want frameworks. The framework is essentially a way to organize the massive amount of complexity boiled in. If you just roll with libraries, then you end up cobbling together a framework on top of it. You will then have to maintain this framework. This is fine when it's just you, it will coalesce into a bunch of conventions that's fairly easy for you to reason about.
But once you start involving others, then you're going to see your nice conventions get rekd like a bull in a china shop. Not everybody sees problems the same way you do.
If you pick the framework beforehand, then you don't need to maintain it, you can let the nice people at Facebook / Google do it for you. And whenever you finally get others involved, they're limited in the amount of architectural damage they can do because they have to stick to the conventions of the framework.
1. 'if' it's an actual app and not a web page with a smattering of interactivity
2. 'if' by 'take off' you mean becomes a moderately complex SPA
3. 'if' there's no alternative that is simpler and more maintainable (another excuse to plug intercooler.js here)
There aren't enough people saying "Are you sure you need a front-end framework?".
I've worked on several projects that had <insert framework> for no real reason other than the dev wanted to learn it. There is a threshold where it makes sense to use React or similar - but that threshold is being set way, way too low.
And you suddenly end up with great globs of javascript in a page that might not need it.
I guess I was also assuming that if the OP was considering using React in the first place, that they were doing more with jQuery than just minor interactivity improvements. But I suppose your concerns are valid if that assumption isn't true. I'm thinking app, not blog.
I saw a comment from someone a few weeks ago who knew angular but had never used jQuery. I was rather baffled how that had come to pass!
Angular was a huge step up in "you won't shoot your foot off-ness" and React is a step further. You still can, but you realize that you're loading the gun most of the time and can take a step back.
And that is really all this churn is about -- trying to make things easier and more foolproof. We've introduced other problems trying to solve the first couple batches of problems (accidentally using the development version of Reach on production is one I see a lot), but we'll get there.
The PHP ecosystem has had quite a bit of churn in the last 5 years too, but the yelling about it doesn't seem to be as loud since people aren't forced into it since there are alternate languages.
Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.
You don't need to know all the toolchains and crap if you just use create-react-app.
Is there a good tutorial out there for lapsed front-end devs?
So I threw out everything, and just started from HTML on Gitlab Pages. I've added on CSS, and just started adding in little JS functions. I can now (sort of) appreciate frameworks. React seems to be a popular choice.
Also, the site loads so much faster, esp. when HTTP/2 is not an option for you (because your hosting does not support it or whatever).
I won't argue, though, that a complex web app should be built on a proper framework.
I love the hand wavyness of this! Yes, you DO need to know the toolchain. Because if you don't, it is going to be murder on you if you need to track down why something isn't working.
Professional developers need to use professional tools and understand them deeply. There's no compromises here.
The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.
When I think complicated, I think of code that's hard to understand, hard to modify, or hard to find things you're looking for in. In that example, everything is exactly where you'd expect it to be:
1) Where do I render / present my data? In the presentation components.
2) Where do I take data from the store and pass it to my presentation components? In the container components.
3) Where do I modify data in my stores? In the reducers.
4) Where are my reducers exposed to my container components? In the actions.
Maybe this kind of structure is overkill for a Todo list, but for a complex SPA, this kind of structure is useful and almost makes it _easier_, not harder, to find the things you're looking for. The app I work in is constantly growing and getting more complicated, esp. in regards to the quantity of features, yet I don't find it to be getting harder to go back and find or change things. I think this is due to the functional nature and design of React combined with the architecture we chose that makes this possible.
And in terms of LoC, that example doesn't seem to be much different from the Angular / Backbone implementations of TodoMVC.