[dhruvkar]

I couldn't get through the entire thing. Even knowing that it's a fun/sarcastic piece of writing, the portrayed pain is all too real, as someone just starting to dive into the front-end.

In all honesty, can I still use jQuery for new projects without issues in 2016? Is there a real reason not to?

[vinceguidry]

Yes, you can. No, there's no 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.

[andybak]

> if the app starts taking off

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.

[thatswrong0]

I agree - I think React is simple enough that there's no reason not to besides the overhead of JSX preprocessing (which I suppose isn't required but I would definitely recommend). It really is more of a library than a framework, which is great for starting out because there are fewer concepts to understand. Then when you start adding more people and your application gets more complicated and you need to manage your data flow in a more consistent way, you can add something like Redux after the fact incrementally. As long as you don't let components become too large, refactoring isn't too difficult.

[andybak]

React isn't that simple. You still have all the package manager/transpiler/build baggage. You still sacrifice pages that aren't blank if javascript is disabled of fails and all the potential SEO/accessibility costs of that.

And you suddenly end up with great globs of javascript in a page that might not need it.

[thatswrong0]

None of those things has anything to do with the inherent simplicity of the library itself.

[andybak]

Out of the two simplicities one has an actual impact on usage.

[thatswrong0]

I guess what I really meant to say is that you could levy the exact same concerns on many other libraries / frameworks. None of that is specific to React.

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.

[greg5green]

This a great comment. Yes you can still use jQuery and yes it's still very powerful, but it lets you shoot your own foot off too much -- and your whole team's feet are in danger too.

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.

[frankquist]

But getting started is simpler with PHP, also. The framework you'll use (Laravel, Symfony) and is associated coding paradigms will probably be a different one than 4 years back (Codeigniter, CakePHP, w/e), but apart from that composer is pretty much the only new tool you'll use apart from that. No webpack/browserify/transpiling/gulp/bower/whatever.

[dhruvkar]

Good point.

Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.

[JustSomeNobody]

As long as you stop reading popular blogs and all HN javascript posts, you can use whatever you feel will get the job done. Likely, you'll get it done faster than someone who reads all the popular blogs and chases the shiny.

[natmaster]

React is really very simple. It only takes a short amount of time to learn it, and then when you do you won't get headaches all the time trying to keep track of state.

You don't need to know all the toolchains and crap if you just use create-react-app.

[theseanz]

I did not have a simple experience with React. I did front end development for years, ending with jQuery-driven AJAX sites pulling from REST APIs (2013), and when I tried to learn React this year it was all voodoo.

Is there a good tutorial out there for lapsed front-end devs?

[jpinnix]

reactforbeginners.com

[dhruvkar]

Good to know. Just trying to find a thread (in front-end dev) to latch on to was challenging.

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.

[majewsky]

I would argue that, for a lot of sites, plain HTML + CSS + little JS functions is the right choice, because building stuff in plain JS is more painful than with frameworks. Having to do it in plain JS makes you think more carefully if you really need this JS. (At least, it does that for me.)

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.

[frankquist]

I also like Vue.js and am surprised it's not getting mentioned much. But it's nice for starting out, in my opinion, since you can pretty much decide if you go all-in. It's quite possible to just use it to sprinkle some JS here and there, but also possible to build SPAs with it.

[dhruvkar]

That's what I'm looking for. I'll check it out, thanks.

[JustSomeNobody]

> You don't need to know all the toolchains and crap if you just use create-react-app.

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.

[gschrader]

While I agree you need to know the toolchain, create-react-app is a professional tool, it works very well. I've struggled before configuring webpack/babel/etc. manually and while it may "murder" me down the road one can always eject if need be.

[atemerev]

React is simple, right until the point it isn't anymore.

The point of breakdown probably starts with Redux. There is no simple way of structuring multi-component pages in React. All is suddenly complicated.

[thatswrong0]

I'm confused what you mean by "multi-component pages". I work with a mildly complex React SPA using a library like Redux and we haven't really had issues with things becoming too complicated.

[atemerev]

http://redux.js.org/docs/basics/ExampleTodoList.html — this is already too complicated (13 JS files for a todo list!)

[thatswrong0]

Maybe it's because I work everyday in a React codebase that is sitting at 150k+ lines of similarly structured code, but I don't find that to be complicated at all. Structure almost always adds overhead, but with the benefit of adding consistency and familiarity. The # of files does not indicated to me how complicated something is.

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.

[thatswrong0]

* almost always