Earlier quoted context omitted.
> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
I can advertise for a "React developer" and find people familiar with react rendering. I will never be able to do that with in-house render solution. This will apply to whatever replaces react as well. Unless I'm selling a render solution, I don't want to be maintaining a render solution. Maintaining glue code might suck, but writing everything from scratch limits the scale of the work that a person can accomplish. I…
Why I don't miss React: a story about using the platform
131–140 of 279 posts
Re: Why I don't miss React: a story about using the platform
#132Earlier quoted context omitted.
Never thought about that, where do you get this from? But it kinda rings true for me in life.
I heard it from Scott Adams, the creator of Dilbert. In addition to writing that comic he is a very interesting thinker. He is also a trained hypnotist.
Re: Why I don't miss React: a story about using the platform
#133> But the web platform isn't perfect, and I suspect most React developers have come across a situation where you’d love to be able to just tweak how your component is being rendered. Honestly, I haven't. The only potential caveat I can think of is when you have some non-reactive legacy code you want to embed inside a React component... but even then React's escape hatches are more than sufficient. If you're really wo…
Re: Why I don't miss React: a story about using the platform
#134Earlier quoted context omitted.
> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
That's like saying I should use a steam engine today because the electric motor will be superseded someday.
Re: Why I don't miss React: a story about using the platform
#135If all you need is a couple of basic forms and some basic interaction, you can do it all with vanilla JS but let's not kid ourselves. This will not allow you to build very rich apps without implementing a significant chunk of the frameworks you dislike so much. In fact, I would even say that if this is not a core part of your product, you are simply wasting time and resources. There is a huge amount of man-hours pour…
> There is a huge amount of man-hours poured into making these frameworks work correctly under any condition. The path is littered with the ghosts of frameworks past. Don't let the current efforts or trends convince you that we're done with this process. React will be a ghost one day.
Re: Why I don't miss React: a story about using the platform
#136If the thing you're integrating is an evolving, improving moving target, and it's coming out of a team of only a handful of people, double any visible costs associated with your application for the sucker who must build it in 2 years time to add some new feature. It is possible to build a strong and easy to communicate case for avoiding frameworks using long term maintenance costs as the basis.
jQuery was actually pretty good at this, it only had one big flag day that I can remember. In that sense, jQuery was much closer to what you get for free working directly against the platform interfaces. Deprecation cycles are much, much longer, and burden of proof much higher for new features in the browser than pretty much any third party framework.
Somewhere here on the thread there was slander directed at Closure Library / Compiler. In this context, that is so totally tone-deaf, Closure Compiler/Library projects from 2010 still build with little to no changes today (based on local experience). I can't say the same for any alternative I have used in the past decade.
Re: Why I don't miss React: a story about using the platform
#137Earlier quoted context omitted.
What's there to optimize? If you don't use state, it doesn't rerender. If you click a button to add another element for example, it does exactly that. If you have a reactive variable in your HTML and update it it rerenders that part only. What's there to optimize further?
Depending on the complexity of your computations and state, what you just described can basically become unusable. For example, an app I work on implements a spec which: - Models state as an arbitrary DAG - With arbitrarily deep dependency chains - Which may trigger dependent nodes based on only subsets of their state - Based on computations of arbitrary XPath expressions, sometimes containing non-native extensions;…
Mobx [1] is pretty good for this, it batches updates that happen, making rendering more efficient.
Also regarding rendering, react will update a component it it's state changes. It might update its children components, but if you pass them in as props, they won't be updated, as they're rendered in the parent component's context.
This allows you to create complex applications with thousands of interactive components, and have quite good performance, as minimal rendering is performed.
Re: Why I don't miss React: a story about using the platform
#138React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might a…
> Stateful components don't work so well in React. They work fine, though managing state outside of components via a state management library is common. > If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. Where do you find this recommendation? I’ve never seen anything like it, and keys are usually only used for repeating sets of elements,…
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
> keys are usually only used for repeating sets of elements
Not true at all!
Re: Why I don't miss React: a story about using the platform
#139React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React. If you want to update props in a stateful component, the recommendation is to replace the component entirely by changing its key. At the point all of the benefits of React (preservation of selection, caret position, scroll position etc.) vanish. You might a…
This is either a fundamental misunderstanding of React, or you're actually talking about a different library. > React works well for simple, non-interactive components. Complex, interactive components are going to have state. Stateful components don't work so well in React React components are designed with state in mind. When state changes, components passed that state in the form of props are re-rendered. Don't tak…
https://reactjs.org/blog/2018/06/07/you-probably-dont-need-d...
> I have never heard these spouted as the benefits of React.
You will find this if you read enough of React developers' blogs. JavaScript and DOM these days are fast enough that most pages can completely re-render the page and replace the whole DOM in one shot and you won't be able to tell the difference. The downside of doing that is that you lose focus, selection, scroll position, etc. So preserving those things is the benefit of React.
Re: Why I don't miss React: a story about using the platform
#140Earlier quoted context omitted.
I think it feels that way because it’s a bit of a paradigm shift in terms of the way we think about building user interfaces, but the reality is its just javascript running in a browser. I’ve been writing react over 10 years and used to devtools just a handful of times. They’re by no means necessary. I used to use an extension for jQuery to quickly find css selectors. Nobody was saying we weren’t using the platform t…
> "...and used to devtools just a handful of times." How do you debug?