4 ms·

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

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.

thatswrong0 10y ago
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 10y ago
  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 10y ago
    None of those things has anything to do with the inherent simplicity of the library itself.
    - andybak 10y ago
      Out of the two simplicities one has an actual impact on usage.
      - thatswrong0 10y ago
        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.
        andybak 10y ago
        Maybe he was but I do worry that anyone new to front-end is being pushed towards frameworks rather than being told to start with the simplest approach possible. 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!
dhruvkar 10y ago
Good point. Having heard the same from other - "jQuery is OK, use React for new projects" - I'll focus on that then.
greg5green 10y ago
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 10y ago
  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.
andybak 10y ago
> 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 10y ago

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 10y ago
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 10y ago
  None of those things has anything to do with the inherent simplicity of the library itself.
  - andybak 10y ago
    Out of the two simplicities one has an actual impact on usage.
    - thatswrong0 10y ago
      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.
      - andybak 10y ago
        Maybe he was but I do worry that anyone new to front-end is being pushed towards frameworks rather than being told to start with the simplest approach possible. 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!

dhruvkar 10y ago

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

greg5green 10y ago

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 10y ago
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.

andybak 10y ago

> 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.