181–190 of 279 posts
I wish I didn’t say this but I just hate using React now. What was once simple is becoming more and more complex and I wish I had just stuck to a more batteries included framework like Angular/Vue/Svelte but the time has passed now. I’m just glad I don’t have to work on Frontend anymore.
Earlier quoted context omitted.
> jQuery I still see it on resumes today. > that google framework Seriously, Google stuff is infamous for being smothered by Google itself, what's your point > nobody cares anymore Literally the only non-Google example you could think of is still popular. But jQuery wasn't a graceful idea with a strong implementation, it was a wrapper to alleviate the pain of browser APIs. React is a wrapper to alleviate the pain of…
Web components might change those primatives. It is still pretty early days, but I would be surpriaed if react isn't replaced either by something built on web components, or maybe even native web components.
Web components were proposed 11 years ago. Widely available for at least six. When will it stop being "early days"?
Now all the air in browser development has been sucked out of the room by them. Instead of actually moving the web forward browsers are busy patching holes and problems created by web components because they are horrendously badly designed.
And they still have an issue list as long as the equator. Any framework in such a state in "early days" would be laughed out of the room.
Article makes a variety of already well understood points, but only briefly touches on the most interesting one (from my perspective): durability. If 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 pos…
React is over 10 years old and is backwards compatible probably all the way back to its 0.x versions.
Web Components have already deprecated and removed v0 of Custom Elements, and deprecated HTML Imports. On framework/library side: Polymer 1 wasn't compatible with Polymer 2 IIRC, and then Polymer was scrapped and discontinued in favor of lit.
React is a surprisingly safe bet for durability.
Earlier quoted context omitted.
> Suspense is also a crazy anti-pattern by literally throwing and catching errors as a means for communicating between parts of the framework. Okay I can criticize React and its weird solutions until the cows come home, but this is a pretty weird one because it’s entirely an implementation detail. No one working with Suspense ever needs to know that’s how it works unless they’re building a library to be compatible wi…
Wouldn't the debugger break on exception? So any exceptions used in "nonexceptional" situations have a potential to "pollute" the debugging experience? Admittedly, I haven't tried debugging React 18 yet, so I don't know if that actually happens in practice.
Earlier quoted context omitted.
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…
> When state changes, components passed that state in the form of props are re-rendered. 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 yo…
Earlier quoted context omitted.
> what you just described can basically become unusable Oh, so like every JS interface ever. :D
I mean, not really? My naive implementation in Solid required a few tweaks understanding the model and performs updates perceptually instantaneously on a perf sensitive input I use as a smoke test, without any of the tricks I expected to need, just its built in reactive primitives. The existing implementation performs the same computations on that data in about half a second, which feels like an eternity without spec…
>You just have to know how to use it, and when not to.
So, you have never had a JS application delivered over the web become unusable despite your attempts to only use it how and when you need to?
Okay, well, congratulations either or in order or you've not been forced to use it for something you didn't want to or have just never been building something big with the technology and made a mistake?
I mean my stuff generally doesn't become unusable, but generally is not always.
Earlier quoted context omitted.
The escape hatches were one of the first things I used to explain why I initially liked react, called them exactly that too. "They're smart enough to know they're not smart enough to build perfect abstractions, so they do a great job but leave escape hatches just in case"
This is why I felt out with Elm. It is harder to escape the hatches with it.
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.
That's like saying I should use a steam engine today because the electric motor will be superseded someday.
It's people that think electric motors are always the right solution to every problem and it's only a matter of rube Goldberging it up to shoehorn electric motors in to places that that's better without them.
It's against arrogant dogmatic rose colored glasses fanboyism being mistaken for software engineering
And this isn't straw-manning, the internet is full of these evangelists that exist as effectively marketing arms, as if they're bicycling around wearing nametags on behalf of the Church of Current Day Frameworks.
All it does is create messy piles of tangled garbage that wastes people's times and gets thrown away to be rewritten when the next flashy thing comes around. It's hot fashion for programming
It's gross and needs to stop. Seriously. Let's build the future, help fix the world's problems and quit fucking around.
This fetishism for shiny things have left us impotent executioners of meaningful change and thus we are amidst the tech stagnation
Earlier quoted context omitted.
Web components might change those primatives. It is still pretty early days, but I would be surpriaed if react isn't replaced either by something built on web components, or maybe even native web components.
> It is still pretty early days Web components were proposed 11 years ago. Widely available for at least six. When will it stop being "early days"? Now all the air in browser development has been sucked out of the room by them. Instead of actually moving the web forward browsers are busy patching holes and problems created by web components because they are horrendously badly designed. And they still have an issue li…
Custom Elements weren't available until 2018. So unless you are referring to the chrome-only experimental v0 version, I don't think you can say it has been widely available for more than 4. And there will likely be substantial improvements to it before it starts dominating web development.