641–650 of 866 posts
Modern reactive framework: - looks like your slider is only updating one value on the page, let me surgically update that for you. no sweat ;)
realistically i've worked at very few companies whose delivery is held back meaningfully by the framework something is built in. when there's friction, it's much more likely to come from poor planning, or constantly adding more functionality without stopping to reconsider architecture, or one of a thousand more organizational issues. the innovation delivered by basically anyone working in software is extremely rarely…
I wouldn't say I've worked at companies where the framework is exactly what holds back deliverability, but I have worked in plenty of environments where a complex front end is multiplying the work required to get a basic CRUD product out without a ton of benefit.
in fact, the greatest source of that kind of trouble, in my experience, is constantly changing approaches and paradigms and patterns throughout the codebase to do something "more modern" without fully committing, leading to a super stratified codebase with dozens of patterns and weird hooks and bindings to make them all get along...
With these articles I'm a little tired of them in that if your workplace can't possibly consider anything else and that's a big deal to you ... kinda feel like you've got a choice to make. Does that make sense for a given individual? Maybe. Otherwise the front end land is still very dynamic and so on, I think it's great, there are lots of options. If some boring insurance company doesn't pick the coolest new framewor…
Plus, I have no interest in front end innovation. I think HN and Craigslist are as good aw it gets.
React reactive framework: - are you moving a slider? lets re-render the whole tree every frame - oh you didn't want to re-render the whole page? shoulda used hooks ;) Modern reactive framework: - looks like your slider is only updating one value on the page, let me surgically update that for you. no sweat ;)
"Slowing innovation across the frontend ecosystem" sounds like a really good idea to me. Frontend innovation is largely vanity churn at this point, and means that any web frontend project left fallow for more than six months is effectively dead, since you need to constantly update for security reasons, and the API and the dependencies are constantly changing, you are doomed to rewrite your application forever. The on…
I agree, part of why I detest frontend and its' ecosystem is because these things seem to be always in motion and there never seems to be a solution that is just "good enough". This seems insane to me on a conceptual level because in the end it's just putting things on display on the internet which is something we've been doing for decades. And it's not like things have got better for the end user anyway seeing how so many websites written in these frontend frameworks are abysmally slow.
I wouldn't have much issue with the state of things if I was just a hobbyist making my own website for fun but I do mind when the job market constantly demands something different. I'm glad that React is the de-facto winner because this is what I need to know to get a job but I still see positions that require Angular or Vue.js and I don't even bother with sending my resume because I know I will be rejected. From my experience most companies do not care that you have worked with a different framework in the past, they expect the exact one they've listed.
Earlier quoted context omitted.
The dependency array thing is really easy if you use eslint with the react rules of hooks.
I'd say that most of the time, that's the wrong thing to do. For the vast majority of effects, you don't actually want to call it for every variable that's referenced in it. A good example is literal arrays, functions, and so on, if you have a prop that's an inline function definition, you'll be calling the effect on every render because the reference is new. You could work around this by memoing every inline functio…
This is a normal part of optimizing React components and the exact reason for the React compiler’s existence.
Earlier quoted context omitted.
Hooks are magic syntax without any doubt. All magic syntax is made up of non-magic parts, that's kinda the point. The way you know it's magic is it shatters the principle of referential identity, which tells you that a variable is itself. It pretends you can use a simpler mental model but you really cannot and must not.
Hooks aren't magic syntax. The problem with hooks has nothing to do with syntax. The problem is that the React crowd has decided to overload the meaning of a term that has had a reasonably solid interpretation (at least in comparison to the React crowd). "React Functional Components" have nothing to do with conventional functional programming. They inherently (intentionally?) violate the spirit of functional programm…
This happens because GUIs are inherently imperative constructs.
Earlier quoted context omitted.
I always thought Angular 1.x was _fine_, so long as you had incredible discipline in your team and stuck to predefined patterns. React’s main benefit wasn’t technical, it was organisational. It’s so opinionated that it’s difficult for an incompetent developer to introduce very low quality code into the project. Meanwhile in AngularJS, a developer with a clever implementation idea was a terrifying prospect for future…
React's benefit was absolutely technical. Its component model and one-way data binding was so much simpler to reason about and elegant than Angular. So much so that they ended up copying it in Aungular 1.6 and Angular 2.x. One of the biggest criticisms at the time (And perhaps still now) was that it wasn't opinionated at all. It didn't make assumptions as to how to do routing, or to fetch data, or to handle state. Th…
> Angular was an all-batteries-included MVC framework
As said back then, React is just the "V" in "MVC".
Earlier quoted context omitted.
Well, that is really embarrassing for Cloudflare... A recursion in a side-effect via dependencies is a rookie mistake, it's hard to imagine it could slip into production with a proper due process. Maybe they should stop vibe-coding and deploying things to production without any tests or review?
If after nearly a decade swarms of people are still making the exact same mistakes with how they use a specific method exposed by the library, then the problem isn't with the hundreds/thousands of people making the mistake, the design of the method is broken. This type of issue simply does not exist in Vue or Svelte even if people abuse watchers (which I've anecdotally noticed tends to happen from React devs writing…
Earlier quoted context omitted.
Enh. That button is often used for "your post gives me bad feelings" but it's supposed to be for "your post is bad for the community"
Go read pg’s comments on downvoting. HN has always been fine with using downvotes to signify disagreement.
Hmm. That sounds an awful lot like "It's true! Google it!"