[HN Gopher] If not React, then what?
___________________________________________________________________
If not React, then what?
Author : pier25
Score : 152 points
Date : 2024-11-30 03:35 UTC (19 hours ago)
(HTM) web link (infrequently.org)
(TXT) w3m dump (infrequently.org)
| 4ntiq wrote:
| I read through this to hopefully save all of you the clickbait
| and mid-way through nonsensical philosophical diatribe. It's a
| bit ranty and devoid of technically-caloric content. The author
| is advocating for use of plain HTML/SSR patterns and avoiding
| SPAs and complicated frameworks/libraries ala Angular/React/etc.
| It's an old thought that lines up with the "you don't need JS"
| crowd.
|
| Oh, and the author would like to kindly point out that React is
| legacy now. Because they said so. In case you didn't know.
| refulgentis wrote:
| Heartily concur. It's a classic of an essay written by one of
| those tortured souls who cannot understand why everyone so
| blithely moves past the incisive, obvious, truths they share.
|
| With a topping of how this is all just solved by "giving a toss
| about the user", followed by a cloying apology for being vulgar
|
| I'm not in web and am amenable to a good web dev hot take but
| this simply isn't worth the time, it's an array of generic
| wisdom delivered as if it's specific, written with the effort
| of someone who is proud of themselves when you disagree.
| Spivak wrote:
| I mean the graph in the article of Amazon vs Target vs
| Wayfair is pretty damning. And honestly you don't even need
| the graph, just go to their sites. Target is dog slow while
| Amazon loads instantly.
| rafaelmn wrote:
| > And honestly you don't even need the graph, just go to
| their sites. Target is dog slow while Amazon loads
| instantly.
|
| I was not able to notice any difference between them
| simonw wrote:
| Were you using a ~$2000 laptop on a broadband connection?
| rafaelmn wrote:
| Out of curiosity I checked on iPhone 14/4g and 2018 Intel
| MBP.
|
| I don't get what the point of these comments is ? If
| you're using RPI with a 2g connection you'll have a bad
| experience shopping at the site ? And somehow that's
| supposed to factor in to my tech stack decisions ?
| simonw wrote:
| Alex's position is that the average consumer is on a
| cheap Android phone, which has severe CPU weaknesses
| compared to any iPhone from the last ~five years:
| https://infrequently.org/2024/01/performance-inequality-
| gap-...
|
| Software engineers tend not to experience the web on the
| same class of device as most of their users.
| ecosystem wrote:
| But is the average Target shopper on a cheap Android
| phone accessing over non-broadband? Wayfair?
|
| It's a fair point to note devs and users might have
| different devices, but in some cases they don't and the
| decision to use React might be well-founded with that
| fact.
| jmye wrote:
| Do you not care about most of your potential customers,
| or do you only cater to high net worth people? If so,
| then sure, substandard devices and connections can be
| ignored. If you're Target, on the other hand, you
| probably shouldn't ignore them.
|
| I find it extremely odd that this was even a question on
| this site. Do you think the problem you're solving should
| impact your tech stack at all, or is your tech stack more
| important than the problem?
| refulgentis wrote:
| You're making the same mistake as the author. I get
| unnecessarily aggro too, but a plain reading of their
| comment isn't "they only cater to high net worth people"
| or they're advocating for such. Its "hey we're talking
| about 3G connections at this point, which are mostly shut
| down, and we don't cover developing markets"
|
| Note most of this is nonsensical too.
|
| His primary thing is "you don't need client side code
| because JS = (HTML + CSS) * x, where X >= 1"
|
| We can start sneering about not caring about users there,
| too, having a one time client side download of that
| magnitude can certainly be much better on the poors than
| 10 page loads with SSR.
| Spivak wrote:
| I keep hearing the "SPA is actually lightweight" argument
| but it's never materialized for me, the fastest sites are
| SSRs that are mostly static. The saving from HTML vs JSON
| just isn't that much over the wire and mobile CPUs and
| memory are a bottleneck.
|
| I have a newer iPhone and Safari is still full-refreshing
| pages constantly due to memory.
| xcrunner529 wrote:
| And it doesn't even have to be that. Just someone at the
| wrong end from a cell phone tower or in a clogged one
| from a sports event or something.
| xcrunner529 wrote:
| Yep! Made me remember my bad target experiences as well.
| Love how that's all ignored by some.
| ganksalot wrote:
| o7 thanks, people like this who do not work in contexts with
| problems that React solves yet insist React is not solving
| problems are profoundly boring.
| hu3 wrote:
| No need for personal attacks.
|
| And there's also the other side: people who insist in
| overusing React. Perhaps that's what the author refers to.
|
| I for one have see HTMX eat React for breakfast in a few of
| my clients during consulting.
| synergy20 wrote:
| Really? HTMX for me brings spaghetti code on the server
| side. Fine for small projects but not so for large ones. I
| would prefer the clear separation between frontend and
| backend beyond small scale projects.
| ganksalot wrote:
| > No need for personal attacks.
|
| i don't know about all that, but this is an incredibly
| tired diatribe.
|
| > Perhaps that's what the author refers to.
|
| they are clearly not.
| sakesun wrote:
| They are clearly not.
|
| "In short, nobody should start a new project in the 2020s
| based on React. Full stop."
| wiseowise wrote:
| > I for one have see HTMX eat React for breakfast in a few
| of my clients during consulting.
|
| What about the rest of them?
| fiddlerwoaroof wrote:
| I spent a lot of time working on react applications of one
| kind or another and I think most businesses don't have
| "problems that React solves" for their frontends. Somewhere
| that's actually an application might, but most line of
| business applications would be better as something like Rails
| views rather than React
| ganksalot wrote:
| > I think most businesses don't have "problems that React
| solves" for their frontends.
|
| that is neither here nor there. you are replying to an
| article whose thrust is that react ought never be used.
|
| > Somewhere that's actually an application might
|
| might, lol? wait are you the author?
|
| > most line of business applications would be better as
| something like Rails views rather than React
|
| why?
| fiddlerwoaroof wrote:
| Because, for most business applications I've worked on,
| React just complicates the frontend code compared to
| serving up simple HTML views and for no real benefit
| aside from "using React"
| xcrunner529 wrote:
| You can read it that way if you ignore the rest of the article,
| I guess. They simply are saying many (most?) sites do not need
| to be SPAs and the baggage that entails with load times and
| latency. Follow a process to determine what is really needed
| based on objective requirements and then use objective measures
| to ensure it does not degrade the experience.
|
| In most cases later frameworks are slow and bulky. I certainly
| hate using sites like X or Target on mobile. Random delayed
| loading of things, loss of scrolling position when going back,
| things just not loading the first time it delayed reactions. It
| sucks.
| wiseowise wrote:
| > Follow a process to determine what is really needed based
| on objective requirements and then use objective measures to
| ensure it does not degrade the experience.
|
| This is how you end up with an amalgam of legacy crap that no
| one wants to touch. I can't read guarantee you that outside
| of big tech and a couple of unicorns started by experienced
| devs this will NEVER work reliably.
| x0x0 wrote:
| Nah, the rest of the article is not insightful either.
|
| eg React Native is dismissed in 5 sentences, with no real
| solution at all given to the basic problem of wanting to have
| a website and mobile apps without writing your app 3 times.
| Let alone a website + mobile apps + windows + mac clients.
| The suggested solutions do not address this need -- eg
| there's some Apache crap that no one I've heard of uses (it's
| renamed Adobe Phonegap crap that Adobe bailed on and tossed
| over to Apache); some random link to a 5 year old google i/o
| presentation; etc.
|
| As far as I know, there's basically 3 toolkits that offer
| this: React + derivates; Rails with Hotwire; and Flutter,
| which means trusting Google (fools only), and which has
| recently deprioritized desktop... so that's a rock solid
| foundation to pour millions of dollars of eng time into. And
| I guess Xamarin, if anyone is using that.
| xcrunner529 wrote:
| I think sadly to that point there's no solution given
| because there isn't one. And the ones that promise it (RN)
| still has you doing tons of platform specific code and in
| some cases supporting even more platforms than just going
| native.
| x0x0 wrote:
| I've been at orgs that wrote 3x apps and at orgs that
| shipped via RN. RN was a significantly superior choice
| ime. While yes, it wasn't 100% write once, it was pretty
| good and also avoided some of the ugly single-platform-
| only bugs I experienced at choice one, eg in core data
| libs (subtly different validations on data), that made
| the write 3 apps strategy be more like 4x work.
|
| As for the article, honesty probably would have just had
| the author write something like: "RN: an unfortunate but
| maybe your best choice in these circumstances" instead of
| pretending there's serious alternatives eg the Apache
| garbage dump.
| msoad wrote:
| React works because I can hire engineers that can be productive
| quickly. A lot of tech conversations leave the talent pool
| aside as if it's easy to find good engineers in all of the
| options you might have.
|
| The ecosystem is another aspect. You have so many great options
| for off the shelf components and libraries with React that you
| might not have with other frameworks.
|
| Before anyone mentions Custom Elements and Web Components, I
| must say I tried it. Gave it a lot of effort to be a solution
| but it is not!
| simonw wrote:
| "React works because I can hire engineers that can be
| productive quickly. A lot of tech conversations leave the
| talent pool aside as if it's easy to find good engineers in
| all of the options you might have."
|
| That's covered in this section:
| https://infrequently.org/2024/11/if-not-react-then-
| what/#%22...
|
| "The ecosystem is another aspect. You have so many great
| options for off the shelf components and libraries with React
| that you might not have with other frameworks."
|
| That's covered here: https://infrequently.org/2024/11/if-not-
| react-then-what/#%22...
| sakesun wrote:
| I think people prefer ecosystem with many resourceful
| components
|
| https://github.com/brillout/awesome-react-components
|
| This point is not directly covered in the article.
| adzm wrote:
| React is not even a framework, really. It is a great starting
| point for simpler sites. Honestly still one of the best solutions
| out there.
| klysm wrote:
| Completely agree. People regularly conflate react core
| libraries with stuff like next
| Sankozi wrote:
| How do you define a framework if React is not one?
|
| It is one of more clear examples of a framework:
|
| - calls your code
|
| - heavily affects how the code is written
|
| - requires significant build configuration (could even be
| argued it is something more than a framework, but definitely
| not a library)
| gerardnico wrote:
| A framework is declarative. You declare what you want.
| Generally in a configuration file and you get an app.
|
| A library does not impose any configuration. I don't see any
| required configuration with React. You can use it wherever
| you want in your code as an addition.
|
| My piece on that:
| https://datacadamia.com/code/design/library_vs_framework
| thraxil wrote:
| Genuinely curious if you could point to some examples of
| actual "frameworks" by your definition then. Because from
| your description, Rails, Django, Laravel, Phoenix, Vue.js,
| and basically every other "framework" I've encountered
| aren't actually frameworks.
| dimgl wrote:
| > Frameworkism isn't delivering.
|
| It isn't? I find React to be great to work with.
| xcrunner529 wrote:
| Yes, you the developer. I think that's his point. The
| performance if react sites is another thing and that's what the
| user cares about. It also doesn't work on mobile. React native
| was worshipped and now is thrown out.
| alex_smart wrote:
| Is it even working for the developer though? Last I checked
| the server-side rendering performance for react based
| frameworks was somewhere like 200 pages per second? Is that
| something to be proud of as a developer?
| robertoandred wrote:
| React is absolutely performant. A developer who makes a slow
| React site would make a slow site with something else.
| xcrunner529 wrote:
| Tell that to all the former PHP developers. Where are these
| performant React sites? The largest and best tech companies
| out there certainly can't do it.
| robertoandred wrote:
| The same former PHP developers responsible for all those
| slow WordPress sites?
| xcrunner529 wrote:
| The ones who made react.
| TiredOfLife wrote:
| https://next-faster.vercel.app/
| dimgl wrote:
| Uh... I'm pretty sure Compass.com is running on
| Next.js...
| cosmotic wrote:
| They're a wide chasm between what one _can_ make and what
| is _led_ to making. React _can_ lead to fast, responsive
| websites, though you 'd be fighting against a current
| pulling you out to a bloated, buggy mess. There's a unique
| stench that comes from many react sites where everything is
| a skeleton screen, everything loads slowly, history
| rewriting is busted, there's no hotlinking, and scrolling
| is glitchy. Peek under the hood, it's almost always react.
| Facebook.com quality is the outlier, not the likely
| outcome.
| crvst wrote:
| React is far from performant for SSR, and it simply can't
| be, as it wasn't designed with backend needs in mind. The
| fact that it works at all is more of a happy accident or
| side effect. Current approaches are more like workarounds
| than proper solutions for making it function effectively on
| servers.
|
| Most importantly, it's also not particularly performant on
| the client side in real-world scenarios.
|
| For evidence, here's a guy testing major websites using his
| awesome react-scan tool:
| https://x.com/aidenybai/status/1861442057598062653
| pier25 wrote:
| If React is so great how come Amazon isn't using it in their
| store?
|
| I think last year an Amazon frontend engineer wrote some tweets
| explaining they tried React and it was too slow. So they keep
| using Java for SSR and sprinkle vanilla JS. They were still
| using jQuery until a couple of years ago and probably still are
| in some parts of their site.
| goodoldneon wrote:
| Do not base your company's tech decisions on FAANG companies
| unless your company is a FAANG company. Your challenges are
| likely very different from theirs
| pier25 wrote:
| You're missing the point of my comment.
|
| Someone is contesting that "frameworkism isn't delivering"
| when we have objective data to prove that it is in fact not
| delivering.
|
| The Amazon store is just a good example because there's a
| lot of data about it, not because it's FAANG.
| t-writescode wrote:
| What I read from what you said is "Chevy trucks are good?
| Oh yeah, if trucks are good, why does the post office use
| non-Chevy, non-truck, fleet cars?"
|
| Please help me understand where I misunderstand
| root_axis wrote:
| You just picked Amazon arbitrarily because it supports
| your argument, but there are many more counter examples
| where react _is_ used, so what 's your point?
| youngtaff wrote:
| Everyone using React is basing their work on Facebook's
| challenge!
| scotty79 wrote:
| Because Amazon Store is and aleays was an armpit of
| webdesign? It's the worst designed e-commerce site and
| decades of tinkering only brought it half way towards basic
| level of decency that was obvious to a beginner web developer
| making their own first e-commerce site from scratch in PHP 20
| years ago?
| FridgeSeal wrote:
| You're blurring architecture with UI.
|
| The Amazon site is pretty ugly, yes, but it's functional
| and fast.
| goobert wrote:
| React is in use in many heavily used frontends at Amazon,
| maybe not the retail site
|
| But there's no inherent reason React couldn't be used for a
| page that basically shows pictures of products with a
| description next to them, the bottlenecks will have nothing
| to do with the frontend in a well engineered system for that
| type of site
| cyberax wrote:
| My constant problem with React-based tools is that they
| don't support deep links properly. You want to right-click
| on a product description to open it in a different tab to
| check later, and you can't.
|
| Even freaking Google (who really should know better)
| suffers from that. Amazon's retail frontend uses plain
| HTML, so it works fine.
| root_axis wrote:
| I'm not sure how much experience you have with react, but
| it doesn't need to "support" links, they function exactly
| the same as with vanilla js, there's nothing about react
| that prevents their use. Using JavaScript for links is
| entirely a developer decision.
| cyberax wrote:
| I'm familiar with React. And no, links in React often
| don't work without extra attention.
|
| It's way too easy to put some state information into the
| context and then have your pages depend on it. For
| example, you have a page with a filter that is
| implemented via a simple state, and then a list of
| widgets that pass the filter. The widgets have a click
| handler that opens the widget details.
|
| Now you right click on it. If you're lucky, it opens the
| widget details in a separate tab. However, the filter
| information is lost.
| troupo wrote:
| > I'm familiar with React. And no, links in React often
| don't work without extra attention.
|
| ^ These two statements are at odds with each other.
|
| React will return a pure browser link that behaves
| exactly as a browser link: function
| Comp() { return <a href="some-link">text</a>; }
|
| > The widgets have a click handler that opens the widget
| details. > > Now you right click on it. If you're lucky,
| it opens the widget details in a separate tab. However,
| the filter information is lost.
|
| So, the problem isn't React. The problem is people
| overriding default browser behaviour for their widgets.
| It was a problem before React, and it will be a problem
| long after React.
|
| For example, here's Google's premier site about web
| technologies: https://web.dev/articles Check out the
| pagination links at the bottom. There's no React on the
| page
| FridgeSeal wrote:
| Sure is odd that a good number of react-and-friends
| websites can't manage to support it all then.
|
| Just like how routing and history is "solved" but I
| encounter websites every other day that completely break
| my browser history.
| QuiDortDine wrote:
| 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 tell the
| difference.
| thepasswordis wrote:
| What do you find hard to learn about react? I think a lot of
| tutorials are really bad, might be the problem.
| 000ooo000 wrote:
| Not GP. Started using React at work around 2017. The hooks
| API is just awful. Those complaints are extremely well-
| trodden ground at this point so I won't rehash. I'm using
| Lit.js for personal stuff instead these days. Shadow DOM
| isn't perfect but web components with Lit has been pretty
| low-surprise so far, which I can't say for Hooks React.
| lucsky wrote:
| > The hooks API is just awful
|
| Hard disagree. Hooks are 100% what is best about React
| these days and custom hooks make organizing or
| encapsulating and sharing behaviors between components a
| total breeze.
| halflife wrote:
| This is something that I just don't get, in the olden
| days, when you wanted to encapsulate logic and state and
| share it between instances you would just use a singleton
| service. But now when classes are "bad" for some reason
| (when the whole point of a class is encapsulation of
| state and logic) you get weird stateful functions that
| makes everything hard to track with complicated API.
| 000ooo000 wrote:
| >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.
| lucsky wrote:
| 1. Nobody said that classes are bad. Yes you can
| encapsulate logic and state in a singleton, that's not
| the issue, the issue is how you then "apply" it. There
| was a fantastic diagram that (most likely) Dan Abramov
| posted on Twitter a while ago (before it became the
| olympic pool of diarrhea that it is today) that was
| demonstrating the superiority of hooks in a beautiful and
| obvious way but I cannot find it anymore... :/
|
| 2. Sorry but if you keep using "weird", "hard" and
| "complicated" adjectives to define something that is
| quite honestly not so hard to grasp you make it hard to
| not go with "skill issues".
| baobabKoodaa wrote:
| Not parent, but I'll answer anyway: React was much much
| easier to learn back when Class Components were the thing.
| Nowadays there is layers upon layers of magic like Functional
| Components with State from Hooks.
| lucsky wrote:
| > Nowadays there is layers upon layers of magic like
| Functional Components with State from Hooks.
|
| 1. you can still write class based components if you want,
| but if you are in a team everyone will hate you for that
| because... 2. the preferred and _vastly_ more flexible and
| powerful way is functional components. That 's it, there
| isn't any other way or any other mystical layer of magic.
|
| What everybody in this umpteenth omfg-react-is-satan thread
| is that implementing complex things with _simple_ things is
| a fucking pipe dream. Fucking deal with it.
| baobabKoodaa wrote:
| I didn't talk about any pipe dream, I named a very
| specific way of how those things were done before - in
| React! - and how it used to be simple and now it's not.
|
| "Fucking deal with it?" What are you, a cultist? I
| answered a question here, fuck off.
| pier25 wrote:
| If you need all this complexity to implement a setTimeout or
| setInterval in a React component I don't think you can really
| blame the tutorials.
|
| https://overreacted.io/making-setinterval-declarative-
| with-r...
| Gualdrapo wrote:
| > Sorry to be the bearer of bad news, but the JS-free web isn't
| coming back.
|
| It has never went anywhere? All it takes is a user brave enough
| to disable it or to use a web browser that doesn't use it or
| has issues with it. But for some reason many web devs actively
| ignore that.
| dottjt wrote:
| As someone who's been doing React since the beginning, I would
| agree that it's hard starting out.
|
| However, I think any new paradigm is difficult starting out.
| Recently I've been learning OO for work and I've been finding
| it stupidly hard and entirely unintuitive.
| sshine wrote:
| I've found Vue easier to learn because it bundles things and
| lets you learn visual components before fully exploring the
| reactive model. So while the modularity of React is
| preferable to a seasoned developer, it does no good to a
| newcomer.
| QuiDortDine wrote:
| I have no doubt React is easy if you've been there from the
| beginning. But if you learned it last year like me, you got
| to find out the hard way that things are done slightly
| differently in each version, introducing breaking changes
| which invalidate the vast majority of the documentation you
| can find (which you need because the official docs is
| absolute crap for beginners, as it assumes you already know
| React's paradigms).
| em-bee wrote:
| what do you mean by learning OO here? javascript is OO too,
| so you have already been doing OO, as far as i understand it
| and what you are learning is something different. and now i
| am curious what that is.
| crvst wrote:
| Cannot agree more! Mastering React is ridiculously hard for
| what it is. There are so many "buts," "it depends," and subtle
| differences to navigate, like useEffect vs. useLayoutEffect.
| But don't forget useEffect is an evil in the first place and so
| on, and so on.
|
| It feels like a clever proof of concept with a leaky
| abstraction at its core, one that no amount of effort can truly
| fix, no matter how much they throw at it. They're even building
| their own compiler. A compiler. For something that's supposed
| to represent the V in MVC.
|
| As a SPA framework, it's questionable. But using React to build
| server-side apps? That's beyond absurd for me, it's like
| Electron for the backend, only worse. And yet, the industry
| loves to pretend otherwise, so here we are.
| lowbloodsugar wrote:
| React is a guided missile foot gun. You _can_ figure out how
| to have it hit something else, but even when you aren't
| pointing it at your foot, it's probably going to hit your
| foot. You can have that feeling of wonder as the rocket sails
| off into the distance, and then just as you get customers, it
| comes back over the horizon and hits your foot. Experienced
| physicists and rocket scientists can override the guidance
| mechanism and have a much better chance of not hitting a
| foot, but who has time for that. Most people just like that
| it has a big red button labeled "Shoot" that's easy to press.
| scotty79 wrote:
| You shouldn't write a single useEffect in the first year or
| two of your career in React.
|
| Why people are so keen on stabbing themselves just because
| there's one or two weird shaped forks in the kitchen drawer.
| Why do suddenly everyone tries to use it for spreading butter
| or peeling eggs?
|
| Just understand what unidirectional data flow is and you are
| golden. You know the entirety of React you should be using
| for your first year of full-time job.
| crvst wrote:
| That's true. Just to note, I never claimed otherwise. See,
| useEffect is an evil remark. This is more based on my
| experience working with an average React codebase.
|
| As for your question, "Why does everyone suddenly try to
| use it for spreading butter or peeling eggs?"
|
| I guess part of the reason is that many people rely on
| older tutorials and patterns where the usage of useEffect
| was much more tolerated or even encouraged as a catch-all
| solution. There's still a lot of inertia from the old
| componentDidThis/componentDidThat paradigm, with useEffect
| being its direct replacement.
|
| I feel it is only a recent tendency to finally abandon the
| overuse of effect hooks.
|
| Just open an average Stack Overflow React question, and
| you'll see how many useEffects are crammed in there.
| Cotterzz wrote:
| Between modern frameworks and that MS born monstrosity
| Typescript, I thought this was the JS-free web. I would love to
| see the back of it. Web Dev seems to be ignoring the last 10-15
| years of new native browser technologies and getting really
| stagnant with proprietary bloat as a result. It's a really good
| time to start from scratch and see what we can do with
| WebGL/WebGPU/Shaders, WASM(C, C++, Rust Etc) and Web Audio, as
| well as the new features of Vanilla JS
| Marazan wrote:
| 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.
| valenterry wrote:
| > Frameworkism isn't delivering.
|
| Correct. The reason is not the frameworks but the languages. What
| is needed is a much more high-level and feature-powerful
| language.
|
| Just look at react. Passing down dependencies/values is a pain.
| So what did react do? It introduced contexts. Similar, other
| react addons try to solve this problem. But they all sacrifice
| type-safety in the process.
|
| They simply cannot solve this problem; only a better language
| can. Typescript maybe could, but they restrict themselves to not
| generate code (or at least very limited, I think for enums they
| do it).
|
| Without a change here, nothing can ever improve.
| klysm wrote:
| This is straight up not true. React state management is very
| flexible and requires you to think about what your problem is
| and the nature of state.
|
| There is absolutely nothing preventing you from keeping those
| safety - I'm not sure what you mean by that.
|
| The typescript type system is very advanced, maybe even too
| advanced! I disagree that more sophisticated languages are
| required.
| valenterry wrote:
| See what Peter Kelly wrote. For example.
| peterkelly wrote:
| The React team should have done their own language, rather than
| making it a framework/library. Then they could ensure the
| absence of side effects in rendering code, and had a better way
| of detecting updates. The knowledge about how to do this was
| already out there for many years before they started:
| https://en.wikipedia.org/wiki/Functional_reactive_programmin...
| CityOfThrowaway wrote:
| Yes, but if they did their own language it would have almost
| certainly died in obscurity.
|
| React won because it solved a real pain point for a group of
| people, using the techniques they were already using... but
| better!
|
| Having built large apps in angular, handlebars, and jquery...
| it was (and still is) a godsend for building highly
| interactive, stateful web applications.
|
| I am deeply skeptical of some of the stuff that people are
| doing now wrt. putting backend logic into React components,
| but the fundamentals of React are still very reasonable to
| me.
| valenterry wrote:
| That's exactly my point.
| reconvene1290 wrote:
| Isn't that ReScript?
|
| https://rescript-lang.org/
| andrewstuart wrote:
| Don't use state, except within a component.
|
| I build all my react this way.
|
| No prop drilling, no Redux, no context, no mobx no state.
|
| If you need to communicate between components then send a
| document event.
|
| Your react application will be dramatically more simple without
| state.
| Cotterzz wrote:
| This new language. Do you mean something that compiles down to
| JS like Typescript, Coffescript & Dart? Or a language that
| compiles to WASM like C, C++ or Rust?
| Aeolun wrote:
| The only part of this whole thing I agree with is that you
| shouldn't start a new project in React. Switch to SolidJS, and
| gain all the benefits (aside from the huge ecosystem) but with a
| speed to match plain HTML/JS.
| fastball wrote:
| > aside from the huge ecosystem
| croes wrote:
| Sometimes less is more
| quantadev wrote:
| The people who don't think React (or Vue) is important are the
| same ones who have never worked on a large project with lots of
| screen updates and state changes that absolutely cannot be
| avoided. React is still #1 in popularity, and the most crucial
| tool for almost any web developer (aside from using TypeScript,
| instead of plain JS which is also critical for large projects)
|
| React is reported to be used by 39.5% of developers worldwide,
| while Vue.js is at 15.4%. The number of "apps" using just
| HTML+CSS is precisely zero, because those aren't "apps" they're
| documents.
| xcrunner529 wrote:
| Ha and jquery was pretty high too. How is that an argument?
| quantadev wrote:
| I'll happily ditch React once something better emerges. I've
| been doing web development since 1998, so I'm used to change.
| goosejuice wrote:
| Generalizing much? React is as popular as it is because of
| inertia.
|
| React holds an important space but its hardly the only tool
| that can succeed in a "large project with lots of screen
| updates and state changes". That's ridiculous.
| quantadev wrote:
| The reason I said "(or Vue)" was specifically to say that
| there are other leading frameworks. I didn't say "or Angluar"
| because in my opinion it's a race between React and Vue at
| this point. But if you think there's a third contender, let
| me know. I'm always looking to learn.
|
| My main point was to compare "frameworks" v.s. "no
| frameworks", rather than to say that React is best, but if
| you want my opinion then yes I do say React is indeed the
| best, and I admit it's an opinion not a fact. lol.
| cyann wrote:
| Angluar -> I'm using this from now on
| quantadev wrote:
| In case I was unclear, I consider Angular dead and
| obsolete.
| cyann wrote:
| Same, anGLuar sounds, for a french speaker, like
| https://en.wiktionary.org/wiki/engluer
|
| 1. to birdlime
|
| 2. (reflexive) to get bogged down
| quantadev wrote:
| In case I was unclear, I consider French dead and
| obsolete.
| riku_iki wrote:
| > In case I was unclear, I consider Angular dead and
| obsolete.
|
| maybe you would expand on this? I have no intention to
| challenge you, just genuinely curios if and why I should
| consider vue over agnular for new project (I use angular
| already).
| quantadev wrote:
| Maybe Angular is still used a lot, in legacy projects. I
| just mean for starting a new project, imo most people
| will choose React or Vue in 2024, right? I never used
| Angular myself, but have used both React and Vue a lot.
| riku_iki wrote:
| I don't have strong insights about current agnular
| popularity. I think at least teams/companies which built
| strong expertise in angular will continue using it for
| new projects unless there is some big reason not to.
|
| SO trends show that angular is more popular, while vue is
| loosing share (not necessary absolute number): https://tr
| ends.stackoverflow.co/?tags=angular,vue.js,reactjs
| quantadev wrote:
| Thanks for sharing that graph. It does show React as the
| leader, the the others in distant 2nd/3rd place.
|
| However I think the "drop off" in the chart for React is
| misleading/incorrect, and likely indicates just a slowing
| down of the economy and/or people moving to LLMs for
| their searches and abandoning StackOverflow completely,
| as I have.
|
| For the past year I haven't yet found a question that an
| LLM couldn't answer better than S.O. could, although
| ironically most of the LLM learning did come from S.O.
|
| Anyway, yeah shops will stick to their legacy code
| forever unless something forces change, because retooling
| is super expensive in money and time, not to mention
| replacing all your developers with different ones!
| halflife wrote:
| If you've never used it don't declare it dead. Angular is
| updated regularly every 6 months. While react is busy
| thinking how to create more SSR apis, the angular team
| keeps improving developer experience.
|
| IMO right now it's easier to start an angular project
| with much less foot guns than react.
| mollerhoj wrote:
| Have you ever worked on a project that used Rails, Laravel,
| Django or Spring? Without being a SPA? For many (most)
| websites, I find that these are far superior to client side
| heavy SPAs with json apis (react, vue etc).
| quantadev wrote:
| Most of the apps I've worked on were very business
| oriented, and about people getting work done, rather than
| "website" type stuff that's mostly static. So for
| example, being able to refresh a part of the screen with
| new information from the server, is critical. Doing page
| reloads would destroy the experience. I have 35yrs exp so
| yes I've used most of what you mentioned.
| peterkelly wrote:
| WordPress relies on server-generated HTML and its admin
| interface is a fairly complex "app", especially once you factor
| in the plugin ecosystem. According to [1], it's used on 43.7%
| of all public websites.
|
| [1] https://w3techs.com/technologies/details/cm-wordpress
| quantadev wrote:
| If every user input causes a page refresh, that's not an
| "app" that's a "website". If you don't have any executable
| code (i.e. Javascript), but just form submits, yeah I agree
| that's what most of the web is, and as you pointed out most
| of the web is websites not web apps.
| simonw wrote:
| Have you explored cross-document view transitions? Would
| you classify something that uses those as an app or a site?
|
| https://developer.chrome.com/docs/web-platform/view-
| transiti...
| threatofrain wrote:
| That's actually rather new so we shall see how frontend
| practice reacts. I've only seen a few instances of it out
| in the wild so far.
| quantadev wrote:
| I'm not saying my own definition of "app" is the only
| correct definition, but in my opinion only if I do a
| click and something on the SAME page changes, then it's
| an app. Transitioning to different pages isn't an app,
| imo.
| simonw wrote:
| With this browser feature a navigation to a new page can
| look like only part of the page changes - without needing
| any JavaScript.
| quantadev wrote:
| > can look like
|
| Yeah, but it ain't. lol.
| thunky wrote:
| It's easy for developers to forget who the "app" is
| actually for.
|
| Users don't care how it was implemented or how nice the
| code looks, they just want it to work.
| quantadev wrote:
| Right. That's precisely why full page reloads/updates
| every time some action is done (mouse click for example)
| would be completely unacceptable for most apps I've
| worked on. I've worked mostly on apps not websites.
| BeefWellington wrote:
| The overwhelming majority of default HTML actions (no JS)
| that happen from a mouse click do not trigger a page
| load. You're trying to make it sound like selecting an
| item from a dropdown or selecting a textbox to enter text
| will cause a complete page load every time unless you use
| an SPA framework and that's just literally completely
| untrue.
|
| By your measure though, it sounds as though you'd be fine
| if these page loads in the javascriptless world were done
| in iframes, since then only some portion of the site is
| being reloaded?
|
| I'm using that to illustrate the argument is absurd and
| the basis on which it is made seems also absurd.
|
| SPAs are heavy and frequently written poorly, often
| eschewing the principles of loading only the bare minimum
| for a kitchen-sink approach. If you view the web as
| having only those two options to accomplish "real work"
| then yeah, you're gonna thing that SPAs are the only way.
| It's not reality though.
| quantadev wrote:
| 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.
| thunky wrote:
| > 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 already.
| hysan wrote:
| It's been a while since I worked with WordPress, but isn't
| their Gutenberg editor (which is the heart of their CMS)
| built on React? So while React may not be used on the user
| facing side, it is still powering the content side of
| WordPress and in a way, powering all of those sites.
| thesuavefactor wrote:
| You can't be more wrong. You're saying that only logic
| performed on the client side can be considered an application?
| State can be stored in the server. Screen changes can be done
| by loading html, it doesn't need a framework. React is far from
| crucial for web development, but people haven't learned
| anything else the last decade. Most front end developers these
| days don't even know what a template engine is, and some don't
| even know how to create a website without a backend rest api
| that spews json data.
| quantadev wrote:
| I wasn't comparing SSR to non-SSR (Server Side Rendering). As
| long as you can refresh portions of a webpage (or states of
| GUI elements), after a user action (button click or
| whatever), that's fine.
|
| However the reason my Dialog Boxes open in a millisecond, and
| close in a millisecond too, is because I choose to render
| them locally. I'm not against SSR tho, as a viable concept.
| That's a different complex discussion where there are trade-
| offs to consider.
| baobabKoodaa wrote:
| > React is reported to be used by 39.5% of developers
| worldwide, while Vue.js is at 15.4%. The number of "apps" using
| just HTML+CSS is precisely zero, because those aren't "apps"
| they're documents.
|
| The options you present are: "either use a JS framework or
| don't use JavaScript at all". That's a false dichotomy. I've
| built plenty of interactive apps with JavaScript without using
| frameworks.
| dariusj18 wrote:
| > I've built plenty of interactive apps with JavaScript
| without using frameworks
|
| And once you reach sufficient project complexity, you will
| end up with just another homegrown framework, with all the
| lessons learned by mature frameworks, left to be fixed over
| the next 5 years.
| baobabKoodaa wrote:
| Oh yeah? And when will that happen? Because people have
| been throwing this argument at me since at least 2014. I
| still haven't slipped on a banana peel and accidentally
| fallen on a homegrown framework. You don't just create a
| framework by accident.
| dariusj18 wrote:
| I don't have any context, but I do have trouble imagining
| that any of your projects have scale/complexity above
| brochure-ware if you haven't run into this.
| baobabKoodaa wrote:
| If you have trouble imagining, here's one such project:
| https://github.com/baobabKoodaa/ouija
| quantadev wrote:
| Even if you know of massive projects in JS, the problem
| isn't that they cannot exist, it's that maintaining them
| takes 100x the manpower it would in TypeScript.
| philipwhiuk wrote:
| Jesus Christ, a 1300 line single file codebase.
| baobabKoodaa wrote:
| Not a single file codebase
| floydnoel wrote:
| I have a lot of "framework free" single-developer
| projects as well (such as https://bongo.to ), but that
| isn't really what I think we are talking about here.
| Single developer projects can do whatever they want, it
| isn't a problem. The problem comes when you have to work
| with distributed teams, juniors, etc. One way or another
| a large team still has to come to agreements about how to
| do things, and without an external reference it will have
| to be made up in an ad-hoc manner instead. This often
| leads to issues, many of us have noticed.
| quantadev wrote:
| I absoluetly agree with your sentiment, and furthermore
| in projects as large and mature as mine, with 500K LOC
| (about maybe 30% in TypeScript) lots of times I simply
| cannot remember enough about my code to effectively
| refactor it from memory without type safety (to check me)
| and IDE refactoring to DO the refactoring.
|
| I mean if I need to change a variable name in a class or
| something, unless it's a perfectly unique name (easily
| searchable), it would take me hours to do in JS what I
| can do in 4 seconds with TypeScript.
| baobabKoodaa wrote:
| The goalposts just keep moving...
|
| The claim upthread was that you couldn't make a web app
| at all without a framework ("or it would just be a
| document"). I said yes you can and the goalposts shifted
| to: sure, but only "brochure-ware" (referring to simple
| unambitious projects). I show an ambitious interactive
| project made without a framework and now the goalposts
| are moving to: sure, but large distributed teams couldn't
| work like this? You know, this solo project is more
| ambitious than 99% of the projects I work on at my actual
| work. You know, projects that have 10, 40, or 100 devs
| working on it.
| quantadev wrote:
| For any large project you need type-safe languages. 99% of
| experience developers (10+ years of experience) will agree
| with this opinion.
|
| Sure you can develop very large projects in JS, as long as
| you don't mind being 1% as efficient, and having 100x more
| bugs. In JS, refactoring a huge project is the biggest
| nightmare in the world and really no human is capable of
| doing a great job of it in a reasonable time, even if they
| have a high IQ and decades of experience.
| baobabKoodaa wrote:
| I don't share your opinion but I'm too tired to go into
| another JS vs TS debate
| cannibalXxx wrote:
| I still think you can build good tools using just html, css and
| pure js if you have the right knowledge. For example, this social
| network was built without any frameworks and has the performance
| it has https://chat-to.dev
| wiseowise wrote:
| > It's the rewarding side of real engineering, trying out new
| materials under well-understood constraints to improve user
| outcomes.
|
| Good thing we're mostly keeping the attitude to hobby projects.
|
| Can't imagine hundreds of artisans(tm) bikeshedding over what the
| hell this even means.
|
| And I can't read with a straight face an article talking about
| complexity of React while suggesting Vue (sic!) as an
| alternative. Lol!
| em-bee wrote:
| what is wrong with vuejs?
| wiseowise wrote:
| Nothing is wrong with Vue.js, but saying that it is less
| complex than React is just false.
| em-bee wrote:
| are you talking about the internal or about the websites
| built with them? i have used neither, but what i gather
| from many discussions and articles is that vuejs makes for
| less complex websites.
| simonw wrote:
| A fun thing about reading Alex is that you can tell he's had the
| same arguments over and over again for a decade now and he's
| frustrated with having to keep on making the same points and
| getting the exact same responses.
|
| Most of the people commenting on this piece won't have read this
| whole article (it's long, and internet attention spans are
| short). As a result, you'll find plenty of the comments here were
| exactly predicted by his writing.
|
| I see him as something of a Cassandra at this point, doomed to
| see the truth about web performance based on many years of
| research... and then to have nobody believe him.
| https://en.wikipedia.org/wiki/Cassandra
| goosejuice wrote:
| Maybe because they start with this tldr:
|
| > In short, nobody should start a new project in the 2020s
| based on React. Full stop.
|
| Good arguments here but the dogma doesn't help.
| andybak wrote:
| Sometimes you have to fight fire with fire. The fact that
| some people reach for React before even considering what they
| are building requires some corrective polemics.
| emmanueloga_ wrote:
| 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.
| photonthug wrote:
| 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 deep knowledge or detailed analysis about anything are
| extremely rare. If you need to communicate a subtle point or
| detailed argument, then you've already lost. This is because
| for any technical decision the opposite argument from FUD is
| easier to make _and_ easier to digest, regardless of whether
| the FUD advice is to stay /defect on the tech stack or the
| design decision or whatever. IOW the winning strategy is
| basically to always go 2nd after what TFA calls the
| "thoughtful engineer" burns out the audience by being
| rational and thorough. Even more bluntly.. most people are
| just showing up to work and have no interest (and much less
| passion) for craftsmanship.
|
| I wish it was different, since I believe in architecture /
| design. But, there's a good chance no one cares about your
| detailed analysis at all and you're much better off producing
| more shallow demos/diagrams/decks regardless of whether your
| audience is engineers or management.
| ahuth wrote:
| This is a very underrated comment.
|
| My only quibble is that it's certainly possible to choose
| React (or any popular solution to a problem) without
| considering other options too much, and still care about
| craft.
| pier25 wrote:
| I doubt it's a matter of style. There's a lot of tribalism
| and irrational opinions around React.
| andybak wrote:
| I strongly dislike React on pragmatic and philosophical
| grounds. I don't feel particularly irrational.
| senko wrote:
| I happen to agree with most of what he said, but man, that tone
| was insufferable ...
|
| (non-wrapping extra long lines have not helped but maybe that's
| on my user agent)
|
| My rules of thumb:
|
| * informational website / blog - static frontend (Django!
| :heart:)
|
| * some interactivity - htmx
|
| * a lot of interactivity (app that happens to libe in the
| browser) - spa (React and weep)
|
| For a very strong assertion he makes (even if you need spa,
| react is obsolete), he dismisses finding a good alternative as
| an exercise to the reader. The ones listed offhandedly in a
| side note look all the same (as react) to me.
| DHPersonal wrote:
| Yes, I think you're right. I overwhelmingly agree with his
| articles, but when I share the content with my colleagues it
| gets at best a careless shrug, but most often what amounts to
| "but [technology referenced] is good because it's popular."
| React is one of those problematic choices companies continue to
| make.
| troupo wrote:
| > A fun thing about reading Alex is that you can tell he's had
| the same arguments over and over again for a decade now and
| he's frustrated with having to keep on making the same points
| and getting the exact same responses.
|
| The sad part is that it's the same increasingly hostile
| arguments he's making while he spent the decade making sure
| that browsers remain bloated and tech requires Javascript to
| even barely function: see his entire work on web components.
|
| > I see him as something of a Cassandra at this point, doomed
| to see the truth about web performance based on many years of
| research
|
| He's not the only one speaking about web performance, or doing
| research. He's not Casaandra. At best, he's a false prophet.
|
| His series on web performance gaps is good, though.
| pyrolistical wrote:
| One of the under appreciated reason why spa took off is it
| exploits the lower cdn cost.
|
| Things that generate html on the server side need to pay for the
| higher bandwidth costs that are hard to cache well.
|
| In the other hand with spa, a well configured cdn can have a
| short ttl on index.html and cache the unique per deployment js
| bundles forever.
|
| The only server bandwidth cost is the actual api data
| aantix wrote:
| Turbo morphing. It's part of Hotwire.
|
| Re-Render the full page server side, app takes response, applies
| only the changes needed. Preserves scrolling state, etc.
|
| Super simple pattern for building dynamic sites.
|
| https://turbo.hotwired.dev/handbook/page_refreshes#morphing
| ericb wrote:
| This is the way.
|
| It achieves 95% of the effect, and you maintain _one_
| implementation, not two.
| shepherdjerred wrote:
| You can build a good website in React and you can build a bad
| website in React. It's easier to build a bad website in React
| than it is to build a bad website with just plain HTML/CSS.
| teruakohatu wrote:
| > It's easier to build a bad website in React than it is to
| build a bad website with just plain HTML/CSS.
|
| I think many people would argue that it is easier to build a
| good web _app_ in React than plain HTML /CSS/JS.
| shepherdjerred wrote:
| Sure, but most people think they're building a webapp when
| they're really building a website.
| emmanueloga_ wrote:
| 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`<h1 id=hello>Hello
| world!</h1>`; // New API: html Tagged templates [1].
| console.log(content); // Outputs: { type: 'h1', props: {
| id: 'hello' }, children: ['Hello world!'] }
| document.querySelector("#container").patch(content); // New API:
| HTMLElement.patch.
|
| I'm sure there are a few more details involved but it sounds like
| a relatively small addition to the current DOM APIs.
|
| I'm not aware of any initiatives like this currently.
| WebComponents could also benefit, as building a DOM tree within a
| class extending HTMLElement is still cumbersome: the
| WebComponents API doesn't really add anything to simplify DOM
| handling, which is why libraries like Lit exist.
|
| --
|
| 1: Inspired by https://github.com/developit/htm
| emmanueloga_ wrote:
| ... also TFA conflates web application architecture with
| frontend frameworks, creating a false dichotomy. For instance,
| I'm building a site that serves static HTML but still benefits
| greatly from Preact for the dynamic parts.
|
| The critique seems focused on SPA architectures heavily based
| on React, as seen in frameworks like Next.js and Remix. To be
| clear, I also lean away from that style of web application
| architecture, but I'm not sure this 20-page article effectively
| makes the case for simpler alternatives.
| floydnoel wrote:
| I thought Next.js and Remix were SSR-based frameworks, both
| created as alternatives to building a SPA.
|
| After the initial "SPA fever" died down, these frameworks
| cropped up to address the shortcomings of SPAs such as a lack
| of SEO-compatibility.
| spankalee wrote:
| There is a proposal for JavaScript-based HTML templates:
| https://github.com/WICG/webcomponents/issues/1069
| BeefWellington wrote:
| 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-level module translates to "Writing your own framework":
| function html(markup) { const templateNode =
| document.createElement(markup)
| templateNode.innerHTML = markup return
| templateNode.content }
|
| Then your code becomes roughly: import html
| from "MyModule" const content = html`<h1
| id=hello>Hello world!</h1>`; // No New API Needed
| document.querySelector("#container").replaceChildren(content.ch
| ildNodes)
|
| You're losing the pretty printing in the console but there's
| options for that -- from tweaking the toString() prototype
| method to straight up creating a custom class that acts as an
| Element.
|
| Worth noting too: you could cheat in the html function above
| and have it directly return content.childNodes, thus reducing
| the differences between the two examples to simply "patch" vs
| "replaceChildren".
|
| In your example, are you envisioning that HTMLElement.patch()
| is doing something different than Element.replaceChildren() or
| Element.replaceWith()? That'd be one area that wouldn't be
| addressed with this.
|
| Having it first-party would be lovely but it's already pretty
| doable.
| recursivedoubts wrote:
| If not react(ive, of some flavor), which is appropriate for some
| things, then hypermedia, which is appropriate for a different but
| overlapping set of things:
|
| https://htmx.org/essays/when-to-use-hypermedia/
| pier25 wrote:
| React is not reactive. That's why it re-renders the whole vdom
| when you store state at root.
| tasuki wrote:
| If not React, then Elm!
| bbkane wrote:
| There's a lot to like about Elm, but the tradeoff is that the
| BDFL (Evan) has essentially abandoned public work on it [0, 1],
| and the community seems to be shrinking [2].
|
| I personally wouldn't choose it for new projects, and I
| consider it essentially a brilliant research language (it's
| inspired a LOT of other UI work).
|
| 0: https://elmcraft.org/lore/elm-core-development/
|
| 1: https://podcasts.apple.com/us/podcast/elm-the-future-of-
| open...
|
| 2: https://reasonableapproximation.net/2024/11/02/elm-
| community...
| lilalomoslama wrote:
| In reality these few ms more do not hurt these companies. it is
| sad but true.
|
| I think react native is always a better choice than tools like
| cordova while the best choice is native development. every time i
| use a cordova app it is painful and you just know something is
| off. react-native apps are a lot nearer to native experience. you
| can differ them if your really trying to though. but if your just
| want a good native ios and android app react-native is a good
| choice. and you can slowly learn native development from there
| and shift to native if you like.
| peutetre wrote:
| The only sure cure for the JavaScript blues is WebAssembly.
|
| Use something like Leptos and be happy:
|
| https://www.leptos.dev/
| Rohansi wrote:
| The treadmill continues.
| peutetre wrote:
| Well, it's more like graduating from a kid's tricycle to a
| mountain bike.
|
| Sure the tricycle had streamers on the handlebars and the
| little basket on the front was cute, but you can get more
| places with a mountain bike.
| pier25 wrote:
| Leptos is even worse than React in memory consumption and
| startup metrics.
|
| https://krausest.github.io/js-framework-benchmark/current.ht...
| oliwarner wrote:
| > React developers are web developers.
|
| This has felt increasingly untrue recently. I hope I'm just
| experiencing the peak of the bell curve but I've been bumping
| into more and more devs who only have experience in SPA React and
| associated styling frameworks. Ask them to actually style
| something and they flake out.
|
| I was used to some tribalism in backends (everyone thinks theirs
| in the best and equally hates PHP devs and Wordpress) but can all
| publish a static page if asked.
|
| It's a self fulfilling issue. Mid-managers want React _because
| Facebook_ and pre-juniors train to meet job postings. Not enough
| question it.
| pier25 wrote:
| It's not recent. We've had memes for years about React devs
| using divs with click events instead of using links.
| oliwarner wrote:
| No, but five, ten years ago that wasn't the average "junior
| web dev" outlook. There was diversity in experience and
| education.
|
| Big money FAANG posts have really distilled the market down.
|
| Maybe I'm just an oldfart. When I started a quarter of a
| century ago, people were crowing about Frontpage experience.
| I'm fairly sure I'd boasted about Macromedia Dreamweaver 3
| expertise. And there was an explosion of technologies being
| thrown around between different devs. But now you don't get
| to discriminate against bad technology if the market demands
| it.
| claytongulick wrote:
| What's the beef with clickable divs? Are you referring to
| just the case where they're misused for top level navigation?
| Or more generically?
|
| It's pretty common to not want the default behavior of an A
| tag, so instead of the e.preventDefault();
| e.stopImmediatePropagation(); dance, a clickable div works
| great. Non deep-linked sub-nav (tabs, etc...) come to mind.
|
| Or maybe I'm hooked into a router and I need to pass some
| additional state, or control a transition direction, or maybe
| I want a navigation to happen after some async action
| completes, etc...
|
| Also, not all clicks are navigation actions.
|
| BTW, I'm not a react guy, just vanilla web components here,
| but genuinely curious why you see clickable divs as a bad
| thing?
| Kuraj wrote:
| Every time I can't middle click a link to open it in a new
| tab I want to punch a wall honestly
| andybak wrote:
| This. As community support for an app Steam comments is
| my current target of hate.
| deergomoo wrote:
| * Accessibility tools may not be able to detect that it's
| an interactive element unless you go out of your way to
| mark it up as such
|
| * It often (always?) breaks middle-clicking/opening in a
| new tab. In your navigation example is fine, but for
| example in Jira it's an absolute crapshoot which links will
| behave properly when middle-clicked
|
| * We already have a tag for a clickable element that is not
| a link: <button>
| andybak wrote:
| Do you religiously check that you haven't broken ctl-click,
| middle click or "right click/open in new tab"? I come
| across a site - sorry I meant "app" - almost every day that
| breaks this.
|
| Just use <a> and you don't have to.
| wavemode wrote:
| There's nothing wrong with clickable divs. The problem is
| using them in place of links.
|
| If you're linking to something, then just use a link. So
| people get their accessibility/screenreader support, and
| you can still use JS to accomplish whatever other auxillary
| behavior you want.
| dr_dshiv wrote:
| "Think, do, observe" -- that's over?
| flimsypremise wrote:
| I don't think the author of this article actually understands the
| pressures that increasingly drive all frontend development into
| javascript frameworks, but those pressures are actually very
| straightforward:
|
| * A large portion of the cost of maintaining a code repository
| goes toward maintaining the build.
|
| * Multiple builds per repo create significant costs.
|
| * Any web application with a UI _requires_ a frontend build for
| CSS/JS. Anyone around from the JQuery/pre-SASS days will recall
| the mess that lack of things like dependency management and
| ability to control import order caused.
|
| * If the frontend build is already baked into the process, you
| can save costs by _only_ using a frontend build.
|
| * SPA patterns are the easiest to use with a frontend build, have
| the most examples/comprehensive documentation.
| baggy_trough wrote:
| I write web apps with UI using ES6 native modules and
| https://stimulus.hotwired.dev. It's very simple, and life is
| good. No-build is the way.
| deergomoo wrote:
| I think the author understands that just fine (I follow him on
| Mastodon and this is something he is _very_ passionate about).
| To me his argument is that this shouldn 't--and doesn't need to
| --be the case.
|
| The _vast_ majority of sites out there would be just fine, and
| in many cases much better, as traditional server-rendered pages
| with a thin layer of JS on top for enhancements and for islands
| of interactivity. That massively reduces the complexity and
| cost of creating and maintaining a build.
|
| Most of us aren't working on anything that requires the
| entirety of every page and the entire navigation model to be
| implemented on the client.
| lucsky wrote:
| So he's basically publishing a 20 pages philosophical
| logorrhea to make the simple point that developers should pay
| more attention to the difference between a web _SITE_ and a
| web _APP_ and choose their stack accordingly, which is a
| totally fair point to which I 100% agree with.
|
| What I fail to see is how React is responsible for any of
| this because this sort of reads like his wife left him for
| one of the React engineer or some shit.
| ht85 wrote:
| Another thing is that almost every complaint I see about
| React (except bundle size maybe, but who cares?) exists in
| the APP context.
|
| If your use case is a simple website, React is just a nice
| templating lib and you won't need to use any of the things
| people generally dislike about it. That AND your experience
| when you _inevitably_ have to add some interactivity is
| going to be 100x better than vanilla JS.
|
| As for the build step, there are many turn key solutions
| nowadays that "just work". And isn't a small build step a
| plus, compared to being at the mercy of a typo breaking
| everything? To me that piece of mind if worth a lot,
| compared to whatever manual testing you'd have to do if you
| work with "text" files.
| hasanhaja wrote:
| > is just a nice templating lib
|
| Are these templates only used on the server-side to
| generate the HTML upfront? Or is it being generated on
| the client?
|
| > experience when you inevitably have to add some
| interactivity is going to be 100x better than vanilla JS
|
| I don't believe this can quantified. How are you
| measuring DX improvements? Are you also able to continue
| to measure these improvements as your
| application/codebase scales?
| andrewaylett wrote:
| It's certainly possible to generate the HTML up-front.
| Tooling like Next.js even sets things up so it's easier
| to render the HTML for the first page load on the server
| than to push it to the client.
|
| I have a website. It's not great, it doesn't get much
| traffic, but it's mine :). If you disable JS, it works:
| links are links, HTML is loaded for each page view. If
| you enable JS, it still works: links will trigger a re-
| render, the address bar updates, all the nice "website"
| stuff.
|
| If I write enough (and people read enough) then enabling
| JS also brings performance benefits: yes, you have to
| load ~100kB of JS. But each page load is 4kB smaller
| because it doesn't contain any boilerplate.
|
| Obviously I could generate the HTML any way I choose, but
| doing it in React is nice and composable.
| flimsypremise wrote:
| Building a web application with a UI in a professional
| context without a frontend build is borderline malpractice.
| Even a "thin" layer of JS on top requires some degree of
| dependency management, and I personally have no desire to go
| back to the days of vanilla CSS, so you need a SASS/SCSS
| transpiler. Then there's a lot of handy things that frontend
| builds do, like normalizing SVG icon formats, automatic
| organization of static assets etc. The fact is the "islands
| of interactivity" model still requires two builds.
| hasanhaja wrote:
| > Building a web application with a UI in a professional
| context without a frontend build is borderline malpractice.
|
| Why do you think that? What problem is a build tool solving
| for you that without it you think you're being
| irresponsible for not doing it by hand?
| deergomoo wrote:
| Nowhere in my comment did I say abandon a build step?
|
| I'm saying--if you do not have high interactivity
| requirements, which I would claim is most things on the web
| --you will encounter a lot less overall complexity shipping
| mostly server-rendered pages with isolated, self contained
| JS bundles where you need them.
|
| I was using multi-entrypoint build steps outputting
| separate per-page or per-feature CSS and JS bundles long
| before I ever worked on an SPA, it's hardly a good reason
| to move your entire UI and routing to the client-side.
| coddle-hark wrote:
| > Any web application with a UI _requires_ a frontend build for
| CSS/JS.
|
| Except it really doesn't. Core web technologies have gotten so
| much better since the jQuery/pre-SASS days that you can
| absolutely get by without a build step.
|
| - http/2 makes bundling a questionable choice
|
| - polyfills are pretty much no longer a thing
|
| - CSS now has most (all?) of the features that people used SASS
| for (variables, nesting, etc.)
|
| - es6 modules work
|
| This has been a big talking point in the Rails community lately
| -- one of the big selling points of Rails 8 was the fact that
| you can, by default, ship a whole webapp without a build step,
| and that this is considered the "happy path".
| no_wizard wrote:
| > http/2 makes bundling a questionable choice
|
| Only if you are talking about the single file (or runtime +
| single file) bundles which never should have been the norm to
| begin with.
|
| You can split chunks and do other optimizations you can't do
| with plain es module imports. Your options become more
| limited because your dependency graph will always be linear,
| for one. This can cause a waterfall effect even with HTTP/2
| that slows everything down.
|
| This same argument goes for everything else. Not enough
| people have taken the time to understand how these
| technologies work, their purpose, and potential.
|
| People hate on these tools without understanding them well
| enough to articulate any more than surface level deep
| knowledge about them
| yurishimo wrote:
| He works (worked?) for Google. I think he knows what it takes
| to build a site on a large team and the trade-offs.
| youngtaff wrote:
| Works for MS now
| lopatin wrote:
| I'll continue using vanilla React, for the same reason I use
| Java: it's reached the coveted "boring technology" status where
| it's mature, stable, fast enough, and has a huge community,
| resources, and ecosystem. I won't let go of that easily. However,
| this is a pretty epic rant nonetheless.
| MarcelOlsz wrote:
| You're going to love Vue. Took me about half an hour to switch
| and be productive and never looked back. I've switched multiple
| teams/devs to it as well. If not just for the devtools
| experience. I switched right before all the messy React stuff
| started getting released.
| aerhardt wrote:
| But why would OP or I switch away from React when we believe
| it's mature, stable, fast enough, and has a huge community,
| resources, and ecosystem?
|
| And perhaps most important of all: it's the tool we know.
| MarcelOlsz wrote:
| I only responded because they said they're using vanilla
| React which for some reason in my head instantly translated
| to "old version of React before it started sucking", and
| replied accordingly.
|
| >But why would OP or I switch away from React when we
| believe it's mature, stable, fast enough, and has a huge
| community, resources, and ecosystem?
|
| Yeah fair enough.
| lopatin wrote:
| By vanilla React I meant that I don't use the new Next.js
| / SSR stuff and instead build a JS file.
| MarcelOlsz wrote:
| Yeah I only realized that later :P
| floydnoel wrote:
| what do you use for routing? I built Routerino for just
| exactly this purpose, to use with vanilla React. maybe
| it'll be useful for you!
|
| https://www.npmjs.com/package/routerino
| zmmmmm wrote:
| I'm having trouble forgiving Vue for the backwards
| compatibility issues and short support period from Vue 2.x =>
| Vue 3.x. I'm now faced with unnecessary cost to upgrade line
| of business apps built with Vue that in full maintenance mode
| but now have critical security vulnerabilities popping up in
| scanners with no way to fix them other than large scale code
| migration. I saw they are now dropping support for Vue 2 even
| in the DevTools, so even migration is going to be harder, if
| we can't easily introspect the pages we are migrating.
|
| I'm suspecting they are going to drop backwards compatibility
| _again_ in the near future by deprecating support for the
| options API - leaving me with _another_ headache.
| MarcelOlsz wrote:
| That's actually fair and my one gripe with Vue, and I just
| spent the past week and a half porting over my old project
| that I wanted to resurrect. If they screw with my vue3
| using composition API then I'll dust off my pitchfork.
| yurishimo wrote:
| Week and a half... sounds nice :,)
|
| Has gitlab finished upgrading yet? Last time I checked
| they spent 2+ years and that's with codemod tools and
| super smart engineers.
|
| At work, I spent a month upgrading one project to work
| with the compatibility build and we've been slowly
| migrating for the past 18 months. After the end of this
| year, we should be out of the woods for that project but
| then we have 3 more so...
|
| Luckily, Evan has said that he has zero interest in
| fracturing the community again and I believe him. The new
| architecture of Vue 3 also makes it very easy to adopt
| almost any new paradigm into Vue as evidenced by the
| numerous demos Evan has made to compare Vue to other JS
| frameworks like Svelte and Solid.
| satvikpendem wrote:
| What I like about React is that generally speaking, it has
| rock solid backwards compatibility support (class
| components are still supported for example), presumably due
| to Meta using it at scale such that they cannot scrap
| everything immediately. Vue, being not used in any large
| company, does not have the same sense of responsibility to
| preserve backwards compatibility, it seems. This has its
| pros and cons though but for many people, backwards
| compatibility is a big deal.
| satvikpendem wrote:
| I started with Vue and switched to React, because of better
| library and TypeScript support. Every other framework pales
| in comparison to React due to its ecosystem, and I'm not
| gonna spend time building new packages to bridge that gap
| when I have my own work I need to get done, so I'll just use
| React and npm install what I need.
| hamandcheese wrote:
| To me, the best part of react/jsx is that if you know HTML,
| and you know JavaScript, you can easily write JSX. I'm
| primarily a backend engineer, but I grokked JSX pretty much
| instantly. Anything in scope in JS is available in the JSX.
|
| Vue templates are, well, yet another funny little template
| language. The hello world example already seems way too
| magical. Just let me use the language I already know.
| smrtinsert wrote:
| Java is still getting great support and great new features
| every release while maintaining backward compat
| davedx wrote:
| Amen. I adopted react for the first time in around 2014. It's
| now "boring" and various predictable groups of people are
| desperate to replace it with /something/, while I'm getting on
| with my job of delivering software using a nice set of
| reasonably standardized tools, not having problems hiring, and
| just generally enjoying life.
|
| Long may the reign of typescript, nodejs and react continue.
| ninkendo wrote:
| Maybe it's time I learn it...
|
| Last time I looked at react was 2016 or so and every tutorial
| was referencing some different mutually incompatible version of
| some component (router, redux, flux, some other alphabet soup)
| and everyone had their own list of essential ingredients in a
| basic hello world app. I came away from the whole experience
| thinking here's an ecosystem that needs to mature another 10
| years or so before I want to even look at it (I'm _not_ a
| frontend person, it's all academic to me.)
|
| Is there a consensus on any of it yet? How to do routing,
| state, builds, etc? Or is there still as many combinations of
| components as there are tutorials?
| hmeh wrote:
| Have you heard of HTML, CSS and forms? They are even more
| boring, more mature, more stable, often faster, have a huge
| community, massive resources and ecosystem. React is even built
| on one of these technologies!
| lopatin wrote:
| Which one of these technologies is React built on top of?
| hmeh wrote:
| HTML, specifically react-dom. It's built with JavaScript
| k__ wrote:
| So glad I work in an ecosystem that doesn't even support SSR.
|
| I'm also glad that the local-first movement got some traction.
| eawgewag wrote:
| I honestly think this conversation gets overly complex because we
| fail to define the kind of websites we are talking about. These
| are my definitions, so I'll just share them upfront:
|
| - a web _site_ -- which has low interactivity requirements.
| Blogs, documentation sites, etc, go here. A vast majority of
| websites are in this bucket
|
| - a web _application_ -- which has high interactivity
| requirements. Things like Gmail, Linear, Google Calendar, and an
| enormous amount of SaaS apps fit in this bucket of things.
|
| React is better at anything else at making the second. React
| developers happily pay the weird tradeoffs that come with it in
| order to efficiently develop the second.
|
| React is pretty reasonably good at making the first, but the
| negative costs are more obvious.
|
| As someone who has worked on one of the most consumed React apps
| in the world (Discord), I think the concerns with React are
| overstated. People want a good product, they don't care about the
| framework and it's costs. React is one of the most efficient (in
| terms of developer productivity) ways to get there.
|
| I'm not a React loyalist; I would love to see someone dethrone
| React. My ears are always to the ground for new developments in
| technology. In my opinion it hasn't happened yet, but I would be
| surprised if it never happens.
| chimpanzee wrote:
| > React is better at anything else at making [a web
| application]
|
| Mithril.js beats it in my opinion.
|
| I'm sure many developers would argue in favor of other
| libraries over React.
|
| React is simply the most popular.
| danjl wrote:
| Being the most popular comes with big benefits. There are far
| more articles about how to support issues that you run into,
| and many more libraries available for your use. While other
| libraries maybe "better"in some cases, giving up the support
| of the large community is a big cost.
| chimpanzee wrote:
| No argument there. But "better at" implies something
| inherent to React's design rather than to its community.
| mdaniel wrote:
| I'm glad you like it, but https://mithril.js.org/simple-
| application.html is some "uh-huh, thanks but no"
| chimpanzee wrote:
| Care to be specific? Is it the documentation you don't
| like? Is it the example application's design you don't
| like? Or is it something about Mithril itself?
| mdaniel wrote:
| Two things, in descending order of rage-close-tab for me:
| that m(.., [m(), m()]) is deeply unserious, and
| .then((result) => User.list = result) just seems
| oppressively singleton _(although I 'm open to that being
| a tutorialism but why even show users antipatterns if
| that's not how it's going to work for real?)_
|
| I tried to be neutral in my reply, so if you like it then
| I'm glad for you, and I hope your colleagues find gainful
| employment when they have to go to their next job that
| also uses Mithril. But I hope I never ever have to work
| in an organization which thinks a shitload of m()
| functions is easier to read than JSX
| edflsafoiewq wrote:
| JSX vs hyperscript is a religious issue. You can use JSX
| with Mithril if you prefer (after all the m() thing is
| what JSX compiles to).
| chimpanzee wrote:
| Yes, that whole page you cited is simply tutorialism.
|
| And Mithril supports jsx. (Not to mention the advantages
| gained by avoiding JSX in favor of hyperscript)
|
| Might be best to actually use it in a small (or large)
| application of your own design rather than judging
| prematurely.
|
| (I'm not suggesting large orgs use Mithril, as other
| commenter mentioned, community in some situations is more
| important than the tooling. But "building a web app" does
| not necessarily imply "employing a team of local
| developers to build a web app asap for less than x usd".)
| deergomoo wrote:
| > a web _site_ [...] a web _application_
|
| But is that not the crux of the article? So much of the web is
| the former but is built and distributed as if it's the latter,
| with all the end-user downsides that entails.
| andybak wrote:
| He spent a chunk of the article defining exactly those terms.
|
| I know we're not supposed to accuse people of not rtfa but
| sometimes it's a struggle.
| FridgeSeal wrote:
| > and an enormous amount of SaaS apps fit in this bucket of
| things.
|
| Let's not get ahead of ourselves. An enormous amount of SaaS's
| _wish_ they were a web app. A good chunk of them would probably
| have a net-better UX by dispensing of this delusion.
| fridder wrote:
| Well, LiveView is great
| andrewstuart wrote:
| I love react and don't feel the pain that people talk about.
|
| Yes it's hard to learn the mental model but worth the effort.
|
| My one tip to make your life with react easier .... don't use
| state except within a component, instead send document events
| ...... makes react 10X easier.
|
| Having said the above I don't do any SSR and not a fan of it.
| johnfn wrote:
| 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. Yes, there are a few specialized domains where this
| will matter. No, you probably don't work in one. Greater leverage
| can almost always be derived from improving the backend.
|
| The second reason the author says is that it's based on a legacy
| eventing system which supports IE. The author goes on for quite a
| while to say how bad this is, but I question the assumption it's
| predicated on: the legacy eventing system never bothers me, and
| it doesn't create issues visible to my users. As far as it seems
| to me, this argument is akin to saying that React hasn't bothered
| refactoring an old part of the code base. Yes, that's not great,
| but it hardly strikes me as a reason to drop a framework
| entirely.
|
| Finally, the author doesn't actually give a prescription as to
| what to use instead of React. This is, personally, where the
| argument really falls apart. React does make a set of tradeoffs,
| I don't deny that, but most alternatives I've seen make a worse
| set of tradeoffs that shift more work onto the engineer. Of
| course, since the author doesn't actually highlight any
| alternative, we can't have a discussion about what you're trading
| away, but I suspect that the author makes no proposal because he
| knows that any alternative would immediately be shot down as
| obviously worse than React.
| aaronblohowiak wrote:
| >React performance concerns in the real world are typically
| measured in, at worst, hundreds of milliseconds. Yes, there are
| a few specialized domains where this will matter. No, you
| probably don't work in one. Greater leverage can almost always
| be derived from improving the backend.
|
| Respectfully, I disagree on all of these points.
| Tronno wrote:
| Care to elaborate?
| aaronblohowiak wrote:
| Other commenters have elaborated as well, but to
| summmarize: hundreds of Ms on a dev machine a) does matter
| and b) is likely much much more in less than ideal
| computing environments, I disagree that the backend usually
| is where more time is spent (at least in maaaaany apps I
| have worked on) And re: specialized domains, I think most
| users of most software appreciate speed even if it isn't a
| stated objective
| echelon wrote:
| > React performance concerns in the real world are typically
| measured in, at worst, hundreds of milliseconds. Yes, there are
| a few specialized domains where this will matter. No, you
| probably don't work in one.
|
| This is fine for solving random business integration concerns,
| but for application software we have to use on a daily basis,
| it really sucks.
|
| Modern web applications sometimes feel incredibly shitty to
| use. Gmail, YouTube, YouTube Music, Reddit, Twitter -- these
| are all bloated, hulking, beastly things.
|
| I'm really hoping Rust becomes popular for specifically web
| _application_ development. It 'll need to overcome the awkward
| WASM/DOM bridge, but then it'll sing.
|
| Heavy software that users spend hours within are where those
| hundreds of milliseconds per action really add up. We should be
| angry about anything worse than single digit milliseconds with
| these tools.
|
| We need an engineering culture of excellence in these domains.
| Channel the Steve Jobs energy to say this isn't good enough.
| ToucanLoucan wrote:
| > This is fine for solving random business integration
| concerns, but for application software we have to use on a
| daily basis, it really sucks.
|
| And more than it just sucking, it is unnecessary. We have
| mature, well documented, cost effective solutions for
| developing software that have been around from years to
| decades. We know how to develop software. The problem is
| people trying to develop software with web tools.
| no_wizard wrote:
| > Heavy software users spend hours within are where those
| hundreds of milliseconds per action really add up. We should
| be angry about anything worse than single digit milliseconds
| with these tools.
|
| I think in the article writers mind here we are talking
| hundreds of milliseconds on first load and the majority of
| actions are instantaneous after that.
|
| This can be achieved, but it takes some diligence and product
| mind focus to optimize what you can how you can and even big
| companies like Google don't always prioritize this the way
| they should
| ToucanLoucan wrote:
| > But front end performance issues are almost never the most
| pressing issue to deal with.
|
| Maybe not to you, but it's by far and away the biggest
| complaint with any website or app that uses React/Angular under
| the hood in my experience. On any computer older than a few
| years, the sheer _amount_ of JavaScript being demanded to be
| run creates serious system bottlenecks.
|
| This is literally why I cancelled Spotify, because it's fucking
| absurd to me that I need a (then anyway) 700 MB app to stream
| music.
| johnfn wrote:
| Is it? On Hacker News it probably is, and I agree that it can
| drive engineers nuts to know that apps are more bloated than
| they have to be, but I think we're a relatively small
| percentage of the population. Among my less
| technically/inclined friends and family I haven't heard one
| complaint about, say, Spotify being slow, and certainly never
| any complaints about its size.
| ToucanLoucan wrote:
| They don't say "I'm sick of React websites," they just say
| "Wow websites are getting slower and slower." or they
| complain about specific tabs or just the browser in general
| sucking up tons of RAM and CPU.
| no_wizard wrote:
| I'm also aware they won't make the direct references and
| I'm willing to bet the OP is too.
|
| There are very few instances I can think of for the last
| 4 years where I heard anyone complaining like this about
| the general state of these things. There's a few
| offenders I can think of, like Salesforce, but I haven't
| heard from any non technical users especially about
| things like Gmail being slow or their browsers being too
| slow.
|
| Whet I often hear instead to be honest is people widely
| seem surprised when they have 200 tabs open in Chrome and
| everything still feels fast to them
|
| That's not to say performance isn't important, it really
| is, in fact I'm the performance czar where I work, I
| spend along time on optimizations and performance.
|
| However the acceptable performance threshold is dependent
| on the activity more than anything I've found. That's why
| it's such a big deal in e-commerce but people don't seem
| to care as much for longer lived apps, otherwise Jira
| might actually be snappy
|
| Now of course there is a threshold regardless of app
| where it will things negatively, losing customers etc.
| and thus it shouldn't be ignore either
| palata wrote:
| > Among my less technically/inclined friends and family I
| haven't heard one complaint about, say, Spotify being slow,
| and certainly never any complaints about its size.
|
| They don't say "modern software is slow", they say "my
| computer is slow, I need to buy a new one" and they do.
|
| Let's be honest: for what the vast majority of people do on
| their computer, there is absolutely no need for a Macbook
| M3. The only reason is that the websites are developed by
| people who buy (or get from their company) a Macbook M3 and
| therefore don't see how much their website sucks on a
| reasonable machine.
|
| I can track it very well on my father's homepage which has
| been the same for 25 years. He has a 4 years old desktop
| mac and the webpage takes more than 20s to load. On an M3
| it takes 2s. This homepage is still loading exactly the
| same kind of information than 25 years ago, yet it is
| almost unbearable on a 4 years old desktop computer. Does
| my father say that this webpage is slow? No, because all
| software goes like this. My father says that his computer
| is now old and considers buying a new one.
| croes wrote:
| People just stopped complaining and search for workarounds
| on themselves or just suffer silently.
| phailhaus wrote:
| > because it's fucking absurd to me that I need a (then
| anyway) 700 MB app to stream music.
|
| You only know that factoid because you're an engineer and you
| looked it up. Users have absolutely no clue, and literally do
| not care.
| palata wrote:
| > Users have absolutely no clue, and literally do not care
|
| When their smartphone is 3 years old and has no more
| storage space, they say "the smartphone is old, I need a
| new one".
|
| Because they don't know that this is a problem of the
| software industry being extremely bad doesn't mean that it
| has no impact on them.
| croes wrote:
| Since when are engineers not users too?
| LtWorf wrote:
| Phones are literally sold at different prices when they
| have more storage. People are familiar with being unable to
| install more apps or take more pictures. Happens all the
| time.
|
| Get out of your bubble.
| afavour wrote:
| > React performance concerns in the real world are typically
| measured in, at worst, hundreds of milliseconds.
|
| I disagree. Try loading up a library heavy site (i.e. React
| plus a half dozen associated helpers for state, UI and
| whatever, which is pretty common) on an old or cheap Android
| device. It can take multiple seconds before the page is fully
| loaded. Even once the libraries are loaded, React sites often
| involve parsing a giant lump of JSON before you can do
| anything, that's particularly CPU intensive and takes time on
| low end devices.
|
| > Yes, there are a few specialized domains where this will
| matter. No, you probably don't work in one.
|
| Again: I beg to differ. Anyone hoping that their site will rank
| well on Google needs to factor in site performance via core web
| vitals. Time and time again I've seen React-based sites perform
| horribly and it's very difficult to dig your way out of the
| hole after the fact.
|
| I actually think most of the problem isn't React itself, it's
| the ecosystem and the philosophy that surrounds it so often.
| You'll have React, you'll have some extra state management
| library on top, you'll have some hideous CSS in JS bulk on top
| because no one wants to actually learn CSS... it's all
| prioritisation of developer experience over user experience.
| And it's industry standard these days.
| satvikpendem wrote:
| With React Server Components, you can have your cake and eat
| it too, by sending only the necessary HTML to the browser
| (thereby having good performance and SEO) but also hydrating
| with more interactivity if necessary. And I'm not sure where
| you think CSS in JS means you don't learn CSS, I'm not sure
| how you'd use it otherwise... Either way, there are CSS in JS
| (TypeScript) libraries that compile down to regular CSS
| classes, like PandaCSS, so again, you can have your cake and
| eat it too.
| afavour wrote:
| React Server Components strikes me as React solving a
| React-caused problem with yet more React. Which is fine, I
| guess, if you're already locked into the React ecosystem.
| But as someone that isn't, looking at the whole proposition
| from the outside, it just screams vendor lock-in to me.
| There are too many devs out there only expert in the way
| React does things and can't step outside of it. RSC is an
| additional crutch that allows this to continue but that
| doesn't mean it's healthy.
|
| My main contention with the OP's point was the assertion
| that React is almost always the right answer. One of my
| biggest bugbears about any web dev discussion (particularly
| on HN) is that everyone treats it as a one size fits all
| argument and it isn't.
|
| If you're making a webapp with interactivity levels like
| Gmail has then React is a sensible choice. The page reloads
| very irregularly. But if you're making something like a
| blog with lots of drive by visits and only small islands of
| reactive content IMO it's the wrong choice.
| thrw42A8N wrote:
| The original problem was caused by PHP (see XHP) and this
| is just bringing the solution to full feature parity.
| hmeh wrote:
| You literally cannot. You can bake two cakes. You can't
| have your cake and eat it too.
|
| Server and client rendering? You must concern yourself with
| both. The best frameworks will not perfect abstract this
| for you. They can't, it's leaky. When the cracks show, it
| will be painful.
|
| CSS-in-JS? I've used it and fought for it. Have you ever
| looked at the css output? That's not a cake I'd want to
| eat. Compare it to a codebase with a well architected set
| of css and the markup and css actually do work for you.
| They are clarifying and reinforce structure. There are
| levels of productivity you gain based solely on things
| being clear and not convoluted that many people in our
| industry cannot recognize because they are fixated on the
| wrong thing. Whether that be what other people are using,
| or what gives dopamine hits (hot reloading, cool tech, etc)
| michaelcampbell wrote:
| Reacting to assertions of broad averages with specific
| counter examples doesn't necessarily invalidate their point.
| afavour wrote:
| OK, let me restate something from my previous component
| explicitly: a site that's concerned with SEO is not a
| "specialized domain". It is very, very common.
| Scarblac wrote:
| So are web applications that are completely behind auth
| and never need to care about SEO.
|
| They're quite different and it's a shame they're usually
| mixed up in these discussions.
| ls_stats wrote:
| >Try loading up a library heavy site (i.e. React plus a half
| dozen associated helpers for state, UI and whatever, which is
| pretty common) on an old or cheap Android device.
|
| that was the case in 2015 when entry level android devices
| were quite slow, nowdays a cheap $200 android phone has at
| least 4-6GB of RAM and an eight core processor.
|
| if that isn't enough for your react powered site, you are
| doing something very wrong.
| hmeh wrote:
| Ironically the first question you ask is the question people
| should be asking about React. Specifically, what problem does
| it solve, and do I have that problem? The problem most teams
| tend to face, and I believe part of the authors argument is
| that people reach for React out of an almost superstitious or
| orthodoxy-based belief.
|
| Likely many developers don't even know how to build something
| without React. They don't know the first thing about html,
| server-side rendering, progressive enhancement or any of the
| things we used to use to build forms over data applications
| before React came along and its siren song drew away many
| developers, and, worse, created an entire generation that fits
| the criteria I'm describing.
|
| The author doesn't need to describe an alternative any more
| than he did, because the alternative is supposed to be self-
| evident. If it's not, the person is supposed to take the
| plethora of breadcrumbs in the article and figure out how we
| used to do things before bloated, convoluted, and typically
| unnecessary frameworks.
|
| When you look at something like Remix and Next you see people
| trying go back to the simple (forms, server rendering) by
| adding additional complexity. It's doubling down on complexity,
| rather than finding simplicity.
| hasanhaja wrote:
| 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 mobile or desktop? Are they mostly accessing your
| service on cellular networks or not? Based on that, what does
| your INP look like? IMO you'll see the impact of React's legacy
| synthetic event system by looking at your INP because it's
| reinventing in userland what the platform already does well.
| This impact on INP is amplified on mobile and moreso on low-end
| mobile. See CRUX data visualised by desktop or mobile below:
|
| https://infrequently.org/2022/12/performance-baseline-2023/#...
|
| > Finally, the author doesn't actually give a prescription as
| to what to use instead of React.
|
| 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. The TLDR is there isn't a one-size-fits-all.
| agumonkey wrote:
| Curious, is this the series
| https://infrequently.org/2024/08/the-landscape/ ?
| hasanhaja wrote:
| Yes, that's the one! Thank you for linking it.
| agumonkey wrote:
| thanks back, i never saw his blog and he seems deeply
| knowledgeable
| LtWorf wrote:
| > But front end performance issues are almost never the most
| pressing issue
|
| Tell me your websites are unbearably slow without telling me
| your websites are unbearably slow :D
| itronitron wrote:
| then anything else?
| qudat wrote:
| > The choice isn't between JavaScript frameworks, it's whether
| SPA-oriented tools should be entertained at all. For most sites,
| the answer is a clearly "no".
|
| "Most sites" sit in the world of marketing, ecommerce, blogs.
| True, they don't need an SPA.
|
| Then there are businesses that "require" highly dynamic websites
| with tons of data funneling through them. I use require here in
| the sense of business requirements set by the various Product
| teams.
|
| These products benefit from being an SPA. Preload and fetch is
| such an incredible paradigm for speed and interactivity that
| every company I've worked for has appreciated. Company employees
| are not trying to run their work browsers without JS nor do they
| even have to particularly worry about mobile support. It's a very
| predictable environment: office, work laptop, internet that can
| support video calls, and a modern browser. That's the operational
| stack that many businesses require.
|
| > The predictable consequence are NPM-algamated bundles full of
| redundancies like core-js, lodash, underscore, polyfills for
| browsers that no longer exist, userland ECC libraries, moment.js,
| and a hundred other horrors.
|
| People really love to hate on npm without trying to understand
| the reason why it exists in its current form:
| https://bower.sh/my-love-letter-to-front-end-web-development
|
| As a semantic aside, I wince when people call React a framework.
| If we think of an SPA in terms of an MVC framework, it primarily
| handles the V. So really it's a view library since developers can
| use whatever M and C they want. Next.js is a react framework and
| as a React expert it's something I have zero interest in using.
|
| I could keep going but these arguments have been argued and
| counter-argued before. For a different spin on the success of
| react: https://bower.sh/react-is-bad-because-its-great
| johnfn wrote:
| I agree with most of what you said. As a minor nit, my
| understanding is that you call into a library, whereas a
| framework calls into you. Since React typically does most of
| the calling into my components I think it's fair enough to call
| it a framework.
| qudat wrote:
| That's a nice description but it is not perfect. React does
| one thing well: view = func(state)
|
| It doesn't have a great story for virtually anything outside
| of that single function which means for many large apps it is
| never enough.
| hasanhaja wrote:
| But most people don't use it for the only thing it does
| well and pick appropriate approaches for the other parts;
| they use it for everything and this has transpired into the
| reinventing of browser mechanisms like CSS in user land.
| This is the real problem. Not the tool "React" (or others
| like it) but the cult that vehemently denies their bets
| were wrong and doesn't take responsibility for the real
| damage it's caused.
| lerp-io wrote:
| the irony is that the website javascript/css is broken atm
| talkingtab wrote:
| I think almost any technology gets to the "this is stupid" point.
| Not it "was" stupid, but it is. We understand something so well,
| we know that despite being useful it is fundamentally flawed.
| This is not usually verbal knowing, but initially more from an
| intuition and understanding a pattern. I have used react, it was
| certainly a better choice than the alternatives. I like it. But
| it is now "stupid", at least for me. And why? Because my whole
| web paradigm has been changed by "mobile first". What is mobile,
| and here I am talking iPhone and "good" Android? It is a good
| processor with tiny screen and really good graphics processor.
| You can run pretty good games on many/most phones. So why not use
| that 3D technology instead of html, css? Or at least in addition
| to. If you play around for react-three/{fiber,drei} for a little
| bit it feels like you have burst out of a straitjacket.
|
| I once was told to make a product "cool" and after struggling to
| understand what "cool" even meant, I came to an idea. Things are
| cool if they make it so you never see the world the same way
| again. react-three/{drei,fiber} and threejs are cool. [For
| example https://r3f.docs.pmnd.rs/getting-started/examples]
| Etheryte wrote:
| These are cool demos, I agree, and they definitely show a
| glimpse of what the future of the web could look like. Right
| now though, pretty much all of them take ages to load, then
| spin my fans up as they run at low fps. And this is on a dev
| laptop, can't imagine what they're like on mobile or an older
| device.
| nomdep wrote:
| My iPhone 12 just crash the page while loading
| icedchai wrote:
| I never liked React. I'm primarily a backend developer, and
| preferred server generated HTML with a sprinkling of Javascript.
| It may sound ridiculous to some, but I miss the JQuery days. For
| newer projects I'm looking at Elixir / Phoenix / LiveView and
| HTMX.
| ilrwbwrkhv wrote:
| Look at Imba. If you are strong enough to avoid cargo culting
| and try things which aren't popular, they are some of the best
| ways to build frontend apps out there: https://imba.io/
| icedchai wrote:
| Thanks. It looks interesting and I will check it out.
| YetAnotherNick wrote:
| No need to miss jquery days. If you want jquery you can use it
| now. I know at least some companies use it even for greenfield
| projects.
| icedchai wrote:
| I'm fine with using it for personal projects. For anything
| with a larger team, they'd probably look at me like I was
| crazy if I suggest anything that didn't involve React, at
| least in these parts.
| openrisk wrote:
| The overall landscape for developing applications is a mess but
| this article does not help much with clearing it up.
|
| One reason for the mess seems to me is the coexistence of many
| paradigms for achieving similar functionality (for example you
| can draw many different boundaries between client and server).
|
| Combine this with the many distinct use cases (form factors,
| application types etc.) _and_ the various non-interoperable
| platforms and you have a serious combinatorial optimization
| problem.
|
| Depending on what one wants to do there might be a sweet spot of
| the 80%/20% type. Alpine.js seems to one such, which if it was
| developed many years ago it may have saved a lot of wasted
| complexity.
| luxuryballs wrote:
| * _Blazor enters the chat*_
| omani wrote:
| https://www.leptos.dev/
| breadwinner wrote:
| Here's proof that you don't need a big fat framework: Take a look
| at this SPA app:
| https://github.com/wisercoder/eureka/tree/master/webapp/Clie...
|
| It is well architected, yet only uses a 500-line component lib
| and a 500-line router.
| lihaoyi wrote:
| The fundamental magic of react is that it lets you write code
| that renders O(n) UI states in a functional manner (i.e. by
| returning the HTML you want) rather than O(n^2) UI state
| transitions in a mutable manner (by mutating the page via nested
| callbacks), and somehow makes it kind of fast-ish
|
| People love complaining about React, but I don't know if they
| remember the pre-React world where you had to write the code to
| manage O(n^2) UI state transitions via recursive mutating
| callbacks. Simple things like "have a the list of photos shown
| always kept in sync with a label showning count of photos" was
| incredibly error prone, and the complexity of implementation went
| up quadratically with the complexity of your app (due to the n^2
| state transitions you needed to worry about!)
|
| Today React is not the only one to do this O(^2) to O(n)
| complexity reduction, but it was the first to go mainstream, and
| very much deserves its success in spite of its various
| shortcomings
| hasanhaja wrote:
| How are you getting to O(n)? Is that in terms of the logic you
| need to read and keep in your mind? Or is it the actual
| computational complexity?
| throwaway284534 wrote:
| I hope that I'm not the only one who feels the anger emanating
| from these sort of blog posts. It's stuff like the Qwik
| developers claiming things like "Hydration is pure overhead" as
| if it's the mathematical proof that keeps their reality from
| crumbling. It's the same thing on YouTube with people like Theo,
| gnashing their teeth at how Tailwind is incredible; You're
| objectively stupid for not liking what I like; You're using it
| wrong; You're a not as smart as me; I drew you as the Soyjak and
| me as the Chad. Please won't somebody tell me that I'm cutting
| edge?!
|
| I really wish these people would pick up a history book. Unlike
| back-end developers, whose worth is intrinsically recognized as
| necessary, front-end development was lowly micro-managed job that
| must simultaneously keep up with customer expectations in a
| variety of formats while also rendering whatever slop passes for
| a REST API. React's adoption was a combination of talented
| marketing and a genuine empathy for the frustrations of a 2010s
| web developer. They gave us a white-lie to pitch the idea to our
| managers: "It's just the 'V' in 'MVC'!"
|
| JSX freed us from the jQuery-Rails template spaghetti. A quiet
| revolution soon followed and everyone's been butthurt ever since.
|
| Look -- Server-side templates, especially the "stringly" typed
| variety, are a demonic chimera suitable only for depraved
| alchemists. There's no type-safety, no IDE references. You're in
| Hokey Pokey Hell -- we start with a string, now we're
| interpolating, back again, now once more deeper and let's really
| put your editor's syntax highlighter to the test!
|
| It's no surprise that stringly typed tools like HTMX and Tailwind
| are so deeply admired by mid-career developers who are frustrated
| by their lack of experience and eager to prove their talent.
| That's all very normal and healthy, but the problem isn't that
| React is too complex. Building software as team is a complex task
| of communication, and pretending to be illiterate doesn't make
| the hard words any less difficult to read.
|
| There's most definitely room for improvement in React, and the
| team at Svelte demonstrated that you could have your state and
| skip the boilerplate too. Svelte's compiler is a genius move and
| unfortunately for them, React's upcoming v19 will commodify their
| complement.
|
| It's never been about replacing React -- it's about empathizing
| with developers and making it easier to work together.
| jakubmazanec wrote:
| I generally agree (that the React isn't the main culprit), but
| what does Tailwind have to do with templating? It's still just
| CSS classes, but with specific names. Also, I bet you could
| have strongly typed class name strings using TypeScript's
| template literal type somehow.
| throwaway284534 wrote:
| The gist is something like a new cohort of front-end
| developers and some begrudging back-end folks who never
| actually learned how anything worked are now trying to
| inscribe their influence as the new smart people with tools
| like Tailwind and HTMX.
|
| Wanting to prove yourself isn't a problem. It's actually a
| sign that a developer is starting to form their own opinions.
| But it becomes toxic when the primary motivation comes from a
| desire to appear smart instead of actually solving a problem.
|
| You're absolutely right about typed classes and that's how
| React Native does it. Writing and debugging CSS is hard for
| many of the same reasons that string-based templates exhibit.
| IMO the developers who push Tailwind are looking through the
| wrong end of the telescope. CSS is challenging because it's a
| combination of declarative aesthetic UI and imperative state
| management. Choosing to represent that complexity with
| Tailwind guarantees what could have be a temporary ignorance
| into a more permanent crutch that retains the same faults of
| the underlying abstraction, tragically opting out of any of
| the benefits of embracing the system. Modern CSS is pretty
| great and learning how it works pays endless dividends.
| firefoxd wrote:
| The fundamental problem with React and the like, is that it
| forced developers to unlearn the anchor tag. If you can change
| the url via js why use an actual hyperlink tag?
|
| Over the years, I'm seeing more and more unlearning of
| fundamental web from new frontend devs forged in boot camps.
| jakubmazanec wrote:
| Great, another misinformed rant about React; meanwhile React
| developers get stuff done without inventing yet another template
| language.
|
| Also, website aren't slow because of React, they are slow because
| of shitty developers or insufficient budgets.
| hasanhaja wrote:
| Why do you think bad developers or teams without sufficient
| budget may produce bad experiences when using React? What
| should those teams be caring about that React doesn't solve for
| them?
| cushpush wrote:
| Surprised nobody has mentioned Electric Clojure yet, with client
| and serverside blocks nested in _one file_.
| atum47 wrote:
| > if not React, then what?
|
| TinyJS?! http://github.com/victorqribeiro/tinyjs
| throwaway0123_5 wrote:
| I'm not a web dev at all, but when I need some web UI
| ClojureScript/Reagent works pretty well. I get all the pretty
| React components while being able to avoid JavaScript and JSX
| entirely (all XML-style DSLs that have closing tags I find
| incredibly verbose and ugly).
| harrall wrote:
| 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 unseated like jQuery got unseated when someone
| makes something that looks nicer. Every time you write a library
| (or even API at work), make sure to look at your code samples and
| you better be 100% be able to say "this is pretty."
| cutler wrote:
| React also gives you React Native, that's why.
___________________________________________________________________
(page generated 2024-11-30 23:01 UTC)