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

1–10 of 187 posts

Re: React/JavaScript fatigue

#3

Post by Bahamut »

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 whole smorgasbord of tooling to optimize for using [insert feature] instead of trying to keep things as simple as possible.

I just hope that over the next few years that this simplifies so that we don't need to have build tooling run everything.

Re: React/JavaScript fatigue

#4

Post by bradhe »

I seriously don't understand the issue here.

I find the overhead completely negligible. I've worked on many React apps. I've worked on innumerable apps in other, different frameworks, tools, etc. too. I still find my React stack (I say "my" because I'm sure my stack is different than yours in one way or another) to be the best solution, and this debate to be tedious.

That said, I feel like every ecosystems works this way: Complaints about lack of good tools/solutions, myriad tools/solutions are built, then there are complaints about the overabundance of tools and complexity of the ecosystem, so everyone abandons whatever the status quo is, and then...back to square one.

Re: React/JavaScript fatigue

#5

Post by whistlerbrk »

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 is harder to build an app up slowly because you have to have a rough idea of what the structure of your app state looks like ahead of time.

So, you're forced to actually know more about your UI, UX, and design before you implement it. It takes longer to implement but once it is done, it's done and easy to improve upon - it's not fragile.

For hacking something together it might not be the way to go. But for a well thought out implementation of an app which interacts a lot with it's backend, I think it's the only way to go now.

I also feel like people will be missing the React wave at their peril. We're on the verge of being able to cleanly abstract out an applications delivery mechanism whether its native, mobile, or web. That is because of things like React and ReactNative and it's immutable render-every-time approach.

Re: React/JavaScript fatigue

#6

Post by thirdreplicator »

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 finally got a chance to come back to it. I made a couple of pages with vue.js, and I think there is a lot less stuff to do. There's no JSX. Your HTML peppered with vue.js directives is your templating language. There's no server side rendering, but that may be a good thing in the end. Fewer dependencies, less learning curve, less ecosystem to swallow in a single gulp. I hired a fresh grad from the Philippines, and he was able to pick it up and run with it immediately. I've only been using vuejs over Christmas, but I'm looking forward to seeing what else it can do. I'll post a small PHP-backed CRUD app if people are interested.

Re: React/JavaScript fatigue

#7

Post by onewaystreet »

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.

Re: React/JavaScript fatigue

#8

Post by orf »

bradhe wrote: post #4

I seriously don't understand the issue here. I find the overhead completely negligible. I've worked on many React apps. I've worked on innumerable apps in other, different frameworks, tools, etc. too. I still find my React stack (I say "my" because I'm sure my stack is different than yours in one way or another) to be the best solution, and this debate to be tedious. That said, I feel like every ecosystems works this…

> (I say "my" because I'm sure my stack is different than yours in one way or another)

I think that's the problem. For a beginner what is their stack? It's a wild west of 'this months hip library' and for a beginner it's unintelligible.

Re: React/JavaScript fatigue

#9

Post by pbhowmic »

This is something I have observed about every language/framework front end combo I have ever used and I have done it long enough to go all the way back to Qt 3 and even before. There is no terse way to describe a UI. Period. C++ or Java I understand they are typed languages with an avowed aim of giving the programmer fine grained control over the program. Objective C may have become popular more recently but it too is an older typed language. The unbrevity of JavaScript is inexcusable and it extends to every UI framework it offers. Tooling is no way to try and ease the problem.

Re: React/JavaScript fatigue

#10

Post by bradhe »

orf wrote: post #8
bradhe wrote: post #4

I seriously don't understand the issue here. I find the overhead completely negligible. I've worked on many React apps. I've worked on innumerable apps in other, different frameworks, tools, etc. too. I still find my React stack (I say "my" because I'm sure my stack is different than yours in one way or another) to be the best solution, and this debate to be tedious. That said, I feel like every ecosystems works this…

> (I say "my" because I'm sure my stack is different than yours in one way or another) I think that's the problem. For a beginner what is their stack? It's a wild west of 'this months hip library' and for a beginner it's unintelligible.

> It's a wild west of 'this months hip library' and for a beginner it's unintelligible.

What's wrong with the "just pick one" approach??

Post reply on HN