Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

If not React, then what?

infrequently.org

Post reply on HN
Print view View original

321–330 of 756 posts

Re: If not React, then what?

#321

Post by emmanueloga_ »

photonthug wrote: post #76
emmanueloga_ wrote: post #58

Earlier quoted context omitted.

If you try something for a decade and it doesn't work, maybe a change in style is necessary! An article exceeding 20 pages doesn't sound like the best persuasion strategy.

I’m not a front end engineer and I read most of this, at first for sheer morbid curiosity about the drama, then I kept reading because it looked like deep knowledge and detailed exposition of a complex subject, then I kept reading because I was wondering who listens to a guy like this and why? In my experience, regardless of your skill at communication, coworkers or bosses that are actually interested in getting to d…

> coworkers or bosses that are actually interested in getting to deep knowledge or detailed analysis about anything are extremely rare

I agree! In general, people are resistant to change, period. Some are particularly wary of facts and logic (see: politics). Successfully getting points across, even when one "is right," often requires a lot of strategizing and non-technical effort.

Whole books have been written on this subject [1]. For those attempting to navigate the challenge, just remember that it's all too easy to burn out in the office while "chasing your ideals.". Doing this while keeping your sanity is an art :-).

--

1: https://pragprog.com/titles/trevan/driving-technical-change/

Re: If not React, then what?

#322

Post by 000ooo000 »

lucsky wrote: post #310
000ooo000 wrote: post #302

Earlier quoted context omitted.

>you get weird stateful functions This is one of the reasons I think hooks stink. It seems like they tried so hard to avoid using classes that they came up with an opaque, framework-only way to manage state so that they could declare "ha! Stateless functions at last!". The state's still there, it's always gonna be there, it's just now hidden behind an abstraction that has a few footguns.

Again, you can still use class components today , feel free and have fun.

Unsure what your point is. I know that; the codebase I work on professionally has both. This thread is discussing the quality of the hooks API.

Re: If not React, then what?

#323

Post by emmanueloga_ »

spankalee wrote: post #129
emmanueloga_ wrote: post #57

I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible. The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc. Imagine being able to do this without importing any 3rd party code: const content = html` Hello world! `; // New API: html Tagged…

There is a proposal for JavaScript-based HTML templates: https://github.com/WICG/webcomponents/issues/1069

Thanks for sharing, I wasn't aware of this one. I hope they succeed!

Re: If not React, then what?

#324

Post by Null-Set »

harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

A more generous way to say this is that the code is more readable, which is in fact important in a growing codebase.

Re: If not React, then what?

#325

Post by mikl »

Marazan wrote: post #260
QuiDortDine wrote: post #7

WOW this is a long article! Still waiting for the substance though... The only point I can agree with is that React is stupidly hard to learn. It feels like a tool made for aliens, though once you master it, it can be pretty efficient. Sorry to be the bearer of bad news, but the JS-free web isn't coming back. And if you're using modern JS, you might as well use React (or a similar tool). The user won't be able to tel…

React is really easy to learn. Stupidly easy. It was so easy that people strived very, very hard to make it seem complicated - and they succeeded. Back in the day every React tutorial layered in soooooo much other stuff, Redux and a million middleware layers that completely obscured what React was. The core of React though is really simple and no amount of attempts at complexification can destroy that.

Hello world might be simple, but you don’t have to build very much before you start to run into problems with the simple “props down, events up” and you start needing to learn about contexts, hooks in general and so on.

Hooks is really one of those things where you need an IDE to tell you that you’re doing it wrong, since there’s a whole bunch of footguns. It’s doing its best to solve a hard problem inside the limitations of JavaScript, but it is essentially a kludge.

Re: If not React, then what?

#326

Post by agumonkey »

harrall wrote: post #297

I've been building sites since the 2000s and I'll let you know why React or jQuery "won." It's because when you write code using these libraries, your code looks nice . I cannot say that for a LOT of libraries, especially MOST frameworks. Sorry for calling AngularJS out but look at a code sample from early Angular: https://stackoverflow.com/questions/42823436/angularjs-error... (It looks terrible.) React will be unse…

To me it goes beyond the looks. Angular terminology and semantics were always very alien. React is no angel either, but it seems influenced by older, more tested concepts (FP and such).

That said, I think client side UI/UX is about to see yet another large wave of change. Hearing chats from solidjs devs make me feel that there's a whole new and saner space to describe simple and fast programmable interactions.

Re: If not React, then what?

#327

Post by johnfn »

hasanhaja wrote: post #268
johnfn wrote: post #168

Reading over the authors primary reasons to not use React, they strike me as fundamentally misguided - mostly solving problems that most people don’t have. One reason it says that React is a poor choice is performance issues. But front end performance issues are almost never the most pressing issue to deal with. React performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds…

I urge you to read Alex's Reckoning series. > performance concerns in the real world are typically measured in, at worst, hundreds of milliseconds. I think outside of the privilege bubble where a significant percentage of the world is in, these concerns are measured in the tens of seconds. > it doesn’t create issues visible to my users What do your users look like? What kind of devices are they on? Is it mostly mobil…

