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

101–110 of 187 posts

Re: React/JavaScript fatigue

#101

Post by wpietri »

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…

> So, you're forced to actually know more about your UI, UX, and design before you implement it.

I hope that's not accurate, because if it is, it's an enormous step backward.

Good software is always about novelty. (The non-novel parts should become libraries, frameworks, services, etc.) Building novel things requires a lot of exploratory work. And exploratory work goes best when your cost of change is low, which means keeping your batch size as small as possible. Anything that forces you to know more means larger batch sizes and higher risks of failure.

Most of the improvements in software methods over the last 20 years are related to smaller batch sizes and easier exploration of a problem domain. I'd hate to think React is pushing against that trend.

Re: React/JavaScript fatigue

#102

Post by jameslk »

I can hardly relate. Perhaps I got lucky, but my experience with the React ecosystem has not been painful. Coming from Angular previously ($watch? isolate scope?? transclusion???), it was a breath of fresh air. It might also be due to my avoidance of certain rabbit holes that are prevalent around React.

One of those being the React community's love affair with immutability (immutable.js, Redux, etc). JavaScript is not itself designed around the concept of immutability. Mixing the concepts has only led me to fight with the language and the existing ecosystem. Immutable patterns work best in a world where most things are immutable to begin with, not when you're trying to coerce a world of mutable tools to be immutable.

I'll admit, walking on some of these landmines initially was pretty painful, but I've been working with large codebases in React (SPAs and projects with tens of thousands lines of code) that I feel I've discovered the right paths to take. Here's my takeaways for modern frontend projects using React:

- Keep code organized in modules (a la CommonJS) so code doesn't become a big ball of mud.

- Use React Router to enforce that organization.

- Stick to vanilla JS- ES5/ES6/ES7--it's better documented.

- Use Grunt, and then add in Gulp when needed, otherwise you'll be writing a lot more boilerplate.

- Use Browserify, not Webpack--it doesn't try to do everything.

