Hacker News Reader

Comment by stupidcar | Hacker News Reader

Tell me about it! Literally all you need is React.

Oh, plus react-router for routing, I guess. And Redux, obviously. Plus react-router-redux to link them together, and react-router-scroll for scroll history. Also react-intl to handle internationalisation. And react-helmet to do document header stuff. You'll need to use immutable as well, obviously, so you'll need redux-immutable. And redux-saga. Hmm, you'll definitely need a selector library like reselect. Better throw in reactcss too. Gotta get them inline styles going!

Anyway, just those and a couple dozen other libraries and you're good to go. Then once you've set up Flow types, Babel compilation, isomorphism, bundling with hot module reloading in Webpack, linting and testing, you've got a rockin' React app. Easy as that!

View on HN

I've used React by itself for over a year before I ever reached for anything else you mentioned there. I eventually picked up many of the other things you mentioned too, and they were very useful, but they were very far from being necessary to make use of React, and I probably would've wanted them or something close if I didn't use React.

they may not have been necessary for your projects, but they're absolutely necessary for any real-world production grade apps. Angular is solely targeted in that direction. 90% of the React examples I see when I interview people are handlebars/mustache 2016, and would be better solved with server-side rendering in the first place.

I think OP has made a mistake calling it a framework as it is not a framework, it is a library. People have added more libraries to it. On the contrary, yes Angular is a bonafide kitchen sink framework missing the major advantage of a framework: A STABLE somewhat opinionated stack. You are correct though that making React into a "framework" is a hot mess.

While React is certainly more lightweight in many respects that something like Angular or Ember, I still think it qualifies as a framework.

For me, the primary difference between a library and a framework is the the typical direction of instantiation and calls between your own code and that of the library/framework, and the ownership of the main workflow / event loop. E.g. does it feel like your code uses the 3rd party code, or that the 3rd party code uses yours?

Putting it more concretely, when you code is executed, does the 3rd party code tend to come after it in the stack, or before it?

With a library, you're mostly calling its methods. So, a library is something like jQuery, where you're just making a lot of calls to its methods. Those libraries might do some very complicated things, but they're still just operations that you have launched, and which eventually return control to your code.

With a framework, you're inheriting from framework classes, and conforming to a workflow that the framework controls. For me, that describes React. You write in its JS dialect (jsx), your classes inherit from React.Component, and you hand over control of the rendering workflow to ReactDOM.Render and the virtual DOM.

I agree. React is far too opinionated for me to treat it as just a library. I use it as a framework just as I would use Angular, and it fits the bill. That it can also be used as just a library is a bonus, but doesn't define its identity.

I'd much rather select the libraries and frameworks I want to use than some huge monolithic beast of a framework. Oh did I mention that all the libraries I select in the react echo system are just JS? Not some massively proprietary framework like angular? yeah.

Lmao, this is exactly how I've felt, and why I'm using ordinary js with closures and a bit of jquery for the time being while I get up to speed and figure out wtf is going on.

"Javascript the good parts" has served me well.

Eh, it really is not that bad. With just React and a fetch polyfil (to replace jquery's ajax) you can get pretty much the same power as with just jquery.

This will all settle down in a year or two, once we get the most basic features built-in into browsers. Like for example modules + HTTP2 will probably mean no more bundlers or build tools (which is where the vast majority of this craziness is coming from)

Made the switch to HTTP/2. Using push with minified/gzipped/cached assets. Loading all my assets is typically a 6ms affair for all of react, react-dom, redux, custom JS, custom CSS, and additional PWA files. Mind you, dev machine.

If what you're trying to accomplish is feasible and maintainable with "ordinary js ... and a bit of jquery" then using a full React+Flux stack like the OP outlined is complete overkill. If someone has experience with those libs and tools then they'll probably use it even for trivial projects. However that does not mean it's prescribed for _everyone_ to use _every time_ they need to write a bit of javascript functionality.

I really wish people would qualify what they're trying to accomplish when they bang on about things being "needlessly complex". Maybe for what they're doing it totally is and they shouldn't be distracted with React, Flux, Webpack, etc. There's nothing wrong with that. However, when taking on a project where these sorts of things are immensely useful, it's nice they exist.

Sure, but tell me what isn't feasible? Ok, I'm not creating photoshop in a browser, but there have been some non-trivial highly interactive apps I've built and they are still modular and serve their purpose well.

I'm not saying we shouldn't get on react - I'm sure in the end it will serve myself and others well, but it's a bit of a headf*ck trying to figure out the whole ecosystem, and how to write a good solid app in it. For anyone that tries to say "but it's only react with x" - No it's not! Not for anyone that cares about the quality of their app, theres a whole heap to learn.

And I am learning, but at the same time I'd rather create a well designed app with the crummy tech I know than a crummy app in something I just haven't figured out yet. Luckily I'm doing my own thing so have that choice.

... and this is how major diversity spawned in the frontend business the last couple of years... Seriously, though, a lot of companies still gets it on with mediocre frontend developers that still rocks jquery solo. It might be down to down company culture or just an unlucky set of colleagues.

I'm no frontender, but lucky to be in a team that got that sh!t under control, luckily.

I know you're using webpack but you could really add gulp to manage webpack and then manage gulp with grunt and then manage grunt with npm.

I mean why use one package manager/module loader when you can use 4?

This is exactly why I don't buy the argument that frameworks are so much easier to use and learn than languages. I look at the state of JS these days and shake my head in disbelief. When did it get so needlessly complex? More importantly, WHY?!?!

People who aren't doing complex things start using libraries that are designed to manage complex things, even though they don't need them, then complain that they're overcomplicated. Repeat ad nauseam.

Reply on news.ycombinator.com