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

31–40 of 187 posts

Re: React/JavaScript fatigue

#31

Post by baddox »

zachrose wrote: post #25

I have a suggestion to this, but I don't know how to get it out there. I can't build a library because the point is to not depend on libraries. My suggestion is that if your going to build an application in the browser, your project needs an architecture that will last beyond today's libraries and tooling. You want to recognize what's unique about your app and express those parts without touching the DOM or network,…

Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state).

Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, since reducers are pure functions and actions are (or should be) simple JSON-able data.

The actual rendering of state to DOM is done completely separately by registering callbacks that listen for application state changes.

Of course, if you're using some other architecture to manage application state, results may vary.

Re: React/JavaScript fatigue

#32

Post by DCoder »

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…

React can do strongly-typed views. I use Typescript, and I can build the DOM either in JSX or by nesting React.DOM.div() and friends, and the Typescript compiler will yell at me if I use an event handler/variable/etc. that does not exist in the code. Why would I go back to an opaque templating language after that?

Re: React/JavaScript fatigue

#33

Post by hoodoof »

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 come to understand that in the reactJS world they might be reading something relevant, but then again they might be reading something completely irrelevant and in compatible (i.e. ES2015 verus JS).

Really when a new technology comes along that is a clear "winner", serious consideration should be given to just getting rid of the "old" way.

Unless Grunt and Gulp are going to somehow make a big comeback, the should be loudly killed off.

Damn - whenever I read the React documentation I have to filter out all the irrelevant code that is not ES2015. Why is all that non-ES2015 code there still?

Old tech should be visibly and loudly killed. No wonder its hard for beginners - its all the damn noise made by the "old" ways of doing things.

The react ecosystem is filled with the living dead - technology that has died but just won't go away.

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.

Beginners (and I am one) don't need to be shown every possible way to do things - they need be given a rock solid, opinionated path on the current right way to get the job done. I don't care if that opinionated path changes every month, I just want to not have to work it out by fighting through two years of zombie tech to eventually figure it out.

Re: React/JavaScript fatigue

#34

Post by sotojuan »

scope wrote: post #30

there's NO fatigue, it all depends on YOU & how you're willing to LEARN continuously Let's put it like this, there are many ways to build a house, but you don't see a builder without at least hammer & nails right? One day you see another builder with a nail gun, do you ask the builder about the machine or do you keep building a house using JUST hammer & nails? After sometime, you see another builder building a house…

Yeah, this is something I struggle with: Always trying to find something new to learn and not mastering anything. It is exhausting, but ultimately it depends on me.

That said, to me the React ecosystem is the opposite of "convention over configuration" which can frustrate a lot of beginners. There's no popular `rails new` or `ember new` to get you started.

Re: React/JavaScript fatigue

#35

Post by addicted »

scope wrote: post #30

there's NO fatigue, it all depends on YOU & how you're willing to LEARN continuously Let's put it like this, there are many ways to build a house, but you don't see a builder without at least hammer & nails right? One day you see another builder with a nail gun, do you ask the builder about the machine or do you keep building a house using JUST hammer & nails? After sometime, you see another builder building a house…

The flaw with this analogy is that when you need to revisit the house you built with a hammer and nails, you can continue using your nail gun. In S/W development, you have to go back to using the hammer and nails (or at the very least have a strong understanding of the hammer and nails). Furthermore, once you've built a house, it's built, and the work you will be doing on it will be minimal. Software development is almost the opposite.

Re: React/JavaScript fatigue

#36

Post by MatthewPhillips »

baddox wrote: post #31
zachrose wrote: post #25

I have a suggestion to this, but I don't know how to get it out there. I can't build a library because the point is to not depend on libraries. My suggestion is that if your going to build an application in the browser, your project needs an architecture that will last beyond today's libraries and tooling. You want to recognize what's unique about your app and express those parts without touching the DOM or network,…

Redux or anything similar to it seems pretty close to this, assuming you always want to stick to its basic architecture (atomic immutable application state with "reducers" that take a state and an action and return the new resulting state). Redux is so small that it's hard to see why you would need to switch away from it if you're keeping the same architecture, but even if you wanted to it ought to be fairly easy, si…

How can I write reusable components if my domain logic must be separate from my view logic?

Re: React/JavaScript fatigue

#37

Post by baddox »

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…

> the move towards more tooling is terrible for what should be something simple.

I couldn't disagree more. I think the advances in tooling around web development is extremely exciting and absolutely necessary if we as an industry want to get our act together writing complex web applications. It's worse for getting new people into programming or web development, but there are always pretty simple drop-in scripts people can use to play with things like Babel, React, or even crazy stuff like full client-side module loading with SystemJS: https://gist.github.com/cem2ran/9be3dd3499566302d5ae

> HTML/CSS/JS are not rocket science - in themselves, they're simple languages for building a user-facing app.

I think that's extremely dismissive, and woefully underestimates the difficulties one faces building a complex long-lived web application.

Re: React/JavaScript fatigue

#38

Post by lsdafjklsd »

I think the problem is that the people using React see the grand architecture in Relay / Falcor / Om.next, and are trying to recreate those API's using current libs. There are still a lot of parts missing when you try to build an app with the same abstractions as the aforementioned libraries, and I think the author is correct about 2016 being a year where those gaps are filled.

What we really need is a translation of om.next to javascript. That library summarizes all the good ideas from Netflix and Facebook into a small library for every day use. The fact that it's in Clojurescript makes it a non-starter for others, too bad because it's a really great eco-system.

edit, list technologies: React + Redux is a good start, but we need composable queries and a router (falcor) or reconciler (om.next) that manages data fetching / caching. JLongster has done some experimentation here with datascript integration https://github.com/jlongster/redux-experiments/blob/master/s...

Re: React/JavaScript fatigue

#39

Post by tptacek »

hoodoof wrote: 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…

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

Re: React/JavaScript fatigue

#40

Post by hoodoof »

tptacek wrote: post #39
hoodoof wrote: 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…

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 the assumption that they are the latest because they are better, and on the assumption that previous technologies that did the same thing will be superseded - I use them.

You can criticise this approach as just following the trends but I take this approach because it would be stupid to try to understand every single component of the ecosystem and then make my own careful choices - what is everyone else using right now? Probably good enough unless I know some good reason not to use it.

I am a beginner and struggle hard to understand the vast array of tech I need to do reactJS development. It hurts me very badly sometimes and I feel stupid because I don't grasp it all, but I have to get shit built so for the most part I'm just doing what others are doing and as I go I am learning more and more and in areas that I have gained real understanding I then make my own educated decisions about exactly how to do it in the right way.

Post reply on HN