Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React/JavaScript fatigue

medium.com

Post reply on HN
Print view View original

11–20 of 187 posts

Re: React/JavaScript fatigue

#11

Post by Touche »

onewaystreet wrote: post #7
thirdreplicator wrote: post #6

I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and fi…

> gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.

After 300+ lines of config spread over 3 files.

Re: React/JavaScript fatigue

#12

Post by capkutay »

whistlerbrk wrote: post #5

The massive amount of great tooling and debugging for React is a strength not a weakness. If people are overwhelmed by React I feel it is likely because: 1. they haven't yet grokked the implications of how re-rendering every single time changes how they have to store the state of their app. (von neumman) 2. related to that, the choice of how to store that state and dispatch to a backend is not baked into React 3. it…

I think people try to get started with react and they jump to the boilerplates that are 'production ready'. Those boilerplates include routers, frameworks to bind routers to state, frameworks for server-side rendering, some new ES7 syntactic sugar, a bleeding edge module bundler like Webpack...the list goes on. They may or may not be a great combination of frameworks, but each has their own learning overhead.

So people confuse learning react or learning redux with learning how to use every single framework shipped in the common react boilerplates. It can take weeks of studying or learning enough about those frameworks to understand how they all work.

React itself is moving along at a healthy pace. Popular frameworks around react change about every week which causes this fatigue that OP speaks of. The most important thing IMO is learning the core concepts behind react, flux, redux, react-router, and worry about product client/server rendering and module bundling later.

Re: React/JavaScript fatigue

#13

Post by moonchrome »

Bahamut wrote: post #3

This is probably my biggest criticism of React (and by extension similar such as Angular 2, although React's choice of JSX is a clear exacerbation of this problem) - the move towards more tooling is terrible for what should be something simple. HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app. It is developers making things more complicated by having us use a…

Angular choses TS (well it's optional but so is jsx).

This is also my no.1 pain point with typescript - they focus on the typechecking part only - you want new JS features ? Use custom js transpilers, polyfills, etc. This means setting up custom typings, build system, module loader, etc.

JS land is just a huge mess to put it nicely because of th inherent problem with browser portability but its made much worse by the low barrier to entry community full of noise. I wish Dart had a better JS interop and faster compiler, in theory it solves all of my JS pains (excellent std lib, sane semantics, default package manager, modules from start, etc.) - in practice it produces big js files, compiling takes forever once you include frameworks, talking to JS is c ffi level of tedious (from what I understand they are working on improving it but its still non trivial with a significant performance overhead)

Re: React/JavaScript fatigue

#15

Post by ebola1717 »

Hm, I found that one of the strengths of React is that it's so easy to sidestep a lot of the complexity of it, if you're not building a true SPA. We use React to add some interactivity to our forms and dashboards, so we only need to use state & props. No Flux/Redux/etc backends, and not much messing around with webpack & co.

Re: React/JavaScript fatigue

#16

Post by sergiotapia »

onewaystreet wrote: post #7
thirdreplicator wrote: post #6

I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and fi…

> gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.

"Replace this garbage with this other newer garbage."

Re: React/JavaScript fatigue

#17

Post by sudo_bang_bang »

Build tools are partly necessary because of how many old crusty browsers hang around out there. I mean, I still work on an app that has to support IE8. That's just ridiculous. As it is, ES6/ES7 imports make a lot of the issues of JS inclusion a thing of the past, but the build tools are necessary for packing these together and transpiling down to ES5, to support older browsers. The other tools you see in the React ecosystem do take time to learn for sure. The whole React/Flux paradigm takes a while but once you get it there's not many surprises. I do feel the fatigue though just as the author does. There's a million ways to do what the browsers should just do natively already. In a few years we hopefully won't have to worry about this anymore.

Re: React/JavaScript fatigue

#18

Post by dcsan »

meteor works nicely with React. It may not be the most optimum route (problems with webpack, outdated node, crappy testing) but is a decent curated way to get started.

The official react stack will be supported going forward, and the velocity of changes is not quite as much as the a-la-carte JS environment.

Re: React/JavaScript fatigue

#19

Post by pavel_lishin »

onewaystreet wrote: post #7
thirdreplicator wrote: post #6

I was thinking to put React.js in my adopt circle, but I spent a couple of days setting up the Node.js gulp-vinyl-browserify-babelify nonsense, and it really is a witch's brew of configuration hocus pocus. Its compelling to know that React is backed by Facebook, but React is simply verbose and comes with too much stuff packed into one package. Whats the alternative? Thanks to hacker news i bookmarked vuejs.org and fi…

> gulp-vinyl-browserify-babelify nonsense Use Webpack. It replaces the need for all of these and does a much better job.

Doesn't that just glue them all together? We're using it at work, and we brought in an in-house React person, but I have no idea what the config does/signifies, and every time they change something, I absolutely don't understand why or how it works. (Our tests currently don't work. I mean, they can run - unless there's an error, in which case it exits early with a 0 status, without running any of the subsequent tests.)

This is partially on me - I should read the shit out of the docs - but so far it seems like it just paints over the complexity a little.

Re: React/JavaScript fatigue

#20

Post by sergiotapia »

I was lucky that I started on React from within Meteor. Meteor builds everything automatically, and does not require you to spend 5 days tweaking a brittle series of config files.

Last week, I wanted to start a React app that talks to a Phoenix API and found out there's a ton of different ways to create a react app. That sucks. There is no 'one obviously better way.' Kudos to Ember for being great in that area. React needs to have an obvious way to start and run an app. Not this gulpwebifypack config garbage

Proof is in the pudding, check it out! http://sergiotapia.me/2015/09/18/react-and-meteor-match-made...

Post reply on HN