Live data from Hacker News

React/JavaScript fatigue

medium.com

61–70 of 187 posts

Re: React/JavaScript fatigue

#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 architectures to stabilize. Until then, my code won't be the holy grail of immutable flux, but my users will never know that. My re-builds take a couple seconds and I don't have hot code reloading. And I'm ok with that.

I work with (what I consider to be) the bare minimum: React, Babel, Browserify, and fswatch. It's all wired together in my Makefile. It works pretty well. When something clearly needs improvement then I'll address it. Maybe I'll switch to Webpack and integrate hot code reloading to improve build times when I have some free time. But only as a luxury. I can get by without it.

The above sounds easier for build tools than for JS architecture. After all, switching from Browserify to Webpack is a lot easier than refactoring your code from your existing setup to something like Relay, Om, etc... What I say to that is this: Gradually integrating flux (vanilla or Redux) into an existing React app is actually very simple. Extract local state, throw it into a store, and add a subscription. I wouldn't expect any refactoring headaches at all if your component hierarchy makes sense. Everything else (for example anything related to GraphQL, ClojureScript, you see where I'm going) counts as "not boring technology" and significantly increases the risk of being pulled back into the unproductive search of JavaScript enlightenment.

I certainly don't want to discourage library authors in any way. If that's what you're passionate about then don't let my jaded thoughts stop you from building something great. We are in a period of great discovery, innovation, and change. I just wanted to share my thoughts about making a conscious effort to minimize my toolset and accepting the tradeoffs of not having the latest tech.

Re: React/JavaScript fatigue

#62
post #42
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.

Given that front ends have a huge visual component, it kind of makes sense that developers would approach them like clothing fashion: you don't have to watch the designers to look reasonably good, or even pay attention to construction, you just have to watch everyone else.

Well, at least that's what I picked up from this rather honest opinion.

Re: React/JavaScript fatigue

#63
post #21

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…

It all depends. React as of right now is the only viable option that has decent server side rendering for 80%+ of web apps it's a must for SEO, FB integration etc. Until Angular 2.0 ships and Ember get's fastboot completed there is no other major viable option.

[deleted]

Re: React/JavaScript fatigue

#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 or years after it is written; I most likely want to just be able to read, understand and edit it quickly. As soon as something has a huge infrastructure, setup, tooling, transpiling or whatever it just becomes burdensome.

Intercooler.js (http://intercoolerjs.org/) demonstrates a good philosophy.

Re: React/JavaScript fatigue

#65
post #33

The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell . How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even co…

Why not just npm scripts instead of webpack/grunt/gulp?

Re: React/JavaScript fatigue

#67
post #33

The problem is that new and better ways to do things come along (ES2015 versus JS, webpack versus grunt/gulp), but the old ways hang around like a bad smell . How the heck as a beginner are you meant to fight your way through all the noise of the old, bad ways of doing things? How is a beginner meant to know that really they should be using ES2015 and webpack rather than JS and gulp/grunt? How does a beginner even co…

Things should remain backward compatible but only for a very short window, it's really unhelpful to have many many different ways of doing the same thing, it fragments everything including the learning curve. Witness Perl. Sounds like a terrible way to build commercial software. The problem isn't that old things don't die away quickly - far from it - the problem is that we have too many new things coming in that keep…

> If I could get away with a Makefile, I probably would.

You kinda can. I'm seriously considering that in conjunction with " rel="nofollow">http://entrproject.org/> for watching file changes.

I wrote the book Automate With Grunt out of anger at the terrible docs for Grunt and my displeasure that there was yet another build system out there. And just as the book was released, Gulp came along. Then Webpack. And now there's tools like Brunch.

I still use Grunt, because I spent time learning it. And I'll be damned if I'm going to waste time learning a new tool without a really good reason other than "Coke vs Pepsi".

(edited for organization because I'm tired.)

Re: React/JavaScript fatigue

#68
post #10

Earlier quoted context omitted.

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

Can you point me to one that'll help me actually get something workable up and running? You say you have one; I assume it's something you've put together over the time you've worked with React, and not something you just pull in from someone else's repo.

I use very basic npm script with browserify to watch/build the output. browserify uses babelify transformer.

Re: React/JavaScript fatigue

#69
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'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…

Any write ups why your team moved from Ember to React? Seems like the recent tenets of Ember coincide with Reacts's componentized architecture and one-way data. Also if you were able to convince the team to go from Ember to React, appears as though the opportunity to switch to clojurescript was there (although react is the hotness right now so convincing was probably easier).

Re: React/JavaScript fatigue

#70
post #9

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 i…

The last time I felt productive doing UIs was with WinForms and before that VB6.
Post reply on HN