Comment by troyvit

Comment by troyvit 8 days ago

> An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity

Is that 100ms on fiber? Cable? 5G? 4G?

Is that for the first button? Or each button? And what happens when you next need to manage dates as objects? Do you pull down dayjs or do you wrangle it yourself? What other libraries do you need to add? How's build speed? How much time to the linters take as they cascade through all that code? How are your Next.js (a pretty standard companion to react) version updates going? Keeping up with security alerts?

I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.

Agencies are going to keep building with React because they can get 90% of a project done in no time flat, and they don't have to deal with the infra challenges after they get their check. Small clients like us will continue to fall for it and slowly grind to a halt as the infrastructure pulls the team to a standstill.

anon7000 8 days ago

No, adding another button does not duplicate the entire underlying libraries used to display said button.

Reply View 4 replies

oefrha 8 days ago

Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.
And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.

Reply View | 3 replies
- troyvit 7 days ago
  
  Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.
  Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.
  I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.
  People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.
  
  Reply View | 2 replies
  
  oefrha 7 days ago
  
  No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.
  (Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
  
  Reply View | 1 reply
  
  troyvit 6 days ago
  
  > (Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)
  Honestly: thank you, I didn't know that and won't do it again.
  
  Reply View | 0 replies

yuskii 8 days ago

> I'm biased against React because I manage a team trained in classic web design who now have to manage a giant React codebase and learn its special way of doing things, and it's a slog.

What special way is that? One of the big draws of React is its minimal api surface, and the ability to write standard JS alongside of your presentational HTML.

I am also curious what "classic web design" actually means, I have a theory, but I am curious all the same

Reply View 2 replies

troyvit 7 days ago

I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.
HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.
And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.
But I can't. So it's time to learn to manage people who want to go this direction.
Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.

Reply View | 1 reply
- girvo 7 days ago
  
  > HTML such that instead of typing <h2> devs have to type something like <Heading.
  ...but they don't? Just use <h2> haha
  
  Reply View | 0 replies