Live data from Hacker News

My Reaction to React

pseudoconcurrentthought.wordpress.com

31–40 of 147 posts

Re: My Reaction to React

#31
post #12
post #10

Earlier quoted context omitted.

Can't blame the tools for a lack of decent developers any more than you can blame a spell checker for illiteracy.

True; us, the Web community (which also built the frameworks) as a whole, is to blame.

> Can't blame the tools for a lack of decent developers any more than you can blame a spell checker for illiteracy.

> True; us, the Web community (which also built the frameworks) as a whole, is to blame.

Doesn't this come across a bit naive?

Is the suggestion that web development is somehow different than all other software development? or that unless you're one of the ~0 people who are able to build a usable programming language, OS, and libraries on top of them, that you're not a "decent developer"? Because while I get you're discussing JavaScript frameworks. "Learning the Framework" and not the details, has been the only reason software development has been able to scale so beautifully. Frameworks that lower the relative complexity should and are encouraged in all other forms of software development, why should web development be different?

Re: My Reaction to React

#32
post #7

Components are easy. Just write a function... Until you want to automatically unregister event handlers when the component is removed Until you want to compose them and select child and parent components without traversing the DOM Until you want to pass options to the components in various ways, and have default values for them Until you want to store component state and re-render part of the component whenever somet…

Are you making an argument against react or an argument against writing react in a pure functional style?

Because unless I'm very much mistaken:

ComponentWillUnmount Props Props state

for the first few complaints.

React is just the view layer, arguing against react because "you need a framework" is like arguing that no one should write their own applications without a framework. It is a separate discussion than what to use for the view rendering.

Re: My Reaction to React

#33
post #26
post #19

Earlier quoted context omitted.

There is no 'one true way'; as long as your app works and you can hold it in your head, everything is fine. With all due respect, this is the major criticism of adopting React, given that it's still in active development and given that many who are looking at using it have established apps using other patterns already.

React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it. You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that…

You don't need to sell it to me, I see the advantages--but precisely because I understand those advantages, I actually intend to complete my next project with Cycle.js [1].

[1]: http://cycle.js.org

Re: My Reaction to React

#34
post #7

Components are easy. Just write a function... Until you want to automatically unregister event handlers when the component is removed Until you want to compose them and select child and parent components without traversing the DOM Until you want to pass options to the components in various ways, and have default values for them Until you want to store component state and re-render part of the component whenever somet…

Well said Sir.

Re: My Reaction to React

#35
Has anyone wondered how similar in spirit React is to the way html and js were originally meant to be written (with embedded callbacks, e.g. ``)? Isn't the `a` in some sense a React component with explicit and local state changes, only missing a explicit render? Theoretically one could build on top of this to make Angular/React style custom components without the need to re-invent state management code.

Of course, I am missing many good features of React (due to my lack of understanding, as I am not a front end developer), but at least conceptually one could argue the original idea was there all along. Perhaps the real power of React lies in the excellent diff algorithm they came up with. Any thoughts?

Re: My Reaction to React

#36
Thank you for writing this article.

I'm an iOS/Backend developer looking to do some lightweight front-end programming, and whenever I look at the JS landscape I shudder.

Nearly every suggestion from JS developers is on the line "Have you tried "React/Angular/Ember/ObscureJS?". The Grunt/Gulp/Yeoman/Bower/Npm/Batman.js etc toolchain makes me question my sanity. Is it so difficult to just use Plain Old JavaScript™ and be done with it?

Sorry for the rant, I wish novice JS developers like us had a better way to get initiated in the JS land.

Re: My Reaction to React

#37
post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

This. If you are doing your own side project, building your own framework is a great way to sharpen your core software engineering skills.

If you are architecting a product meant to scale, choosing a framework with significant mindshare, great documentation, and tons of learning materials and blogs supporting it is the right way to go. Frameworks are also supported by other frameworks. React/Redux has popular tools for debugging, logging, asynchronous operations, server-side rendering. I'm sure there are similar angular ecosystem frameworks as well.

Re: My Reaction to React

#38
post #33
post #26

Earlier quoted context omitted.

React's API is fairly stable, and has been for a long time. Redux has almost become the de-facto standard for new projects, but again, it is just a library around a good idea: do all state transitions inside a pure function - get an input, return a new output, and the entire view gets re-rendered with it. You can use React's immutability helpers inside it, or or performance in large state trees, use ImmutableJS that…

You don't need to sell it to me, I see the advantages--but precisely because I understand those advantages, I actually intend to complete my next project with Cycle.js [1]. [1]: http://cycle.js.org

Awesome! A lot of smart people have been saying good things about Cycle.JS, but I unfortunately have been unable to wrap my head around it. The idea of putting stream of user-generated events front and center appeals to the puritan in me, but I find it more natural to think about the front-end beginning with the rendered view, and events and their mutation (uni-directional actions) later.

The Elm language is yet another area that gives the fear of missing out on the 'better than yesterday's abstraction'. But as long as I'm able to build great software with the tools I know and patterns my brain is comfortable manipulating, they can wait. This is the line of thinking that I mentioned in the original post about no one true way.

Re: My Reaction to React

#39
I don't know what point you're trying to make. Sure, if you don't really need any of these tools and libraries... Don't use them?

If you're gonna be building a sophisticated application, it's going to have to deal with a TON of challenges, and there's not really any way around em. Why not learn some of the more robust tooling and make life easier for yourself?

Re: My Reaction to React

#40
post #9

I went down a similar path a few years ago when starting a new project. Instead of learning a new framework I wrote my own. It took less time overall, since the logic wasn't especially hard to write, and it was easier to debug - at first. Everything changed as soon as another developer, then two, then three, started working on it with me. They were not happy about learning how to use my custom MVC framework. Perhaps…

I came here to say exactly this. I think that one thing to distinguish is: pick small yet popular libraries/frameworks that solve few and clearly defined problems and do that well.

For comparison: I think React is (currently) still in the small category, I think Angular is waaay to big.

This way you'll have tutorials, courses, books, stackexchange, educated talent, new features and bug fixes -- it all comes your way if you pick a popular-enough library.

Post reply on HN