- Use a reactive data paradigm to keep data flow simple (observables, e.g. Mobservable works really well) instead of Flux/Redux/*ux.

- Stick to real CSS and use namespaces (or web components), not React's hijacked inlined version of it.

These practices have helped the teams I've worked in get stuff done and have scaled quite well.

Re: React/JavaScript fatigue

#103

Post by frik »

bsuh wrote: post #90
jkldotio wrote: post #64

Many of the newer Javascript libraries seem massively over-engineered compared to what you actually gain over using jQuery, or even just plain Javascript. I don't want to detract from the complexity of what some of these frameworks can achieve but at the same time it's not like they are doing complex 3D or machine learning. For me it's about readability and maintainability. I can come back to a program weeks, months…

It seems like no one asks "Just because we can use Javascript for everything, should we?" Pros: AJAX for loading content makes requests smaller making your app more performant. Cons: The Javascript framework requires a 1xx KB download before content can be rendered, making your app less performant, hurting SEO, and breaking the back button (no, I don't want to scroll again from the top through the 5 posts I already r…

ReactJS is used for the Facebook's people search page (mobile web version). Most Facebook web pages are renderer on server with PHP/HACK.

Re: React/JavaScript fatigue

#104

Post by mbrock »

tptacek wrote: post #42
hoodoof wrote: post #40

Earlier quoted context omitted.

My (simplistic) understanding is that webpack is more simple than grunt and gulp to configure. Backed up by my observation that most of the most current projects seem to be embracing it - that's enough for me, it's the current winner so it's what I use. I don't have time and I'm not interested in doing a detailed technical analysis - my approach is just to try to understand what technologies are the latest - and on t…

This response sums up something important about the Javascript development community that I cannot put into words.

My reaction to your comment is likewise ineffable and mysterious.

Re: React/JavaScript fatigue

#105

Post by mbrock »

wpietri wrote: post #101
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…

> So, you're forced to actually know more about your UI, UX, and design before you implement it. I hope that's not accurate, because if it is, it's an enormous step backward. Good software is always about novelty. (The non-novel parts should become libraries, frameworks, services, etc.) Building novel things requires a lot of exploratory work. And exploratory work goes best when your cost of change is low, which mean…

It's not. You can change stuff and build stuff incrementally just fine.

Re: React/JavaScript fatigue

#106

Post by mbrock »

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…

What does all that stuff have to do with React? Isn't it just a bunch of general purpose JavaScript tools that you decided that you needed to use?

Re: React/JavaScript fatigue

#107

Post by mbrock »

lopatin wrote: post #61

I recently adopted the "you shouldn't have to think about your toolset" and "use boring technology" mindsets. I learned React but I stopped following all other wonderful work being done by the community. It was just too much. And as a result I became happier and more productive. My passion is my pet project which uses JS, not the JS ecosystem itself. I'll wait a year for build tools to become easier and React archite…

When I started using React on a commercial project a year ago, I was totally uninterested in upfront adoption of technology other than the minimum required. So I eschewed all the Flux stuff and just used a single nested record of app state updated with the simple built-in immutability helper. We put everything in just two or three files so we didn't need any complex build tooling. We did routing by just listening to hash change events. We got up and running very quickly and fleshed out the app in a couple of months with no major problems. Later we've started using some stuff, but we did it gradually according to real needs.

So when I see people starting their projects by configuring dozens of tools and technologies that they don't really need up front, I wonder why they don't just start simple.

Re: React/JavaScript fatigue

#108

Post by Skinney »

ilostmykeys wrote: post #82
modarts wrote: post #49

Honestly, at this point, since the JS community seems to have fallen back on just lifting all of the good ideas from the Clojurescript community, why not just go straight to the source and start learning some Clojure? - You don't need to bring your own persistent data structure lib (ImmutableJS/mori/etc,) - Don't need to bring a functional utility lib (lodash/ramda/etc) - The build ecosystem revolves around a really…

I tried that for 6 months then went back to JS only to discover that within those 6 months Facebook and half of the React community had moved on to ES6, and even ES7, which meant that I just missed half a year of the most important phase in the evolution of JS. Great job, says me. I'm having to make up for it now. What nudged me out of my love affair with CLJS is when I needed to implement a really simple async patte…

> What nudged me out of my love affair with CLJS is when I needed to implement a really simple async pattern in CLJS.

What? Async/await in CLJS is:

(defn async-fn [] (go true))

(go (How is that syntactically and conceptually complicated compared to async/await?

Re: React/JavaScript fatigue

#109

Post by Skinney »

sotojuan wrote: post #92
lsdafjklsd wrote: post #52

Earlier quoted context omitted.

I'm basically saying this. At work we've started to move from Ember to React over a year and a half ago, directly because of the work David Nolen has done in the space. And now we have Redux wrapping an Immutable.js map, and are trying to piece together the rest of the stack that is om.next. It would be wayyyyyyy easier and better and less hacky to just write clojurescript. Getting people on board is sadly super diff…

Question (from a newbie): Why didn't you stay with Ember, now that it has a similar engine as React yet comes with a CLI tool and strong community conventions that get rid of any build tool frustrations?

I'll assume the main keywords are "one and a half year ago". Me personally, I like the fact that React is a library wheras Ember is a framework. React doesn't dictate how you code your program, while Ember does.

Re: React/JavaScript fatigue

#110

Post by hakanderyal »

hoodoof wrote: post #40
tptacek wrote: post #39

Earlier quoted context omitted.

Sell me on Webpack, and, in particular, on why I should care about this particular bit of plumbing.

My (simplistic) understanding is that webpack is more simple than grunt and gulp to configure. Backed up by my observation that most of the most current projects seem to be embracing it - that's enough for me, it's the current winner so it's what I use. I don't have time and I'm not interested in doing a detailed technical analysis - my approach is just to try to understand what technologies are the latest - and on t…

From my limited POV, this is how I see most of the newcomers to JS community currently behaves. And it's a good example of 'learning by doing', which is the advice that everyone gives around here.

- Do some research, look what successful/smart/sane people are using/working on, and why.

- Jump in, hack stuff, make things work.

- Learn while creating. Discover the insights behind the choices that people you're following made.

- Start making your own informed choices.

As long as you're not stuck in the step 2, and advance beyond doing what everyone is doing, you're probably on the right track.

That's how I learned to build maintainable/scalable/successful applications.

It worked out perfectly for me.

Edit: typo, clarified first sentence.

Post reply on HN