> I think he does and that's a big part of this article. It's almost literally everything from the "OK, But What, Then?" section.

I did read it. I didn't want to go into depth debunking every single sentence OP wrote because I thought it would be obnoxious, but I'll write a bit more.

> The TLDR is there isn't a one-size-fits-all.

That's what I mean - the author gives no prescription. Saying there is no one-size-fits-all is not a prescription. I'll respond to a specific quote the author said, which I believe to be the crux of his suggestion:

> Teams that have grounded their product decisions appropriately can productively work through the narrow form by running truly objective bakeoffs.

Most teams do not have the privilege of being able to "ground their product decisions appropriately". Most teams - at least those in small to mid-size startups - will start out building A, route through A' and A'' and end up building B once they land on PMF. If you ran a "bakeoff" on A, you're going to be a bit upset when you end up at A' and probably run horribly technically aground when you truly find the right thing to build.

Yes, if at the point when you discover B you have the latitude to rewrite your entire codebase to fit your new criteria, then by all means, go ahead. That will definitely outperform React. I think the teams with that kind of latitude is an exceptionally small fraction of all teams, and the number of teams with the technical chops to do it correctly will be an even smaller fraction of that. The rest of us will use React, which is roughly 80% as good as the optimal solution.

Oh and, yes, if you work at a huge company who has found PMF and has the latitude to rewrite your code into whatever the optimal solution is, don't let me stop you. That is what Google and Facebook did, after all. I just don't think many of us are Google or Facebook.

Re: If not React, then what?

#328

Post by emmanueloga_ »

BeefWellington wrote: post #160
emmanueloga_ wrote: post #57

I think React is fine, especially when using it mainly for rendering, keeping async stuff out of the components as much as possible. The React API is way nicer to construct DOM trees than using Fragments, creating and appending children elements, concatenating strings to produce HTML, etc. Imagine being able to do this without importing any 3rd party code: const content = html` Hello world! `; // New API: html Tagged…

Apart from running screaming in the opposite direction from tagged templates for security reasons, I think a more suitable approach (that fits current ECMAScript naming conventions / namespacing) might just be something like: const content = document.createTemplate(`tagged string`).content You can already effectively do this, though you'll have to decide for yourself if putting the following lines of code into a top-…

All of what I'm talking about is doable through libraries today (or you can write it yourself). But making things available through DOM APIs create a new baseline where the very same tools are made available for anyone, no matter the framework (think: document.querySelector APIs).

Regarding patch, morphdom explains very well the difference between replacing and patching the DOM [1]:

> Replacing an entire DOM tree is fast but loses internal state (e.g., scroll positions, input carets, CSS transitions). Instead, we aim to transform the existing DOM tree to match the new one, minimizing changes and preserving state.

Also, there's the matter of performance. Diffing and patching as a single method call implemented natively should be a lot faster than using a bunch of JS code.

---

1: https://github.com/patrick-steele-idem/morphdom

Re: If not React, then what?

#329

Post by baobabKoodaa »

quantadev wrote: post #316
baobabKoodaa wrote: post #284

Earlier quoted context omitted.

Not a single file codebase

> Not a single file codebase. Yes it is. App.js is all the code there is. You can't count the two other files with 10 lines each. lol. Let's be honest here. And yeah for a tiny toy project like this you can get away with having zero design, zero architecture, zero object models, zero classes, and sure since everything is zero, we can throw in "Zero TypeScript" and "Zero Frameworks". Looks like some high-schooler's fi…

> App.js is all the code there is

No, it's not. Chatbot.js is 3400 LOC.

There's literally only 4 JS files in the whole repo and you couldn't be bothered to check how much code they have? Even after I told the other guy who made the same false claim "no, it's not a single file codebase"?

Jesus you people are insufferable. So obnoxiously confident while being wrong about easily verifiable facts.

> tiny toy project

Huh? 99% of web development is about rendering text and images. This project is moving your mouse inside a web browser & provides a plausible chat experience without a language model. That's more ambitious than just about any actual work project I've seen.

Re: If not React, then what?

#330

Post by quantadev »

thunky wrote: post #253
quantadev wrote: post #198

Earlier quoted context omitted.

Static sites have their place in the world, for sure. But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed. If you call this "absurd" it really shines more of a light on your own credibility than mine.

> But for large sophisticated apps where a mouse click might cause a state change that might update an unpredictable number of discreet individual visual changes throughout the entire page, that's where an SPA is needed In my experience, these apps are rare, yet SPAs are prevalent. Which is a problem. It would be nice, from a user perspective, if boring "apps" that are mainly forms and tables would quit it with SPAs…

I know what you mean. The train went off the tracks in about 1995 when JS was invented to begin with. We never had to "Mix Apps with Documents" to begin with, but that's how the industry evolved and to this day every modern stack/framework is still just tools to compensate for that "original sin" lol.
Post reply on HN