Live data from Hacker News

My struggle to learn React

bradfrost.com

161–170 of 218 posts

Re: My struggle to learn React

#161

I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…

> web application / UI frameworks that are going to be the The Final Paradigm come

Are there any that would claim that? As far as the popular ones that have been there (which is really just JQuery and Angular, but could also encompass thins like Underscore, Knockout, etc.) go, I think most of them presented themselves as band-aids for limits in Javascript/DOM API's. I think React is that first one that gained widespread adoption that actually promoted a paradigm (view is a function of state).

That is not to say it's The Final Paradigm, but I think an important reason for both Angular and JQuery to lose adoption is because the wounds they band-aided over were cured.

Re: My struggle to learn React

#163
This is more of a criticism of modern web development, and not specific to React. A modern web developer has to install node, webpack, babel/typescript, react, redux, sass/less just to write HTML, Javascript and CSS. It's especially frustrating for newbies since ES6/JSX and React always seem to "travel together." But you can write non-ES6 and non-JSX React.

- https://reactjs.org/docs/react-without-es6.html

- https://reactjs.org/docs/react-without-jsx.html

This is what all the JSX and ES6 compile down to. It's just not as fun.

But React at its core is very simple: Same props always render same UI. Different props always render different UI.

  add(1, 2) -> 3
  add(2, 1) -> 3
  add(2, 2) -> 4
That's the core principle. And it is the drive to organise your code into declared props that naturally drive how your React code is organised.

  add({'num1': 1, 'num2': 2}) -> 3
  add({'num2': 2, 'num1': 1}) -> 3
  add({'num1': 2, 'num2': 2}) -> 4
It's a reaction to the unpredictable nature of "typical" jquery code where data and actions flow in both direction and it became difficult to pinpoint why something changed. If you clean up how you use jquery and are disciplined about it, you will eventually build something like React. There's no magic to React. The virtual DOM is not React. It's just an optimisation.

Same with Redux. When you eventually start writing large React applications, you will eventually end up re-inventing something similar to Redux.

Re: My struggle to learn React

#165

I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…

> As of now, I have still yet to see a JS framework that made any sense to me.

The basic issue with the DOM is that it makes state management a pain in the arse.

So you have written a DOM widget and you want to incorporate it in a bigger widget, so you have to have some kind of "composite" API with a widget life-cycle that pumps data and dumps custom events from/to somewhere. It's not that hard to code, but by the time you are finished coding a library that handles all that you have created you own front-end framework basically.

Web Components help a bit by it doesn't seem that Google, Mozilla or Microsoft and co are doing a very good job at promoting them, pushing them in their browsers or even education people about them. It looks like it is one of that spec browser vendors don't like for whatever reason :

https://caniuse.com/#search=web%20component

Vue.js actually retains most of the philosophy of Web Components like Polymer so I went with that instead of React,Angular and co. Front-end development is all about state management.

Re: My struggle to learn React

#166

The people who will learn React the quickest are those who have been building applications on other platforms beyond the web.

I think it is worth learning Elm first because it many ways it is much simpler. No JS "this" issues to worry about. No props vs. state. It is very opinionated. But it is also virtual dom and "component based" so the paradigm is instilled in the brain to go across and learn React. Disclosure: I learned some Haskell before Elm so I may be "immunized" against some of the struggle!

I don’t know, I think it’s better to just dive straight into what you’re trying to learn, otherwise you’re basically procrastinating.

Re: My struggle to learn React

#167

I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…

Honestly, something like React/Vue has got to be as close as it gets to "The Final Paradigm". At this point, it's been a long time since I've seen a new paradigm that does anything vastly different or more productive and simple than JSX + React/Vue lifecycle & state hooks. Most of the new UI libs that come out (Glimmer, Marko, etc) seem to be heavily influenced by React and don't offer a giant leap in how UI is done.…

It's funny to think retrospectively that something like Backbone.js absolutely did not solve view state management at all and people adopted it because it somehow looked like Rails with big models, Angular.js misunderstood the issue completely with factories everywhere instead of a single dataflow.

The new paradigm would be the browser handling all that and there is no need for frameworks anymore. We are not there yet given how poor web component support is : https://caniuse.com/#search=web%20component

Re: My struggle to learn React

#168

I've been doing web development for over 15 years, and I've seen a lot of trendy web application / UI frameworks that are going to be the The Final Paradigm come and go. That experience has taught me an important lesson about trendy framework stuff: If it doesn't make sense to a lot of people after a lot of thought, and there's a lot of rationalization required to plug that gap, it's probably not working out very wel…

Honestly, something like React/Vue has got to be as close as it gets to "The Final Paradigm". At this point, it's been a long time since I've seen a new paradigm that does anything vastly different or more productive and simple than JSX + React/Vue lifecycle & state hooks. Most of the new UI libs that come out (Glimmer, Marko, etc) seem to be heavily influenced by React and don't offer a giant leap in how UI is done.…

I don't think so, I'm thinking it's all about to change . why? WASM.

We now see languages targeting the browser, and the beginnings of front end frameworks being developed in traditionally backend languages. I think this is going to create quite a different landscape for the web world in the next 5 years. Different languages bring different approaches to problems.

Re: My struggle to learn React

#169
post #61
post #12

This is a fine article. But I just want to say, as an alternate data point, my experience has been exactly the opposite . I love React. React is the first front-end technology I have ever managed to get to stick. * ES6 is just a detail, I know. But for me, ES6 transforms Javascript from an idiosyncratic scripting language where I constantly have to look up the ordinary way to handle basic programming tasks into somet…

Some unsolicited advice from someone who has also been down a similar path. I normally suggest eschewing the javascript class model in favor of using stateless functional components.[0] I've found them simpler to understand and it cuts down on unnecessary typing. I almost never use 'this' in javascript, and instead have favored an OLOO[1] or pure functional style as it fits into a simpler mental model for how things…

+1 for testing actions / reducers.

Snapshot testing probably makes sense if you're making a design system of component building blocks or a purpose-built re-usable component. Anything more and your tests will probably end up being brittle.

For routing, I usually recommend "connected-react-router." [1] Never heard of "redux-little-router" - will have to check it out!

[1]: https://github.com/supasate/connected-react-router

Re: My struggle to learn React

#170
post #89

> 4. Getting lost in this-land. This is one of major design flaws in JavaScript; when one goes deeper into prototype land and using 'this' in closures/functions, facepalming happens all the time as the semantics is completely different to what one would expect in better designed languages like C++ and Java. So you have to workaround around these warts, making the programming akin to walking on eggshells. Especially i…

I’ll take EcmaScript over C++ any day :-)

But I started programming back in 83, before the PC industry decided that some bastardized knock off of Simula 67 was the one true programming model. In contrast, a language which traces its origins back to Smalltalk/Self with a longing to use some Lisp/Scheme techniques can’t be all bad.

Post reply on HN