Live data from Hacker News

What I wish I knew about React

bitsofco.de

201–210 of 301 posts

Re: What I wish I knew about React

#201
Big picture: React (especially with JSX) can be thought as PHP running on client side.

We can replace mentally any or on the page with . When the application state (fuzzy term but still) changes we request these content generating functions to re-execute.

The VDOM is just an implementation detail - agreement on what these someScriptFunction()'s shall return. Conceptually they may return just html and so we can use:

    function onDataModelChange(model) {
      element.html = provideHtmlRenderingOf(model); 
    }
can be used instead of reconciliation (diffing). Performance of such updates will be the same, if not better than React's, BTW.

The only problem of element.html = ... approach is that such updates will loose runtime state. For example, if you have replaced that way you will loose its current editing state - undo/redo stack, caret positioning, etc.

So VDOM and reconciliation mechanism is a palliative - to do not loose runtime states on updates. But, again, it is not a panacea. Think about based editors, their content cannot be reactive in principle.

That update-only-what-is-needed reasoning frequently used by React people to promote "speed" hypothesis is a bit misleading - it was introduced for different reasons really.

Re: What I wish I knew about React

#202

tldr; React is a view renderer. It renders views. Getting data to and from those views not included. Navigation? Not included. Persistence? Not included. Styling? Not included. Why? It's just a view renderer, that is to say, it renders templates. When the only thing your application shares with its dependencies is its view renderer, you're going to feel a lot of pain. This is one of the big reasons why I use Ember.js…

agreed. using ember has been instrumental in getting my projects up and running quickly, and then, maintaining them as they grow from mvp to enterprise level.

Re: What I wish I knew about React

#203

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

I've been considering the jump into TS, but I don't want to end up in a coffeescript situation (i.e. language is dead, but code lingers on and has to be converted back to JS at some point, rather painfully). Do you think it's worth it?

Unlike coffeescript which had a fundamentally different syntax, typescript is just modern javascript plus types.

Re: What I wish I knew about React

#204

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

I've always found the best distinction between a framework and the library lies in who-calls-who? A library you call when you're ready to use it. With React, that's calling `ReactDOM.render()` when you want to render your application. A framework you just provide code blocks and let the framework call your code, rather than your code calling the libraries/frameworks code. So with that in mind, you can use React as bo…

> If you call `ReactDOM.render` in multiple places

Nobody uses React that way. Besides, React is still very much the one calling you when you're dealing w/ lifecycle methods, useEffect/useCallback, suspense, etc.

Re: What I wish I knew about React

#205
post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

I think the number of concepts that need to be understood to be an efficient React developer has grown over the years just enough that it has become slightly frustrating to learn. It is still presented as a very simple small surface area framework but there's a lot of subtly with how many new concepts need to be understood now like hooks as an example. I think it just crossed a threshold and became less intuitive and…

The useEffect example in this article to me is ludicrous. It makes absolutely no sense just looking at it.

Re: What I wish I knew about React

#206

Earlier quoted context omitted.

We rewrote our frontend in hooks and graphql 1 year ago. Hooks are fine, but graphql is a messy time sink for our usecase.

Did you also rewrite the backend for GQL? We've had great success and satisfaction with GQL, but it’s been limited to greenfield development so far. To me, one of the bigger wins with GQL on the front-end, aside from the obvious consolidation of requests, is access to react-apollo client's caching system, which can replace the use of state stores like redux for API data in many cases. I could see it being a challenge…

I don't understand this hype about Apollo. Its trying to be some strange "semi-framework" that takes care of some of your application concerns while actively making it harder to take care of the rest.

For example, Apollo will cache api requests, but what about local application state? Their local caching library is cumbersome to use. If you wanted to update local state, you either need to write a mutation, or manually fetch data from the cache and change it. For the former, I find writing GraphQL mutations more verbose and cumbersome than Redux.

In the latter, you need to worry about fetching, changing and saving state every time you need to make a change. With Redux on the other hand, your current state is fetched and saved for you automatically and you just need to worry about describing the state change in the reducer.

I also dislike the Query and Mutation components. The Query component can be fine for simple use cases, but it still ties your API calls directly to your component. What this often means that any business logic associated with the request goes in the component as well, leading your components to become bloated and untested.

The mutation component is even worse leading to super hard to understand code - you are basically writing your API request layer using HTML markup. For me its so much simpler to just have functions that call APIs directly instead of trying to understand some strange markup hierarchy.

In short, I can see the appeal of Apollo if your app had very little frontend state and just needed to be a reflection of the server. However, as your codebase grows in complexity, the patterns that Apollo encourages you to use lead to bloated and unmaintainable code.

Re: What I wish I knew about React

#207

Earlier quoted context omitted.

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

Its reaching the point where it is becoming standardised, and therefore not interesting, and so it must pass, and a new framework will become the one to use for web development. It's axiomatic that web development must be cool and new and therefore no framework can ever become a standard.

I still write web in ColdFusion and (mostly) plain JavaScript. Seriously. I’m not cool at all.

Re: What I wish I knew about React

#208
post #83

I am not so up to date with frontend dev but what's with the hate towards React these days? It still does what it's supposed to do very well and very fast. Yeah sure if you want JSX you need transpilation but I would want that anyway if I want any of the ES6 features without losing browser compatibility. And it's also constantly evolving and getting better. Just recently I started a React project with class component…

> I am not so up to date with frontend dev but what's with the hate towards React these days? HN is rarely the place to read constructive comments about JavaScript and frontend development. Personally I've been developing web apps for 10 years (with technologies such as Spring, ASP.NET, CakePHP, Symfony, Django, jQuery, Backbone.js, Angular 1) and I quite enjoy React. I think it makes my job easier and I feel product…

> HN is rarely the place to read constructive comments about JavaScript and frontend development.

So, so true. Not even just JS though. Community can be rough on people generally.

Re: What I wish I knew about React

#209
post #113
post #30

Earlier quoted context omitted.

I personally find “the HTML is a function of its inputs, internal state, and nothing else” to be a much more predictable model for writing large web applications than, “anybody anywhere in your code can pull the rug from under you arbitrarily with jQuery”, and for that alone I prefer the React development experience. With Hooks I’m happy in that most of the “business logicky” stuff can be split out into those and my…

The SSR data fetching story really isn’t much different than the story for managing global state in React on the client. It’s true than a client-side React application could just do AJAX requests on component mounts (or in a useEffect hook) to keep that data in local React component state, and that wouldn’t easily translate to React SSR (because the server renderer can’t know when your component tree is “ready”). But…

I don't really understand why suspending server rendering to load data is still an unsolved problem for React. Ember figured this out 4 years ago with FastBoot.

Re: What I wish I knew about React

#210
post #86

React is a framework though, not a library. I don't mean to be disparaging but this is an article about how someone thought react was one thing, found it was another and then wrote a post of random tidbits about things in react you could learn from its homepage?

React's marketing (such as it is) has pushed the "it's just a library" and "it's just the V in MVC" hard. I think folks can be forgiven for thinking those notions won't entirely fail to describe the real world experience and use of React in ~100% of actual projects (and even more so now that ditching legitimately-actually-quite-portable Redux for hook-centric logic is trendy) and being a more than a little surprised and perplexed when they do.
Post reply on HN