Hacker News

Show HN: Nue – Apps lighter than a React button

2025-04-015:47756568nuejs.org

Nue is HTML, CSS, and JavaScript taken to their absolute peak.

On this release we're showing what you can do by taking the modern web standards — HTML, CSS, and JS — to their absolute peak:

The entire app is significantly lighter than a React button:

See benchmark and details here ›

Going large-scale

Here’s the same app, now with a Rust computation engine and Event Sourcing for instant search and other operations over 150,000 records — far past where JavaScript (and React) would crash with a stack overflow error:

Instant operations across 150.000 records with Rust/WASM

See this demo live ›

Tooling

Nue crushes HMR and build speed records and sets you up with a millisecond feedback loop for your day-to-day VSCode/Sublime file-save operations:

Immediate feedback for design and component updates, preserving app state

Here's what this means:

For Rust, Go, and JS engineers

This is a wake-up call for Rust, Go, and JS engineers stuck wrestling with React idioms instead of leaning on timeless software patterns. Nue emphasizes a model-first approach, delivering modular design with simple, testable functions, true static typing, and minimal dependencies. Nue is a liberating experience for system devs whose skills can finally shine in a separated model layer.

For Design Engineers

This is a wake-up call for design engineers bogged down by React patterns and 40,000+ line design systems. Build radically simpler systems with modern CSS (@layers, variables, calc()) and take control of your typography and whitespace.

For UX Engineers

This is a wake-up call for UX engineers tangled in React hooks and utility class walls instead of owning the user experience. Build apps as light as a React button to push the web—and your skills—forward.

FAQ: WTH is Nue?

Nue is a web framework focused on web standards, currently in active development. We aim to reveal the hidden complexity that’s become normalized in modern web development. When a single button outweighs an entire application, something’s fundamentally broken.

Nue drives the inevitable shift. We’re rebuilding tools and frameworks from the ground up with a cleaner, more robust architecture. Our goal is to restore the joy of web development for all key skill sets: frontend architects, design engineers, and UX engineers.

We're improving the developer experience in three distinct phases:

Nue roadmap

Join the mailing list to follow our progress and see how our vision unfolds:


Read the original article

tipiirai

Karma: 2701
...
 @Hacker__News
@hacker._news

Comments

  • By fcpk 2025-04-018:0326 reply

    I see a lot of people angry at "Nue" in various ways, and I can't help but think these are people heavily relying on React and missing the overall issue. The issue is that these huge frameworks have made the web a horrible slow mess. I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible. When a simple home page dashboard or a notes page takes more than 10s to load on a 10G connection peered within 5ms of the host, and 95% of this is spent in JS, that's when you know the typical current webapp has reached a massive state of bloat only supported by fast browser engine, and people not having expectations.

    I'm not hopefully Nue would revolutionize this since there are plethora of Web SaaS companies just wanting to use "common" frameworks... but I can at least root for them.

    • By oefrha 2025-04-0112:097 reply

      The bloat isn't coming from "huge frameworks" like React.

      To give some concrete numbers: a barebones react project created with `pnpm create vite -t react-ts` clocks in at ~60KB compressed:

        dist/index.html                   0.46 kB │ gzip:  0.30 kB
  dist/assets/react-CHdo91hT.svg    4.13 kB │ gzip:  2.14 kB
  dist/assets/index-D8b4DHJx.css    1.39 kB │ gzip:  0.71 kB
  dist/assets/index-9_sxcfan.js   188.05 kB │ gzip: 59.16 kB
      A vue project (`pnpm create vite -t vue-ts`) is even smaller at ~25KB:

        dist/index.html                  0.46 kB │ gzip:  0.30 kB
  dist/assets/index-1byZ3dr3.css   1.27 kB │ gzip:  0.65 kB
  dist/assets/index-CKXNvRRZ.js   60.77 kB │ gzip: 24.44 kB
      I've created plenty of medium-sized projects with React/Vue clocking in at 200-300KB compressed (excluding image assets). You can still realistically use those on 2G — yes I've tried, not just in dev tools, but when I was actually rate limited to 2G.

      > When a simple home page dashboard or a notes page takes more than 10s to load on a 10G connection peered within 5ms of the host, and 95% of this is spent in JS.

      You can create that kind of garbage with any framework, or without framework. You can actually do worse with the traditional way of using third party dependencies wholesale (the jQuery way), you can be downloading 200KB for 1KB of actually used code.

      Edit: Also, the comparison in the article is pretty stupid. A full view in React is not much larger than "a React button", it's upfront cost + marginal cost.

      • By tipiirai 2025-04-0112:399 reply

        Author here: Fair point—React’s baseline isn’t a monster. ~60KB compressed for a barebones Vite/React setup, or even ~25KB with Vue. Medium projects at 200-300KB are definitely workable.

        But here’s the point: a single React/ShadCN button, straight from their official docs, still outweighs Nue’s entire SPA demo. Add more widgets—tabs, modals, whatever—and that gap only widens. Nue is flipping the script. Web standards let us start lean and stay lean—smaller codebases, faster HMR, quicker builds. That’s the win: efficiency that scales without piling complexity.

        • By schwartzworld 2025-04-0116:532 reply

          > a single React/ShadCN button

          So don't use ShadCN? It's so weird to put up this strawman app and then be like "see what's wrong with React"? Like showing two boards nailed together and being like "can you believe I needed all those power tools just to do this?"

          > Add more widgets—tabs, modals, whatever—and that gap only widens

          This is the benchmark I want to see. Two full-featured apps built with minimal prod dependencies. There's a pretty good chance that the various ShadCN modules share many of their dependencies so that importing more doesn't necessarily mean a linear increase in bundle size. It could be that once you build something full-featured, React projects come in smaller, or at least not big enough to invalidate the other upsides of choosing it.

          • By 9question1 2025-04-0117:191 reply

            But the OP did implement a fully featured app as the Nue comparison half of the benchmark. I have never used Nue and don't know if I ever would. I just think to be fair to the OP, even if incremental cost declines as you keep adding stuff in React, there's no way it is negative, which means the benchmark you asked for logically must have a similar result?

          • By mvdtnz 2025-04-0118:203 reply

            > Two full-featured apps built with minimal prod dependencies.

            This isn't what you see in the real world. I'd rather see comparisons to real life (where 99.9% of web apps are bloated garbage) than nonsense synthetic benchmarks like that.

            • By schwartzworld 2025-04-0211:16

              Does an ecosystem like that exist for Nue? If not, it’s the only fair comparison. The ShadCN button comes with styles and behavior that wasn’t implemented in the Nue demo.

            • By bobthepanda 2025-04-021:09

              The problem is you could also just do that to Nue, there’s nothing really preventing that.

              If your team or company has bad dependency hygiene, changing a single framework is not going to help you.

        • By oefrha 2025-04-0112:522 reply

          An extra 100-200KB compressed is a ~100ms one time cost once in a while for the majority of my users, and ~1s for 95%+ of users. At that point I'm going to optimize for developer productivity (which includes breadth of ecosystem). I can be both productive and respectful to my users with these common frameworks.

          Note that I'm very mindful of web performance, and I've been quite vocal on this site about some alarming trends like calling for the end of bundling (native esm) and roundtrips for everything (liveview and co., or at least the abuse of them). In my experience waterfalls and roundtrips are the number one thing hated by people on slow and/or unreliable networks; 100KB added to a flat bundle at load is almost nothing.

          • By troyvit 2025-04-0114:002 reply

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

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

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

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

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

            • By anon7000 2025-04-0123:051 reply

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

              • By oefrha 2025-04-020:151 reply

                Yeah, I don’t even know why people who are that clueless about frameworks are commenting; it takes less than an hour of learning of modern web development, from scratch, to shut down that notion. And other libraries to manage dates and stuff? Excuse me? How does that have anything to do with the rendering framework? Completely orthogonal choices.

                And asking about basic math on download speed is golden. No idea how someone can “manage a team trained in classic web design” without that knowledge and then pretend to care about performance.

                • By troyvit 2025-04-0215:001 reply

                  Eh, I'm clueless about this aspect of the framework (if you can call such a steaming pile of resume-driven-development such), and honestly I'm thankful for it.

                  Libraries like dayjs add complexity to the overall codebase and it's another piece of code you need to keep track of, update, and repair when its makers decide to go a different direction with it or some script kiddie decides to introduce a backdoor into it.

                  I think your larger concern shouldn't be about the "clueless people" who are commenting on this thread and rather the number of upvotes my comment got (especially compared to your rant). Clearly it struck a chord.

                  People are commenting and upvoting because the choices that went into building React leaves a lot of room for frameworks like Nue, Vue, hell even HTMX. Just because (it sounds like) you've staked your career on thinking React, the McDonalds of frameworks, is awesome doesn't change that.

                  • By oefrha 2025-04-039:031 reply

                    No I’ve not staked my career on React, I’m not even primarily a front end guy and React is my least favorite framework among popular ones, but thank you for your concern. I was debunking one ridiculously wrong comment criticizing my least favorite framework with solid, reproducible statistics, but that’s apparently a rant compared to your very insightful questions like “100ms to download 100KB, is that fiber? Cable? 5G? 4G?”, then okay. You clearly struck a chord with a large number of people so out of touch that they believe a copy of React is required for each button, and pride themselves on such ignorance because it’s “resume-driven-development”, so congratulations.

                    (Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)

                    • By troyvit 2025-04-0315:17

                      > (Another tip: Don’t bring votes into discussions, it’s both against site guidelines and laughable.)

                      Honestly: thank you, I didn't know that and won't do it again.

            • By yuskii 2025-04-0120:221 reply

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

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

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

              • By troyvit 2025-04-0215:091 reply

                I was speaking directly to the reactive framework itself (which is a smart way to get around some limitations), the div salad it pushes developers to sustain, and the fact that they felt they had to rewrite HTML such that instead of typing <h2> devs have to type something like <Heading.

                HTML is a pretty simple markup language and abstracting from it doesn't seem to make any sense.

                And I think your theory about what I mean by "classic web design" is probably right; keeping the JS separate from mark-up is one example of how I wish I could go back in time.

                But I can't. So it's time to learn to manage people who want to go this direction.

                Meta wrote React for Facebook mainly, and most other projects won't touch that scale. In my organization's case it's like we're water-skiing behind an aircraft carrier. It's the wrong tool for the job, and having three people manage 37k lines of code (excluding libraries) is tough.

                • By girvo 2025-04-0222:48

                  > HTML such that instead of typing <h2> devs have to type something like <Heading.

                  ...but they don't? Just use <h2> haha

          • By sgc 2025-04-0113:32

            Although payload can be indicative of page load speed, there are many good reasons Lighthouse scores are more complex than that. Specifically, at the start of this thread the criticism was that the js work in modern web apps is slow. I have thus far managed to avoid using react so I don't know the actual numbers, but I don't think the conversation should be reduced to payload size, even if it is obviously important. When I profile problematic pages, other than sites that don't properly scale their images, it is not usually network that bogs them down, it is the rendering.

            Even focusing on Lighthouse score or similar for a basic app is totally missing the point of Nue as presented on the linked page. It about a framework designed for speed that can handle data at scale, that is easier to control and personalize, and easier to model and thus architect. And yes, of course, most any framework can be used for good work, but the relevant question here is which one promotes it the most from start to finish, and makes it the easiest to implement. Speaking only for myself, this focus is great to see.

        • By PaulHoule 2025-04-0114:261 reply

          How much is it React/Nue and how much is everything else?

          HTML has evolved in the last 15 years to be a platform for applications. The early Bootstrap was a terrible Rube Goldberg machine because CSS didn't have civilized layout mechanisms such as grid and flexbox. Newer frameworks like Tailwind are more sensible, but still add 50k to your bundle, and if your app is complex and developed under deadlines you probably have components that use Tailwind and Bootstrap and emotion and styled-components and raw CSS and you still have to write some SCSS to get the styles just right in the end.

          I've been investigating the accessibility of various <Modal> components and found that they all suck because they do complicated things with <Portal>(s) and various-aria-attributes. HTML has had a <dialog> component that properly hides the rest of the page since 2022 but barely anyone was using it.

          If you stuck to using Tailwind or Bootstrap or raw CSS and used a minimal widget set you can make small applications with any framework. If you wrote raw CSS and made the most of the widgets that come in HTML5 (like the new stylable <select>) you can make tiny applications.

          • By kylecordes 2025-04-0116:291 reply

            Tailwind, at least for the last couple major versions, only adds the classes you actually use (plus the resets). Baseline size of the resets is far below 50k.

            Great point about the dialog element. I used it in a project recently for the first time... It was very nice to not involve a framework-heavy "portal" scheme, etc.

        • By eastbound 2025-04-0119:103 reply

          > React’s baseline isn’t a monster.

          Yes it is. It’s not size, it’s logic: Every time the component rerenders, the root loop is executed. Why? The root loop reassigns every useEffect, reruns every useState, every other hook (and useSearchParams is executed n times for n components that need it in the hierarchy) when only the HTML needs rerender.

          (Yes the programmer can optimize/memoize, and yes “a hook’s execution time is very short” (but multiplied by every cell in the table, when needed)). Must be the fault of the programmer if the framework has a super-intensive concept at the root.)

          • By code_biologist 2025-04-0119:331 reply

            I'm old enough to remember when this simplified model was why people thought React was better than alternatives.

            • By lastdong 2025-04-0120:071 reply

              I know, right? And where is Preact, Inferno and others sped-up React-like now?

              • By teg4n_ 2025-04-0122:44

                What do you mean where are they? They are still around. Preact especially is doing really cool work adding signals on top of a similar to react model.

          • By lucsky 2025-04-0218:34

            > It’s not size

            That's what TFA is complaining about: size. But nice pivot, hope your head isn't spinning too much.

          • By fijiaarone 2025-04-020:22

            Yeah, react developers don’t even realize that there is execution time as well as download time for an app.

        • By a022311 2025-04-0114:34

          I think Nue just puts you in the mindset of trying to keep the codebase as small and lightweight as possible. I wanted to rebuild my website with Nue and there was something telling me to avoid Motion, Tailwind CSS, etc. This philosophy can actually prove very helpful in the long term, however I feel that by using Nue you're really compromising on DX (development is much slower), although that might be because I'm not so familiar with creating websites without a framework. In any case, it's definitely worth a try.

        • By ouraf 2025-04-0123:50

          this means the example wasn't made to be lightweight. You'll need an apples to apples example to convince any detractor. Implement the same app using two different toolsets, document the process with each and then benchmark it

        • By nicce 2025-04-0114:222 reply

          To be honest, I am very confused with this benchmark. It is misleading.

          What is the actually size of the production build portion only for that button part? Because I think that the ShadCN button source code is not equal in size for the button that client downloads in production environment. Especially if you have SSR.

          • By hombre_fatal 2025-04-0116:291 reply

            If you look at the demo, all of the payload comes from react and the tailwindcss classes that the shadcn button refers to.

            It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.

            But still, that's a decently broad demo to fit in a small payload, so the exaggeration kinda takes away from that.

            The main thing I care about in client development is the state management solution since that's where most of the complexity comes from, and it's what makes or breaks an approach. In React, I use MobX which I see as the holy grail.

            Whether Nue is nice to use or not for me is gonna come down to how nice this is to work with: https://nuejs.org/docs/interactivity.html

            • By mvdtnz 2025-04-0118:283 reply

              > It's dishonest to call this the payload of "one shadcn button" since it's basically all react/tailwindcss fixed cost and not literally a shadcn button.

              Does the ShadCN button work without paying that cost?

              • By hombre_fatal 2025-04-0121:57

                Sure. If you just want the shadcn button by itself, it will generate this html: <button class="{tailwindcss classes}" />.

                And it has a dependency on some common tailwindcss classes that will get injected into your bundle.

                Most shadcn components depend on tailwindcss classes, and how the whole shtick works is that tailwindcss only includes in your bundle the classes that your components use across your app. Which is kind of a clever integration for a ui component 'package manager' for reducing bundle size.

                But most importantly, consider that OP's demo has very minimal CSS because they aren't using a CSS framework, and that has nothing to do with their Nue framework. It's not like their Nue framework comes with an optimized answer to tailwindcss/shadcn; you have to bring your own solution.

                So if you use tailwindcss/shadcn with React, you'd certainly use it with Nue.

                What Nue should do instead is add libraries to either side necessary to reach parity with the other side. Nue has built-in routing, so it would be fair to add react-router-dom to the React side. And they wouldn't have 100 people calling them out for the dumb benchmark.

              • By jmaw 2025-04-0120:031 reply

                Are you really going to build a site which just consists of a button?

                • By mvdtnz 2025-04-0121:071 reply

                  If I'm working with a payload budget and I'm using React I guess so?

                  • By albedoa 2025-04-020:50

                    Stop. You really do not need to be acting like this.

              • By albedoa 2025-04-0121:031 reply

                Your question is, incredibly, more dishonest than the original claim. Truly impressive.

                • By mvdtnz 2025-04-0121:06

                  What's dishonest about my question? Please keep your personal attacks to yourself.

          • By programmarchy 2025-04-0116:311 reply

            Seems like you should be correct. A shadcn button is just react, tailwind, and @radix/react-slot. But if you simply create a new shadcn Next.js template (i.e. pnpm dlx shadcn@latest init) and add a button, the "First Load JS" is ~100kB. Maybe you could blame that on Next.js bloat and we should also compare it to a Vite setup, but it's still surprising.

            • By nicce 2025-04-0117:021 reply

              Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.

              You only need couple images on your webpage and that runtime size becomes soon irrelevant.

              So the question is, that how much overhead are React/Tailwind CSS adding beyond that initial runtime size? If I have 100 different buttons, is it suddenly 10 000 kilobytes? I think it is not. This is the most fundamental issue on all the modern web benchmarking results. They benchmark sites that are no reflecting reality in any sense.

              These frameworks are designed for content-heavy websites and the performance means completely different thing. If every button adds so much overhead, of course that would be a big deal. But I think they are not adding that much overhead.

              • By mvdtnz 2025-04-0121:171 reply

                > Yeah, but my point is that you download the runtime and core of React/Tailwind just once for the whole web page and those should be removed from the test, or at least there should be comparison which includes the both cases.

                You think a test that is comparing the size of apps that use various frameworks should exclude the frameworks from the test? Then what is even being tested?

                • By nicce 2025-04-0121:34

                  Actual overhead when the site is used in reality? How much ovearhead are those 100 different buttons creating? What is the performance of state managing? What is the rendering performance in complex sites? How much size overhead are modular files adding? Is .jsx contributing more than raw HTML for page size? The library runtime bundle size is mostly meaningless, unless you want to provide static website with just text. And then you should not use any of these frameworks.

        • By jeffhuys 2025-04-0114:371 reply

          [flagged]

          • By zerocrates 2025-04-0114:45

            Some people just really like em dashes.

        • By senordevnyc 2025-04-0113:013 reply

          This sounds like ChatGPT’s voice :)

          • By dragonwriter 2025-04-0116:151 reply

            It really doesn't sound like ChatGPT’s default voice, though it is pretty good at taking on different voices so in a sense you could say that about almost anything. It does use em-dashes, which people have recently started way over-indexing on as a ChatGPT tell, but lots of posters on HN have been using em-dashes for longer than ChatGPT has existed.

            It does read like marketing material, though.

            • By senordevnyc 2025-04-0116:411 reply

              It's not just the em-dashes for me. It's actually more these parts:

              But here’s the point:

              That’s the win:

              Those sound exactly like ChatGPT when I tell it to write in a more direct, opinionated style.

              • By dragonwriter 2025-04-0117:061 reply

                It reads like pretty much every piece of tech marketing/evangelism in the last several decades. Which, sure, ChatGPT nails pretty well if you tell it to do that, but... I don't think that has high specificity as a ChatGPT tell.

                Generic marketing speak is generic.

                • By rob 2025-04-0118:051 reply

                  I agree with everybody else: it smells like ChatGPT. And I thought this before reading this chain.

                  Actually, going through their entire profile, it makes it even more obvious:

                  > Author here. No need to update the resume yet—titles do keep shifting! React’s monolithic style has muddied the waters, making it tough to build clean business logic, prioritize performance, craft CSS design systems, or just focus on user experience. Nue’s here to unblock that—giving each role room to shine with leaner tools, not cramming everyone into the same heavy stack.

                  > Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.

                  Looks like they switch to ChatGPT-mode for most of their Nue replies.

                  • By mvdtnz 2025-04-0121:20

                    I agree with you this is absolutely ChatGPT output. This should result in instant bans from HN in my opinion. I only come here to hear from human beings.

          • By jeffhuys 2025-04-0114:38

            It does, and it muddies the waters a lot. Why does it read like a sales pitch?

          • By balamatom 2025-04-0113:351 reply

            ChatGPT learned that voice from actual people, you know.

            • By senordevnyc 2025-04-0116:121 reply

              And yet, over the last year or two, people using ChatGPT to write their comments stand out like a sore thumb. The overall structure, the specific style of using em-dashes, semicolons, and colons...it's blindingly obvious.

              If you just go back a couple months and read OP's comments, they sound very different from everything they've posted today: https://news.ycombinator.com/item?id=42734300

              To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.

              • By balamatom 2025-04-0116:472 reply

                Yep, I read through some of their comments -- it is strange. I would certainly like to see people improve their grammar, punctuation, and general consistency; but, let's face it, people rarely care to.

                Call me paranoid (because, let's admit it, I am) but... after all, it's the Internet, and it's 2025! There's been enough controversy about the political power of speech over the past decade alone, that I can see people running their stuff through ChatGPT just to stay on the safe side and make things sound blandly "professional": just so they can avoid being taken the wrong way by a random reader who happens to strongly object to some particular aspect of their communication style.

                (Goodness knows I've found myself on either side of all that at different times -- personally, I find it highly inauthentic to make noncommittal "positive" statements in lieu of plain observations. It's absolutely grating; while some other people seem to require it, and can be indeed quite self-contradictorily harsh about it.)

                I can definitely see a major use case for LLMs there -- though I do find the implications quite terrifying. Call it political correctness, call it jamming stylometry, call it a day. Either way there's definitely some sort of power differential here that needs to be examined and I think the world is less prepared than ever to confront whatever its meaning turns out to be.

                Which brings me to my other point:

                >To be clear, I don't really care, I use ChatGPT all day every day, but just letting OP know it's often pretty obvious when you have it write for you.

                Now this I don't quite understand. Pointing something out ("letting someone know") generally implies you want someone else to care about that something, even if you honestly don't. So, since you don't care -- why is it that you want others to? Honest question.

                • By senordevnyc 2025-04-021:04

                  Yeah, that was ambiguous. I don’t care if people use ChatGPT to write for them, but don’t be so lazy with it that it’s so obvious and bland.

                • By tipiirai 2025-04-0117:05

                  Would love to get some help on documenting Nue! Crazy amount of work for a non-native English speaker doing both coding and docs.

      • By ToucanLoucan 2025-04-0114:583 reply

        Downloading =/= executing. Downloading 60 kb of compressed JavaScript isn't the problem, the problem is running that JavaScript, and all the resulting web calls that JavaScript will do, and all the resulting compute it will take to... I dunno, make the button round or whatever. Load time is no longer a solid metric for a good experience, that's very late 00's of anyone to say, the metric now is how long until the page is laid out, and the controls on it are responsive?

        Edit: Also how hot is my phone?

        • By trgn 2025-04-0115:58

          absolutely. page performance is the result of a hairball of initial asset loads, AJAX calls, ad-hoc roundtrips, telemetry bloat, ...

          It's so convoluted, and very app specific. Core web vitals provide the right framework to think about what is relevant, but in reality your app likely requires dedicated instrumentation to capture these phases accurately.

        • By oefrha 2025-04-0115:21

          I test my damn sites on a fucking iPhone 6 from 2014. Executing that JS is a breeze.

          React etc. runs just fine on absolute garbage kiosks. If you introduce 10MB of additional JS on top of 60KB of React, it's those 10MB's fault.

        • By knubie 2025-04-0118:131 reply

          Downloading 60kb of compressed javascript takes way longer than executing it.

          • By viraptor 2025-04-0118:551 reply

            Executing 60kb of JS can take between 0s and infinity. You can't summarise it like this.

            • By ToucanLoucan 2025-04-0119:032 reply

              It's gonna sound elitist but every one of these confident assertions on the part of, for the purposes of discussion I'm assuming are defensive React developers, reinforces that a sizable contingent of the aforementioned developer community has no grasp whatsoever on the fundamentals of programming.

              Hate me if you will, but holy fuck. "Downloading this code takes WAY more time than running it" with NO parameters whatsoever on what the code is doing is an absolutely ridiculous assertion.

              • By Tadpole9181 2025-04-0121:40

                No, it comes across as if y'all are having a bad faith argument about something outside of your field of expertise...

                Most React apps don't put an infinite loop in their components. The vast majority of the time it sets up initial state, maybe sets up a skeleton while loading some customer data, then shows a page with a few sections and a dozen inputs.

                So "holy fuck" you should probably calm yourself down.

              • By azemetre 2025-04-0119:161 reply

                Agreed. I don't think people realize that 5mb of a PNG is way different than 5mb of JS. The browser parsers that PNG way way faster than it parses JS.

                • By FridgeSeal 2025-04-0122:02

                  The PNG also doesn’t then go off and start pulling even more data down off the network.

      • By jsight 2025-04-0122:31

        > The bloat isn't coming from "huge frameworks" like React.

        I agree. This is such a familiar cycle. People still blame Java for things that were really the fault of the average "enterprise Java developer".

        The reality is that these frameworks don't automatically lead to bloated code shipping everything.

      • By xp84 2025-04-0217:23

        Isn’t using compressed numbers pretending that network bandwidth is the only cost of bloat?

        All that JS, once decompressed, needs to be parsed and actually evaluated. That is where it hurts even people on gigabit connections.

        I think frontend bloat has arrived at such an absurd level that it kind of makes me wish broadband and mobile speeds, and JS engine speeds, had paused their advancement for 15 years so that FE developers would have had to learn to write good code. Presently there is a whole generation of developers who built their whole careers in this era where you can get acceptably mediocre performance even with wildly inefficient code and an absurd amount of dependencies, most of them barely used on a given page. They’ve never been challenged to do any better, so i don’t really blame them.

      • By aubergene 2025-04-0120:42

        Just to add Svelte (`pnpm create vite -t svelte-ts`) ~8KB

          dist/index.html                  0.46 kB │ gzip: 0.30 kB
  dist/assets/index-yJpzg09Q.css   1.26 kB │ gzip: 0.63 kB
  dist/assets/index-CxtJFQC8.js   17.91 kB │ gzip: 7.72 kB

      • By actinium226 2025-04-0113:421 reply

        > You can create that kind of garbage with any framework, or without framework

        I would think it would be quite a challenge to accomplish the given task without a framework?

        • By floydnoel 2025-04-0120:28

          before React took over, "SPAs" were written with jQuery and Bootstrap, and it was common to see a project with multiple copies of different versions of jQuery. Totally possible to bloat a website without a framework. just go old school!

      • By balamatom 2025-04-0113:37

        >You can create that kind of garbage with any framework, or without framework.

        The whole point of the framework is to make even absolute garbage stick together. (While making the developer replaceable.)

    • By ikurei 2025-04-018:187 reply

      I'm not happy about how bloated most React sites are, and I've mostly stopped using it unless clients specifically request it after years of it being my main framework, but...

      > The issue is that these huge frameworks have made the web a horrible slow mess.

      I don't think this is accurate. Most bloat in the web is caused by:

      a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

      (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)

      b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible

      (I remember being shocked, some years ago, when I saw a site with 50 trackers. May be it was The Verge? Or some newspaper? Now I don't even bat an eye when the number is in the hundreds.)

      React sites can be extremely fast if the developer cares, and the bloat it introduces is rarely relevant. The OP article describes a button as 78K, but that's because it's loading the whole of react for just a button.

      If your page has hundreds of buttons, you don't bring 78K hundreds of times, and so complex sites built with React are not that inefficient.

      As a Devops engineer, do you have stats on how much of that slowness is the framework or the actual app code?

      • By mpweiher 2025-04-0110:563 reply

        > a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

        > (This is partly on React, or may be on the culture around React that has made all of this normal and acceptable.)

        Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

        Networks are fast. Machines are crazy fast. Almost 30 years ago I was doing on-line adaptation of Postscript print files. So some form input and re-rendering the Postscript with the updates from the form values. Basically instantaneous.

        • By branko_d 2025-04-0116:35

          > Networks are fast.

          Well, it depends on what you mean by “fast”: bandwidth or latency? While the bandwidth has improved enormously over the years, latency… not so much. And it never will due to the simple fact that the speed of light is limited.

          Most of the slowness seems to come about by treating latency as something that doesn’t matter (because the testing is done on a local, low-latency network) or will improve radically over time because bandwidth did (which it will not).

          Unfortunately, React wants to be both a rendering library and also manage state by tying it to the component lifetime, which encourages cascaded fetching - exactly the kind of workload that is sensitive to latency.

        • By nicce 2025-04-0114:25

          > Yes, that, too. But you are forgetting that React makes all that opimizing work necessary in the first place.

          Isn't the runtime state optimization the only responsibility of React. It's a library. The rest goes for Vite, Deno et al.

        • By tmpz22 2025-04-0112:214 reply

          Low powered android devices are a thing. Networks outside of Metro US, EU, and parts of Asia, are also a thing.

          Check out google maps there’s more to the world than your open office.

          • By HappMacDonald 2025-04-0112:33

            His point isn't "network/hardware is fast, so let's be inefficient": it is the opposite. "network/hardware is fast, so why is the page still slow?". On lower powered devices and slower networks, it's even more vital to author lean applications and web pages — but "things are slow even when the hardware and network are fast" is a simple canary that we are swimming through some problems.

          • By troupo 2025-04-0112:27

            1. Even those low-powered Android devices are basically supercomputers

            2. The Javascript bloat hurts those devices immensely. See "Performance Inequality Gap 2024" https://infrequently.org/2024/01/performance-inequality-gap-...

          • By mpweiher 2025-04-0116:301 reply

            How would you spec such a "lower powered" Android device?

            • By panstromek 2025-04-0310:331 reply

              Alex Russel did a lot of writing on this and posts yearly updates based on the state of the phone market. You can pick median, P75 or P95 device based on the analysis and set up targets based on that.

              https://infrequently.org/2024/01/performance-inequality-gap-...

              I did it the simple way and bought a first item in "sort by cheapest" smartphone list. That's Alcatel 1, and it's extremely underpowered. It's maybe a bit overkill, but if something runs on that device, it will run amazing on anything else.

              • By mpweiher 2025-04-047:091 reply

                Hmm....that's a cool writeup but not really what I was looking for. Anyway, let's take the phone configuration he mentions:

                "The A51 featured eight slow cores (4x2.3 GHz Cortex-A73 and 4x1.7 GHz Cortex-A53) on a 10nm process"

                Looking at Wikipedia, it also has at least 4 GB of RAM and comes with 4G Internet.

                The Alcatel 1 also seems to have at least a 1 GHz CPU and at least a gigabyte of RAM.

                I also had a look at the Samsung Galaxy Watch. Lowest spec I could find was 1 GHz dual core + 768MB RAM (bluetooth), 1.5 GB (LTE).

                The machine I was doing the web-based Postscript rendering on was a PowerMac G3. Single core 32 bit processor running at 266 MHz and and with 192MB of RAM. Connection was early DSL, 768 KB down, I think 128 KB up.

                I did not do any heroic optimizations, it was fast "as-is".

                So I think my point stands that modern computers, including low end Smartphones and watches are incredibly powerful and fast, including the networks.

                If your tech stack manages to bring that hardware to its knees for basic UI rendering, and requires a lot of optimization effort to run barely reasonably, then there is something fundamentally wrong with your tech stack.

                • By panstromek 2025-04-048:151 reply

                  > If your tech stack manages to bring that hardware to its knees for basic UI rendering, and requires a lot of optimization effort to run barely reasonably, then there is something fundamentally wrong with your tech stack

                  Yea, I think this is the problem, but the hard part is that it's largely outside of your control on the web. Alcatel 1 is technically a super computer, but it can't even run its own UI properly. I optimize my websites on it and while laggy, they sometimes run faster than Chrome's UI that displays them, it's crazy.

                  Running the system + the browser is already way too much and there's almost no perf budget left for the website - and it doesn't help that web tech is inherently sub-optimal in many ways, so you're already pessimized on all fronts. Even a baseline a simple page with almost no content is laggy on this device.

                  • By mpweiher 2025-04-049:551 reply

                    > it's largely outside of your control on the web.

                    On the web or in the JS ecosystem?

                    While I agree that even just the browsers are monster applications, usually duplicating (at least) the entire OS they are running on, just usually worse.

                    However, most browsers are perfectly capable of extremely snappy rendering and interactions, even on low-powered devices.

                    Let's remember that WWW.app was developed on a NeXT Cube, 25 MHz 68040, probably in the 16-64 MB RAM range (min was 8, but I am assuming it was more than the min), and that was plenty snappy.

                    • By panstromek 2025-04-0415:591 reply

                      > > it's largely outside of your control on the web.

                      > On the web or in the JS ecosystem?

                      I meant outside of your control on that device.

                      • By mpweiher 2025-04-0416:261 reply

                        Hmmm...that is the opposite of what you wrote earlier.

                        Are you claiming that even plain/styled HTML is too slow on these kinds of devices?

                        • By panstromek 2025-04-0419:29

                          Yes, pretty often. Like I said, Alcatel 1 can't even handle it's own native UI. Just opening the search/url input has like 2 second latency. On a fresh start, it's like 20s. Typing on a native keyboard is super laggy and slows down the whole phone.

                          Sites like Hacker News and textual blogs work pretty fine if you get lucky and nothing is running in the background, but you have to wait for a while for the phone to stop crunching stuff. The scrolling has noticable latency and random hiccups. If you scroll too fast, the content will show up delayed.

                          Once you add some images or a bit of javascript, you start to feel a lot more jank. You often get a perf hit when you recieve push notifications or when you re-connect to wifi, or open a native keyboard accidentaly, same with triggering browser UI or tapping the back button. Also, the browser sometimes just crashes (I guess out of memory?).

                          It certainly is usable, but the latency variance of various actions is wild. Sometimes it feels ok to use, but other times the whole session is like 1 fps for 5 minutes.

      • By regularfry 2025-04-019:105 reply

        > a) developers don't taking any time to optimize, lazy load, cache, minimize dependencies... > ... > b) the 300 tracking scripts every site has to try to squeeze as much revenue as possible

        Having seen the dynamics up close, I'd say it's far closer to the truth to say that the reason developers don't have time for a) is because they are having to spend all their time on things like b). I've not met a developer who doesn't want to build a better experience. I have met many developers who can't do so, for reasons outside their control.

        Characterising it as "if the developer cares" puts the blame in entirely the wrong place.

        • By soulofmischief 2025-04-0110:025 reply

          It's both. The majority of web developers today suck, plain and simple. They thought they could make a lot of money doing web dev and don't approach engineering as an art form or a science. They just scrape by and do not level up on their own outside of or during work.

          I've had to come in and rewrite apps before where the developers had full leeway and still produced an unmaintainable behemoth of third-party components loosely taped together.

          Also, React is a nightmare. An absolute minefield with zero cohesive vision, with an ever-changing API and a culture of shaming developers who haven't switched to the new React paradigm-of-the-year. For a framework meant for serious adults, I'd check out mithril. It's small, API-stable and intuitive, and gets right out of your way.

          • By johnisgood 2025-04-0111:311 reply

            > The majority of web developers today suck

            Because they are what we called script kiddies back then, copy-pasting from SO and now LLMs.

            I do not even know if they would classify as "junior" devs.

            This does not apply to ALL web developers, but many.

            • By maccard 2025-04-0112:13

              They still existed and wrote shitty code 20 years ago, or 30 years ago.

          • By injidup 2025-04-0111:122 reply

            > React is a nightmare ... culture of shaming developers who haven't switched to the new React paradigm-of-the-year

            proceeds to shame and suggests changing to the new paragdigm of the year.

            > For a framework meant for serious adults

            • By soulofmischief 2025-04-0111:24

              I have been using mithril for a decade. It isn't the new paradigm of the year. It's been API stable for a long time.

              And the sentence you quoted is a dig at React and the React ecosystem, not individual developers.

              Nice try, though!

            • By RUnconcerned 2025-04-0111:25

              mithril is hardly the new paradigm of the year

          • By branko_d 2025-04-0116:47

            > Also, React is a nightmare.

            I think React is a “nightmare” in similar way that JavaScript is a ”nightmare” - it certainly can be, if you abuse it, and it makes it a little too easy to do so.

            However, you can take “just the good parts” and ignore the rest. For me, that means using React as a rendering library and managing state almost entirely outside of it.

          • By lexlash 2025-04-0119:42

            I've introduced mithril at three different companies to audiences of non-UX engineers and it went well each time, resulting in small, static, API-driven single page applications. For my Software Engineering class, I'm able to get the basics across in a day and let students iterate without having to set up build tools for them. Huge fan.

            React seems to be a self-perpetuating ecosystem at this point, and I keep reading about the next framework-of-the-month being tied to a specific vendor or having an uncertain future with funding/bugs/forks.

            https://mithril.js.org/

          • By bryanrasmussen 2025-04-0111:241 reply

            I'd think it has about 60% cohesive vision, but that's just a ballpark, 0 seems way to low though.

            • By soulofmischief 2025-04-0111:271 reply

              Fair. I'm curious, what do you think are the best-designed and most cohesive parts of React?

              • By bryanrasmussen 2025-04-0111:442 reply

                The idea of JSX is I think genius.

                If I were making a component rendering type library before React I would probably end up making some fake attributes on HTML elements the way Angular and a lot of other people do. It's a pretty simple idea. Pretty much everybody was doing it about the time of Backbone and Angular etc. etc. I'm sure you can think of other examples.

                But whoever first came up with JSX said hey, if we're already making non standard HTML why not go all the way, allow you make your own semantic tree that we "render down" to HTML.

                This of course allows you in fact separate out the media target - HTML, Native App, PDF, graphics from your renderable representation of that in code, and thus have different renderers for the same declarative way of structuring content.

                https://github.com/chentsulin/awesome-react-renderer

                So to me JSX is actually a sensible step up in abstraction layer, although not all the way yet, because you still need to have lots of specific knowledge of your particular media rendering target.

                This is perhaps of particular interest to me as in about 2004 I was working on a media management system where the idea was you would feed in multiple markup formats, and a configuration for the media, and then use an in house declarative language to dynamically do things in each media, without having to have much understanding of how the media worked internally because our rendering pipeline took care of that - generated pdf, DHTML website (fancy menus), HTML help, and emails - with of course possibility of saving data for reuse in different media and cross media styling (use same company logos, color schemes, email addresses without having to write code for them in each media etc.)

                sorry about last part, old programmer wandering.

                • By threetonesun 2025-04-0113:061 reply

                  I would never want to write template files in something other than JSX at this point. Every library that does binding via HTML attributes is a huge step back, as far as I'm concerned.

                  I'd also say React's one way data binding was a big step forward when it was released. Where it (and TBH, many other SPA frameworks at the time) missed the boat was form handling, which it turns out is like 90% of the Internet and internal applications.

                  • By bryanrasmussen 2025-04-0117:10

                    I wouldn't say it's 90% (although my last quibble regarding percentages in this very thread got downvoted to 0) but it is tedious and sort of difficult because of the tediousness, but not sure I have ever seen any solution for forms that made me say, damn I like working with this.

                • By branko_d 2025-04-0116:58

                  What is truly remarkable about it is that it’s just JavaScript (after some transpilation), which means you can easily use JavaScript’s control structures. Conditional rendering has never been so easy!

        • By cbm-vic-20 2025-04-0111:263 reply

          I've seen this happen many times:

          Dev: Hey, I added that screen you asked for- take a look and tell me what you think- any layout changes, wording, etc.

          PM: Looks great! Okay, the next thing is...

          Dev: Hold on! I need to go back and clean up some of the code I put in there to test a few ideas, and there's a loop in there that has some side effects if some if the timing is off.

          PM: This looks fine. Let's move on to the next thing..

          • By mattgreenrocks 2025-04-0114:14

            If the PM is like that, the dev should eventually learn not to speak up until they're ready to move on to the next thing. To be clear, the PM should listen to the dev.

            But the system persists because both people are complicit.

          • By tonyedgecombe 2025-04-0112:041 reply

            Isn't this one of the main selling points of apps like Balsamiq, you can present something that looks sketch like rather than a completed page.

            https://balsamiq.com/product/

            • By pmontra 2025-04-0112:291 reply

              When starting from scratch: yes. When maintaining a mature application: no, because then you need to keep in sync the app and balsamiq and there is neither the time nor the will for that. And the money.

              • By edoceo 2025-04-0113:461 reply

                I'm still designing on paper with crayons (not a joke)

                • By worthless-trash 2025-04-0215:341 reply

                  I design with pencils, but I thought crayons would give the PM something to chew on when there is technical discussion.

                  Are your designs huge ?

                  • By edoceo 2025-04-0216:121 reply

                    One screen per paper I print with special guides. So, I've got various resolution represented. The I just take pictures of the drawings, load them into this webtool and connect them together.

                    Like a super low budget Balsamiq

                    • By worthless-trash 2025-04-0217:141 reply

                      I'm kinda digging the idea.

                      • By edoceo 2025-04-0217:53

                        Maybe I'll show HN, it's one of those ideas I have that just feels "too dumb" to be useful outside of my universe.

          • By general_reveal 2025-04-0112:49

            [dead]

        • By friendzis 2025-04-0111:461 reply

          How can you close the ticket without "taking any time to optimize, lazy load, cache, minimize dependencies..." if that is in the AC/DoD?

          Why don't those developers that care put important things the AC/DoD?

        • By maccard 2025-04-0112:12

          I’ve worked with plenty of developers who will argue that it’s fine on their development environment and their machine on the same network with test data and that it must be $OTHER_TEAM who is causing it. Arguably more of them than ones who really care. The problem is it only takes 2-3 of those people to bring the whole thing crashing down.

        • By ikurei 2025-04-029:49

          That's a good point. I didn't mean to demean React developers: I've been one for years and I can't say I optimized everything I could've.

          The blame for not caring enough about performance and UX is on the whole industry. That does include developers, but not just them.

      • By brundolf 2025-04-018:28

        I would go farther and say it's not even a lack of "optimization", it's a bloat of spaghetti logic that no sane person would ever write, driven by teams that don't talk to each other and are constantly pushed by stakeholders to add more layers instead of cleaning anything up

        It has nothing to do with the frameworks. Except maybe that they empowered developers, including the ones cranking out bad code

      • By cowsandmilk 2025-04-019:212 reply

        > developers don't taking any time to optimize, lazy load, cache, minimize dependencies...

        I built much more performant apps without lazy loading or caching when using html and a sprinkle of JS.

        • By jack_riminton 2025-04-019:37

          Exactly. If it's a common enough occurrence that most React SPA's are slow and bloated, it may not be the framework's fault, but if changing to a simpler framework makes it better, then it's just a semantic argument

        • By branko_d 2025-04-0117:10

          We built a document management system as React SPA which is very performant.

          Key: when user clicks on something, this causes 0 to 1 HTTP requests.

          We didn’t do lazy loading or caching either.

      • By ben_w 2025-04-019:232 reply

        > the 300 tracking scripts every site has to try to squeeze as much revenue as possible

        Just the other day I was appalled by a new record, 1604.

        I'm increasingly of the opinion this stuff needs to just be banned outright by law. None of the businesses I've talked to seem to be aware of how dishonest it looks to say "we value your privacy" while trying to get users to agree to get more companies than there were pupils in my secondary school to analyse them.

        • By pavlov 2025-04-019:411 reply

          EU has laws that give back control to users.

          But for this to be effective, the browser should be cooperating and working on the user’s behalf to limit tracking. (You know, the whole reason why WWW calls it “user agent” — it should be on the user’s side.)

          Unfortunately >90% of browsers use an engine made by the greatest beneficiary of user tracking. Hundreds of billions in future profits might be endangered by giving users actual control. The proverbial fox guarding the hen house.

          • By CodesInChaos 2025-04-0110:581 reply

            > the browser should be cooperating and working on the user’s behalf to limit tracking

            I hear Microsoft is working on a new browser that gives the user more control over cookies:

            1. It shows a confirmation dialog before setting a cookie

            2. The site can declare a machine readable policy (P3P) specifying what the cookie will be used for, which the browser uses to automatically decide if the cookie should be permitted.

            They plan to call it "Internet Explorer" or something.

        • By spockz 2025-04-0110:361 reply

          Where do these 1600 trackers even come from? Does every text writer add their own in the CMS? Is it not managed centrally? Or does every web component load their own flavour?

          I didn’t even know there were 1600 different distinct trackers around.

          • By whstl 2025-04-0111:21

            Did the page have any ads? Because ads themselves often also contain lots of third-party tools, for fraud detection, the bidding part, tracking, retargetting...

      • By ksec 2025-04-0111:102 reply

        >the 300 tracking scripts every site has to try to squeeze as much revenue as possible

        Let's say tracking for revenue is required and not an argument to be made. The question I never quite understand is why cant we have ONE scripts to rule them all? I remember there was a company / services that may be called Segment? And quick google search doesn't have anything familiar, that offers something like that.

        • By whstl 2025-04-0111:18

          The reason we still have 300 scripts is that ad-tech companies want direct control over their tracking rather than relying on an intermediary.

          So they make it harder or more limited to integrate with tools like Segment.

        • By ivan_gammel 2025-04-0111:141 reply

          > why cant we have ONE scripts to rule them all

          Because those tracking scripts are provided by competing advertising platforms and they want to own the data.

          • By PaulHoule 2025-04-0111:482 reply

            Nobody trusts anybody else. The site wants to over estimate clicks, the advertiser wants to under estimate. Of course the numbers won’t match up because you lose people along the way. If you have 300 trackers they can’t all be lying to you.

            • By ivan_gammel 2025-04-0112:08

              >The site wants to over estimate clicks, the advertiser wants to under estimate

              Only if you show the ads. Many companies do not, but still use lots of trackers. Why? Because their performance marketing team is trying to find the right mix of advertisement channels, so they go for paid search and clicks to Google, Meta and lots of other AdTech. In that case trackers are needed to optimize spending by analyzing user behavior. If certain cohort spends more time on the site, they will get more ads of it. If another cohort leaves the site quickly, they will see less ads. The promise of AdTech in general is that they personalize ads as much as possible to reduce your customer acquisition costs (CACs) - you won't waste money on showing ads to people who won't buy your product. So they need the data and they have to own it, because personalization is their competitive advantage.

            • By ksec 2025-04-0111:49

              Arh! That makes a lot more sense. Thank You. Sometimes I do wish I could learn a lot more about online advertising. But it is mostly a forbidden topic on HN.

      • By andrewingram 2025-04-019:141 reply

        Yeah, I think both these are true:

        1. React is bigger and slower than it needs to be. There are likely better choices today. 2. Most websites will be bigger and slower than they need to be due to the endless September of new devs, and the rarity of being given space to focus on size/performance. As React is popular, it means even if React was tiny and fast, these websites would still be slow.

        • By MartijnHols 2025-04-019:293 reply

          Why would React be bigger and slower than it needs to be? It's a very mature project with a professional development team behind it, I'm sure we can trust them to tackle whatever unnecessary bloat they may have. I think we should be able to trust that anything that is in there serves a purpose, and that it serves hundreds of niche edge-cases that someone will eventually run into but are non-obvious until it's widely used.

          These kinds of statements are only true if you're willing to sacrifice in other areas such as maintainability, security, stability, compatibility, accessibility, extensibility or something similar.

          • By whstl 2025-04-0111:311 reply

            I understand your answer is in good faith, but it still sounds like the same generic answer given when someone questions the engineering quality of any other popular product or service.

            The fact is that plenty of teams are mature and professional and yet most software still suffers from bloat, slowness, bugs. Why would React be different?

            Preact, for comparison, is only 5kb or so, and has almost 1:1 feature parity. It's not fully drop-in without the compat, and even experienced React devs can nitpick about it, but that's not the point: the mere fact that it exists and gets the job done is enough to raise doubts about the need for React to be quite big.

            Does React need to lose weight? Maybe, maybe not. But I don't think it's good to shut down those discussions.

            • By MartijnHols 2025-04-0112:461 reply

              I think the same generic answer _does_ apply to most mature projects. Libraries like these should be approached like discussions about starting over in mature software projects; "this time we'll do it correctly", or "this framework is much simpler". This applies very much to libraries such as these.

              When the complexity is low, projects are easy to learn, maintain and handle. That really makes them seem better and have advantages – advantages like a much reduced bundle size. But these new setups just don't do the same thing. It's a shell of what the old project did, as it's missing solutions for hundreds of edge-cases and other requirements that were tackled by the mature many-year old project that is maintained by some of the best developers. I'm sure React has a bit of bloat, but I'm willing to trust the React team that the vast majority of it is there for a reason. It might also be the cost of building on top of a very mature solution.

              Would you not shut such a discussion down when someone new in the team proposes a complete rewrite?

              Preact does not have 1:1 feature parity, if it had it would have been much more widely used (who wouldn't want a free filesize reduction?). Preact has plenty of issues, which is why it isn't as widely used.

              • By whstl 2025-04-0113:16

                No, I would not shut down discussions. I appreciate new points of view, and I’m fine with being challenged. I would especially not shut down discussions when my assumptions are nothing but a hunch.

                > Preact does not have 1:1 feature parity, if it had it would have been much more widely used

                Like another poster said, this is a logical error. Preact is fully featured.

          • By tipiirai 2025-04-0110:083 reply

            Author here. React’s absolutely mature—no question there, with a skilled team behind it. But the button example highlights something off: a single component outweighing an entire app feels fundamentally broken. There’s clear room for fresh alternatives, especially now. You can see it here on HN—seasoned devs wrestling with React’s wild complexity. Nue’s a stab at fixing that.

            • By dhruvrajvanshi 2025-04-0110:49

              > a single component outweighing an entire app feels fundamentally broken.

              I think this is an overly dramatic take. Of course react has a fixed overhead. If all you're deploying is the single button, then that overhead is for no benefit. But the overhead gets amortized over your entire app, which most likely has thousands of components. This is like a microbenchmark which only measures the static overhead. Not indicative of a real app.

              There's an entire cottage industry of "react" but smaller frameworks out there. Somehow, none of them have caught on.

              Preact is the one I'd go for if I wanted a smaller react because it's quite mature and it provides the same API.

            • By ipsento606 2025-04-0112:58

              > a single component outweighing an entire app feels fundamentally broken

              It just doesn't to me, understanding that in react-land, a single component and an entire app will have roughly equivalent size, if you're not pulling in any other dependencies.

              No one (I hope) would ever use react for a single button, so it feels like an unhelpful comparison.

            • By ikurei 2025-04-029:43

              I don't think that is fundamentally broken. React is just not the right technology for a single button, and it's not trying to be.

              If you tried to use photolitography (the technology used to print the circuits in microprocessors) to do tattoos... well it could probably work, but it would be highly inefficient and expensive and bad.

              React is for complex web applications, and it I don't think it's a very valid criticism to say that it is bad for a different use case. To some extent, the React community may have over-promoted React as the final web-dev framework, but that's also a mistake.

              In any case, kudos on creating Nue, looks really cool, I'll keep an eye on it ;)

          • By afavour 2025-04-0111:412 reply

            Compare React and Preact:

            https://preactjs.com/

            I use Preact often and very, very rarely run into an issue that justifies React being almost 20x the size.

            • By PaulHoule 2025-04-0111:552 reply

              Is it really React or the stuff it lets you bring in? Many React apps have at least one big widget set (say MUI or reactstrap or …) and then a number of “best of breede” components that do various things. It’s rare for components to be styled with plain CSS these days so you probably have to bring in Emotion and styled-components and Tailwind and …. It is all code that goes into the bundle and it’s a burden on your mind because these are all leaky abstractions and don’t absolve you of understanding CSS.

              • By chrisweekly 2025-04-0112:30

                A someone who's been developing for the web for a living since the late 1990s, I agree that nothing absolves the web developer of the need to understand web fundamentals. But laying blame for bloated SPAs at React's feet is misplaced. With SSR, you can ship React apps that work with JS disabled. And with static extraction (a la vanilla-extract) you can do CSS-in-JS with 0 runtime overhead. Being mindful of bundle size and user-perceived performance is essential. For those that pay attention and leverage the web properly as a platform, amazing performance (and capabilities / UX) with React is achievable. See https://Remix.run.

              • By afavour 2025-04-0112:06

                Oh I agree. Was just addressing OP’s argument that surely React is as optimised and small as it can possibly be. I’m personally not convinced.

            • By MartijnHols 2025-04-0112:242 reply

              If Preact truly was as feature complete as React, it would be used by everyone by now – it's old enough for most teams to be aware of it. The fact that it isn't widely used is case in point.

              • By troupo 2025-04-0112:321 reply

                > If Preact truly was as feature complete as React, it would be used by everyone by now

                That's a false logical conclusion.

                Preact (and others, like Svelte and Solid) are not only "as feature complete as React", they don't need some of the features of React (hooks are unnecessary when you have proper reactivity) and they are better at certain features (like SSR).

                People using or not using them has nothing to do with feature completeness.

                • By MartijnHols 2025-04-0112:521 reply

                  Fair enough. The quoted statement doesn't hold outside the context of the argument that Preact has feature parity. You can build the same apps with Preact and those others, you just need to sacrifice other things.

                  • By troupo 2025-04-0115:40

                    Again, there's no such thing as "feature parity" because some (many?) of React features are not required by other frameworks.

                    E.g. you don't need React hooks because Preact has signals: https://preactjs.com/guide/v10/signals/

                    Does this mean that Preact doesn't have feature parity? For a very strict definition, no it doesn't. Does it mean you need to sacrifice anything? No.

                    Same goes for many other frameworks. In modern landscape when it comes to features and abilities React is actually quite a poor offering.

              • By afavour 2025-04-0115:29

                Not really. Developers are as susceptible to marketing as anyone. React is backed by Facebook. Preact is... not.

    • By jeffhuys 2025-04-018:113 reply

      I get what you're trying to say, but aren't you blowing it a little out of proportion? At my job we have an SPA that loads a dashboard with 20+ widgets, all doing their own requests, transferring 2+ MB (compressed) of JS. It loads in two seconds, with all caches disabled. And I mean full load, not "ready for interaction". It runs on Vue 3.

      I agree that the web could be lighter, but "finding one that will do a first load under 10s is close to impossible" sounds like exaggeration - it might not be due to the framework or lack thereof.

      Btw, the webapp I'm describing is NOT built by the best of the best.

      • By _Algernon_ 2025-04-018:153 reply

        Now test it again on a 5 year old mobile device on a 3g connection with some packet loss, not in the sterile environment that is your office with a last-gen i7 processor.

        • By jeffhuys 2025-04-018:34

          Well, the post I replied to said "on a 10G connection peered within 5ms of the host" so I think it's fair to assume they also were in a sterile environment. I'm even on a lower connection with 20ms+ ping!

        • By docmars 2025-04-0116:241 reply

          The thing is, enterprise web applications are not built for phones. This would be like telling someone to run the latest Ubisoft game on a PC from 2-3 generations ago, and expecting it to perform well.

          Today's applications are more complex than ever, bloated perhaps, but the demand for features, complex visualizations, etc. rise with the patterns of seeing them more in other applications.

          • By lolinder 2025-04-0123:17

            This. So many people—both on the dev side and the annoyed HN commenter side—act as though all websites have the same requirements. They don't. The usage profile varies enormously, and if you treat every website as just a website without considering the context it's used in you're going to either waste a lot of time optimizing things that don't matter or you're going to make your app suck by not adjusting properly for your users.

        • By YetAnotherNick 2025-04-019:181 reply

          5 year old mobile isn't as slow as you make it out to be. Cheap 2025 phones is significantly slower than my 8 years old iPad. Also 3G could be fast and it isn't the protocol that makes the speed to <1Mbps.

          • By PaulHoule 2025-04-0111:56

            Could be a desktop PC with 25/3 ADSL where somebody is streaming Netflix and a game console is updating itself.

      • By InsideOutSanta 2025-04-018:282 reply

        I know I'm weird because I grew up in the 90s, but 2 MB of JS to show a dashboard with widgets still doesn't quite compute in my brain.

        • By jeffhuys 2025-04-018:351 reply

          It's not just 2 MB of JS. I'm describing ALL traffic, also the JSONs received, CSS, images, everything.

          Besides, we show many charts, and believe me when I say: financial people are PICKY when it comes to chart functionality. It needs to have EVERYTHING or you're not considered serious.

          • By mariusor 2025-04-019:111 reply

            It sounds like you're developing a turn-key highly interactive application for a very particular niche of users. It makes sense that for them the tradeoff of downloading 2MB of Javascript makes sense versus enjoying their bells and whistles.

            But for the rest of the internet, where users sometimes view your page with decrepit browsers riding on hobbled connections, 2MB is too much. Worrying about these people is not blowing it out of proportion. It's basic human decency.

            • By spockz 2025-04-0110:411 reply

              I think you are mostly describing the difference between a web application and web site. Where lately frameworks for building web applications have been used to build web sites.

              • By mariusor 2025-04-0111:211 reply

                Sure, but I think there are devs out there that are making that confusion, and parent comment I responded to seems to not be aware of the difference. You know it's not the guns that kill people, it's the web devs.

                • By jeffhuys 2025-04-0114:251 reply

                  Interesting that you think that I'm not aware of the difference, lol. Whatever.

                  • By mariusor 2025-04-0115:12

                    Yes, because you're rebutting to a post about light(er) web components by saying that we're blowing it out of proportion since your specific case with very specific users can work with 2MB of Javascript. You gave no indication that you're aware of other use cases that will benefit from these smaller frameworks, and even though I am aware you can't put in one couple hundred words post everything about your knowledge you showed zero empathy towards web users that are different than yours. Apologies if that's not the case, I still feel like it's a discussion worth having. More so if you agree with my words.

        • By black_puppydog 2025-04-018:351 reply

          Heh, I just literally built a toy dashboard in dioxus that loads just about 2MB of code, and then 700KB of css (tailwind, not optimized) and 1.5MB of payload data to visualize. Then again the 2MB includes ~1.7MB of just static data that I included in the wasm build for convenience since it will always be needed. :D

          (this was a learning project in my free time, no I'm not defending this in any way, although I'm actually quite happy with the solution of including static data in my binary)

          • By jeffhuys 2025-04-018:37

            It's interesting. I believe many of the people here know how it goes. There's no possibility of shrinking this further. It will only expand; we just have too much going on. We do have a genuine use for SPA, though - our webapp IS as complex a web-app can get, we offer no mobile version (for that, get the app).

      • By alabastervlog 2025-04-0113:27

        Transfer's only part of the story (and 2MB is a ton on anything but a great connection)—the rest is memory use, which will tend to be some multiple of the transfer size, plus whatever your code initializes, and processor cycles.

    • By geocar 2025-04-019:241 reply

      > I see a lot of people angry at "Nue" in various ways

      Interesting. I see people making overlay-broad claims without evidence or justification.

      > I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible

      Nobody is going to call in for your help unless something is wrong, so don't be surprised you haven't seen anything right. That just means people are keeping the good stuff secret (and/or they don't work for your company)

      > I can't help but think these are people heavily relying on React and missing the overall issue.

      That's too bad.

      I think that everyone who works on a slow project knows it's ultimately Management's fault, and when a codebase gets so big that nobody feels like they can fix it anymore, that's Management's fault too.

      Maybe you can think if Management called you in earlier you could've designed a better thing, but guess what: I think that would be Management's fault too.

      > but I can at least root for them

      Can you imagine if any of what you said was really True, everybody believed you, and everybody actually stopped using these "huge frameworks [that] have made the web a horrible slow mess", and that actually solved "the overall issue" so that all software is perfect and reliable? What exactly do you think a SRE does in this case? Do you think that's even a job?

      I really suggest trying to look at things differently, because I think for your skills there's a huge opportunity sitting right in front of you if you can see it.

      • By zwnow 2025-04-019:30

        Well most stuff going wrong in apps is actually managements fault. At least in my experience. Either directly or hidden in their decision making.

    • By bambax 2025-04-019:205 reply

      The real question is, do we actually need "frameworks"? Pure JS works pretty well, and no JS at all even better.

      I recently worked on an SAP project where there was a whole Java layer in front of SAP, and then a huge Angular app on top of it all; but since the point of the application was to manage b2b sales of physical things and it mattered very much whether those things were in stock, almost every screen did a full request to the SAP layer. The need for a thick "rich" client was unclear, and PHP would probably have worked much better.

      Hype aside, it seems big organizations are using frameworks as a mean to ensure uniform coding practices and make developers more easily replaceable; but surely there are better ways to achieve that.

      • By brulard 2025-04-0110:32

        Not every page or app needs framework. But building complex app without one would be very hard and time consuming, and your team would need to come up with ways to solve problems like architecture, code structure, routing, data management, state management, etc. So you would basically reinvent all the wheels on your own cost, and you will have a non standard solution, that would not be compatible with libraries out there (for example UI components) and neither with new devs. Before Angular and React came I was building apps with plain JS with jQuery (not a framework, just a lib) and I would never go back there.

      • By sparin9 2025-04-0110:08

        I agree. In a recent small project, I ran an experiment: first, I built the app in React, then in Vue, and finally in vanilla JS. In the end, I stuck with the vanilla JS version because it was significantly smaller, easier to deploy, and much simpler to maintain long-term.

      • By cruffle_duffle 2025-04-0116:18

        I worked at a startup where one of the original devs had “strong opinions” on JavaScript frameworks. “It’s all bloat!!! We don’t need that crap”. So consequently all the new engineers had to learn this dude’s codebase, which turned into to be… A framework! Only instead of a documented one that had plenty of support it was an unholy mess that required extra time to build all the stuff missing from the it’s-not-a-bloated-framework-but-pure-JavaScript-framework.

        Guess what happened the day after the dude left the company? All the engineers immediately started to replace the unholy mess of “totally not a framework” framework with an actual one.

        Guess what happened to development productivity and product quality? They went up dramatically.

      • By sensanaty 2025-04-0110:382 reply

        As someone who's worked on web apps with and without frameworks, yes, we need frameworks, especially if it's a large one or if there's a team of more than a few people involved.

        The good ones these days like Vue or especially Svelte are barely any different to how you'd do things the "vanilla" way except they provide some sane QoL features like components (anyone who says web components are the answer has very obviously never used web components) and sane data flow management to and from said components.

        I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways, even for apps that aren't that complex. And at that point you're just doing React or Angular or Vue, but worse in every conceivable way. Yay for going at it vanilla, I guess?

        • By OscarDC 2025-04-0118:52

          > but worse in every conceivable way

          I always had an issue with that sentence (and I heard it a lot). Why would experienced software developers always come with a solution worse in "every conceivable way" when implementing logic answering a problem they're having, which would have the huge advantage of being tailored for their own needs?

          I'm more of a library developer than an application one but I've seen that many JS webdevs have an aversion toward trying things themselves - instead always going for the most huge/"starred" dependency when they can. I'm not sure the impact of this philosophy is always better for a project's health than the total opposite where you would just re-invent your own wheel.

          I do have seen multiple attempts at doing a specific homemade architecture that worked out well for some applications with very specific needs even 10 years later (For example I'm thinking about a 500k+ LOC JS webapp - not intended to be accessed on a desktop browser, but that's not the only successful long-lived JS project I know with their own archi). And I guess a lot of webapps do have their own specific needs where the "default framework" solution leads to some inefficiencies or hard-to-maintain / understand mess.

        • By bambax 2025-04-0118:21

          > I mean, more power to you if you want to handle complex states without the features a lib like Vue or Svelte provide you, but in my experience you eventually end up with a homecooked framework anyways

          If state needs to be managed client-side (which is not always the case), then yes, a library is helpful. But a "framework" provides much more than state management, and those other things are usually dispensable, IMHO.

      • By j-krieger 2025-04-019:212 reply

        > The real question is, do we actually need "frameworks"?

        Yes. The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

        • By onion2k 2025-04-0110:223 reply

          The advantage of having a common API across thousands of web apps shouldn't be a point of discussion.

          We have one. It's called "the browser". The discussion is whether or not we need a higher level API than that. If we do, maybe that should also be a part of the browser's API.

          • By arvinsim 2025-04-0110:421 reply

            It would be easier if "the browser" is just one target.

            As it is, there multiple browsers supporting different levels of features.

            That's the whole reason why frameworks are made in the first place dating back to jQuery.

            • By GuB-42 2025-04-0113:222 reply

              The days of IE6 which justified jQuery are long gone.

              All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.

              • By koshergweilo 2025-04-0118:451 reply

                > All browsers that matter now support a solid common set of features which should be sufficient for the vast majority of cases.

                All it takes is one of those non majority use cases and you're going to need some kind of dependency to get things consistent

                • By pkphilip 2025-04-0214:47

                  Frameworks like Vue 3 don't actually work on older browsers since it requires ES2016 support in the browsers.. that means IE 11 and older browsers are out. With Svelte you need Microsoft Edge (IE 11 is not supported). Also, it requires Firefox 74 (released in 2020) or newer Firefox versions.

                  With React, you can make it work with older browsers using Polyfill etc.

              • By j-krieger 2025-04-0117:29

                You still can‘t style select elements in anything but brand new alpha chrome. It‘s been 20 years since that feature was requested.

          • By troupo 2025-04-0112:351 reply

            > The discussion is whether or not we need a higher level API than that.

            Try using DOM APIs to build anything remotely complex or interactive. There's a reason everyone who only uses browser APIs ends up just dumping strings into the DOM via innerHtml.

            • By skydhash 2025-04-0116:491 reply

              > Try using DOM APIs to build anything remotely complex or interactive.

              I think the core question is: Are we building something complex or interactive. I don't see the need for React or other frameworks unless you're storing a lot of mutable states client-side. But more often than not, all I see is replicating the database through API endpoints.

              • By j-krieger 2025-04-0117:29

                Any user facing website that is not a portfolio site is interactive. The days where the web is display-only are long past.

          • By j-krieger 2025-04-0117:28

            „The browser“ doesn‘t exist. So no, we don‘t have one.

        • By TickleSteve 2025-04-019:552 reply

          Pure JS is that interface... you're arguing for multiple unnecessary abstraction layers piled on top of each other.

          More abstraction != easier to use.

          • By tipiirai 2025-04-0110:131 reply

            Spot on. HTML, JS, and CSS deliver a clean separation of concerns—a perfect blank slate for killer products. You just need a few key pieces to tie it all together: templating with loops for repeating HTML chunks and a way to stitch in headers, footers, or sidebars. For apps, a routing system is a must. And HMR to supercharge your dev workflow. That’s Nue in a nutshell.

            • By troupo 2025-04-0112:371 reply

              > HTML, JS, and CSS deliver a clean separation of concerns

              There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.

              > For apps,

              For apps you need actual app-like things where your separation of concerns looks like the right image here: https://x.com/simonswiss/status/1664736786671869952

              • By skydhash 2025-04-0116:551 reply

                >> HTML, JS, and CSS deliver a clean separation of concerns

                > There's nothing clean about this separation, and concerns are never as neatly separated as people pretend they are.

                It's very clean and something repeated by almost every UI framework and document system. The separation is between structure, style, and interactivity. Most web apps actually fits the document models where you have content pages and forms. But people wants to bring desktop and game UI patterns into that. And make it a mess.

                • By troupo 2025-04-029:341 reply

                  > It's very clean

                  It's not

                  > something repeated by almost every UI framework and document system.

                  That is, hardly any UI framework separates these things. From Windows APIs to SwiftUI there's rarely a system which tries to separate these concepts. Because however hard you pretend they are separated, they never are.

                  > Most web apps actually fits the document models where you have content pages and forms.

                  Even in a document your styles are linked to the structure of your document.

                  • By skydhash 2025-04-0215:261 reply

                    > Because however hard you pretend they are separated, they never are.

                    That would hold true for whatever systems. The pretention is just for making it easier to do the job without extraneous effort. Cascading is a nice pattern for applying properties in the case of a document. JS was originally intended for scripting (not for full-blown application) and the DOM API works fine for that. Without that, we would have to put everything in HTML or have something like Flash.

                    • By troupo 2025-04-0220:181 reply

                      > That would hold true for whatever systems.

                      Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?

                      And now it's "they are never separated, and this holds true for whatever systems"

                      > The pretention is just for making it easier to do the job without extraneous effort.

                      In reality there's a lot of extraneous effort especially when systems become more complex. BEM was invented not because CSS was great and amazing at reducing effort, but because it was adding a great amount of effort for a very large number of designs.

                      CSS Scoping was finally, thankfully, added not because cascading nature of CSS reduces a lot of effort.

                      The rest of your comment has nothing to do with what I said.

                      • By skydhash 2025-04-034:061 reply

                        > And now it's "they are never separated, and this holds true for whatever systems"

                        What I described as separation is a a decomposition into modules which are linked together through a contract. CSS has cascading and selectors, while JS has the DOM API. Otherwise, it would still be attributes on tags.

                        BEM is just a development technique, not a technical requirement or capability. Without cascading, we would probably have components and inheritance.

                        > Remember how you started with how every UI system and framework was somehow this separtaion of style and presentation and structure and interactivity?

                        On Android and iOS, you have XML for layout. QT and GTK have support for CSS like styles. I remember at least one of the have supported XML for layout definition. They're not required, but they make it easier to build the UI as it almost always have a tree structure.

                        • By troupo 2025-04-038:46

                          > What I described as separation is a a decomposition into modules which are linked together through a contract.

                          wat

                          > Without cascading, we would probably have components and inheritance.

                          indeed. That is why I wrote what I wrote about BEM and CSS Scoping

                          > They're not required, but they make it easier to build the UI as it almost always have a tree structure.

                          Those systems have support, but there's rarely, if ever, a true separation of styling and structure. There's a reason for that, illustrated here: https://x.com/simonswiss/status/1664736786671869952

                          The separation between CSS and HTML is a good idea in a very theoretical abstract academic sense. It never ever worked in practice.

          • By j-krieger 2025-04-0117:311 reply

            Your comment shows that you don‘t have a lot of experience in that matter. „Pure JS“ (there is no such thing) has perhaps the tiniest standard library of anything out there. The rest is browser vendor code, of which a lot depends on browsers and versions. Hell, they didn‘t even get date parsing right.

            • By TickleSteve 2025-04-0211:45

              "Pure" JS exists as a concept, not a project.

              Having a tiny standard library is also a good thing, not a bad one... I'm not saying its an ideal API but in general, smaller==better (within reason).

    • By mapcars 2025-04-018:38

      > Web SaaS companies just wanting to use "common" frameworks

      Companies obviously want to use what works well and been tested and tried in production. If Nue achieves that with significant benefits outweighting the migration costs it will become the new common.

      The "problem" with React is that it improved developer experience and efficiency by a ton compared to what was there before it, and not because of anything else.

    • By maxloh 2025-04-0110:451 reply

      IMO, this framework is built for use cases normally handled by React-based static site generators. For instance, a simple marketing site for a company. In these use cases, React is obviously an overkill. You wouldn't want your users to download, parse, and execute 2.8 kB of the React runtime just for simple buttons, tabs, and routing.

      However, I don't find this framework suitable for more complex state-driven applications. If you want to build X's front end with this framework, you're just shooting yourself in the foot. It won't take an hour before you hit the framework's design limitations.

      Just choose the right tool for the right job.

      • By tipiirai 2025-04-0110:493 reply

        Author here: You’re right that Nue shines for simpler sites—like marketing pages, blog, and documentation. But calling it just a static site generator misses the mark. This latest release (check mpa.nuejs.org/app/?rust) handles a Rust-powered SPA with event sourcing over 150k records—far beyond ‘simple.’ For state-driven apps, Nue’s model-first approach keeps things clean and scalable—limitations are there, sure, but they’re not the foot-shooter you might think. Right tool, right job—totally agree—just saying Nue’s toolbox is bigger than it looks!

        • By girvo 2025-04-0110:521 reply

          > Nue’s model-first approach keeps things clean and scalable

          Like I understand why you say this, but as someone who spent the 2000s building "model first" web apps (and desktop applications), I don't miss it in the slightest. Immediate mode-esque render loops didn't catch on just because it's a fad, it really does fit a lot of highly interactive things better.

          Of course the bigger problem is people using something that's great for heavily interactive web applications for building things that _don't need_ that interactivity...

          Nue looks great, and I think it stands on it's own two feet. The constant React bashing just turns me off it more than anything (and that's not about React specifically, I have no real love for it, just that kind of project marketing isn't my cup of tea)

        • By maxloh 2025-04-0111:17

          Thanks for your reply! The misconception might stem from the lack of clarity in the documentation regarding how islands (components) work.

          - How do I declare local states (instance variables) in an island?

          - How do I fetch and display data from an API?

          - Where should we place data that is normally kept in contexts/stores in other frameworks?

          These are common problems faced when developing an SPA, but missing in the documentation.

        • By tombl 2025-04-0112:09

          hmm, it looks like you've got a bug in the demo app. if you type too quickly into the search bar, the entire app slows to a halt.

          seems like you'd want to move the filtering logic off the main thread, or you'd want to reinvent React's "Fiber" suspendable rendering architecture.

    • By docmars 2025-04-0116:21

      Anything that forces React off its boring throne of forced ubiquity is a good thing in my book, not only for its lack of optimization, but its unwillingness to move past its outdated APIs and state management patterns. The amount of limitations I've faced using it compared to other libraries / ecosystem is enough to drive anyone mad.

      I will say these claims about 10-second load times are highly exaggerated though. I've built several large applications with Vue and React, and once compiled, load within 2-3 seconds, with any remaining time spent requesting data at the mercy of your servers, which is going to happen in any client-side application, including native apps; so this isn't browser technology's fault.

      Once cached, loads instantly -- and anyone complaining about cold starts can take their criticism to native app makers for phones, or motherboard manufacturers for long boot times. It's hardly an issue because of caching, and I tend to think the complainers about the modern web are forgetting how much more complex our applications are these days. Raw speed for lack of features? Or a little bloat for more capabilities? Pick one, and accept the tradeoffs. Maybe one day browser tech won't force us to choose.

      While there is a case to be made for slow internet connections (this is where Svelte and other compiled runtimes come in with SSR), for the average enterprise using a private SaaS, or home internet customers using public SaaS apps on the web, by-and-large the experience is going to be just fine, unless the team who built the app didn't optimize.

      All that aside, it's refreshing to see more ground being broken in the area of speed — I'm all for it.

    • By andai 2025-04-019:472 reply

      I often hear it said that devs should use slow machines and connections for development. That's a great idea (and it can be simulated) in theory, but in practice very few people are going to buy old ThinkPads to test on. So a solution should probably be done in software, i.e. at the level of compilers and runtimes.

      i.e. if JS engines weren't so fast, bloated frameworks would be impossible, even on dev hardware.

      So I'm wondering if just like C++ compilers have optimization levels, perhaps there should be negative optimization levels, where all your code runs 10x slower by inserting dummy instructions (or perhaps a browser for testing that uses a naively implemented JS engine).

      This would allow you to directly experience the pain you're causing without leaving the comfort of your fancy dev machine.

      Then again by the sound of it, the release build of the app running on v8 already takes 10 sec to load, so we have already achieved the goal of gross lag without special tooling, so clearly people just don't care (or are working in systems where they feel powerless to fix it)?

      • By johneth 2025-04-0110:371 reply

        > So a solution should probably be done in software

        In Chrome you can simulate a slow connection on a slow device via the dev tools. Firefox has a similar feature.

        It's not entirely what you're suggesting (which is sort of like Chaos Monkey but for web apps I guess?)

      • By thunderfork 2025-04-0116:48

        [dead]

    • By rdsubhas 2025-04-0116:16

      The context of what the application does matters. I'm extremely cautious when people hype up "download sizes", when such size is less than 1MB, because this is usually a sign of cosmetic obsession and/or disassociation from the real world value offered.

      A 200-300kb "bloated" single page app which does the job of a 10MB "minimalistic" downloaded store app – is IMHO pretty incredible. It's doing the same work at nearly 1/50th the size, all else being similar (externally loaded images and stuff). Heck, even a 1MB page load size is still 1/10th smaller.

      Sure, it can be argued that the browser does most of the heavylifting. The same can be said of Android or iOS too, definitely the OS offers _even more_ heavylifting than the browser.

    • By martinsnow 2025-04-018:111 reply

      Rarely is that a problem with react itself. Poorly written applications exist in every flavor of language, framework and library.

      • By mentalgear 2025-04-018:261 reply

        Some frameworks though make it easy to fall into a good default, and others don't.

        • By jack_riminton 2025-04-019:40

          Yep, the more complex an app can be, the more complex the app will be

    • By throwaway290 2025-04-018:161 reply

      As I wrote in my comment it's a cool project but the way it's presented as a takedown of React is so ironically wrong. People pick React when they need a rendering layer and want to write the rest themselves. People who need a monolith SSG that is optimized for this thing choose Vue/Astro/Next and the like and that is Nue's niche. If you write a rendering library that beats React at its use cases then be my guest please brag about it

      • By tipiirai 2025-04-018:182 reply

        Thanks for the take—glad you think the project’s cool. I get where you’re coming from: React’s a rendering layer for folks who want control, while Nue’s tackling a broader scope, closer to Vue/Astro/Next combo. The ‘takedown’ vibe isn’t the goal, though—more like highlighting how web standards can slash bloat across the board, even for something as ‘simple’ as a button. Nue’s not here to just beat React at rendering; it’s rethinking the whole stack to avoid needing so many layers in the first place. Fair point on use cases—definitely food for thought as we push forward

        • By troupo 2025-04-0115:451 reply

          So far this "re-thinking" is just dumping loads of innerHtml's and trashing the entire DOM.

          The only reason it's fast is because browsers have been optimized beyond any sane reason.

          E.g. your table demo removes and re-adds all rows on every button press. This is not re-thinking. This is throwing all we've learned out of the window and starting from scratch.

          • By tipiirai 2025-04-0115:491 reply

            Nue JS reactive library is based DOM diffing. The next version also has keyed rows.

            • By troupo 2025-04-0120:20

              I looked into the code linked elsewhere in the thread and then just watched the behavior in the browser dev tools.

              Delete the entire thing, recreate, delete the entire thing, recreate. That's as far as the amazing web standards will take you.

              As soon as you start talking reactive, dom diffing, and keyed rows, you're literally in the territory of the frameworks you so love to berate.

              Frameworks, especially modern ones, do all that and so much more (and leverage web standards whenever possible if those give an advantage)

        • By throwaway290 2025-04-018:24

          Cool, good luck! Building on top of Web standards is definitely a great idea and your (non-Rust) demo is pretty good. If I wanted to build a static webapp and was in the mood to play with something new I might try it.

    • By sensanaty 2025-04-0110:481 reply

      > I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible

      I am currently in Indonesia on extremely flimsy and slow wifi at 1-2 bars that maybe tops out at 50mbps on a good day if no one else is on it and the gods align to grace me with a decent speed. Day-to-day, it's around 25mbps.

      Doing a hard refresh of Linear (not affiliated in any way other than using them for work, but I know they use React), a complex project view that includes many graphs and other things like that, the full load time for everything on screen is 5.6 seconds with ~15MB of content loaded (this includes images and interactive graphs). DOMContentLoaded finishes at 360ms and the full interactive load is finished at 600ms, with me being able to click on tickets and navigate to them at the roughly 1s mark or less. Back home Linear load instantly for me with full interactivity, and the cached version of it even here in Indonesia is similarly fast.

      It's not the frameworks slowing things down, it's usually all the bullshit that the business forces on its users that the devs have 0 say over. The app I work on loads really, really fast on dev builds that don't have any of the idiotic tracking BS enabled (for example on staging builds, which aren't even fully optimized builds compared to regular prod builds), but because the marketing, data and sales teams want their google analytics and 7 other tracking softwares, the whole thing slows to an unbearable crawl as we load in dozens of MB of packages each bigger than the Vue library controlling the whole thing.

    • By ellinoora 2025-04-018:16

      Indeed. This button comparison is quite telling, ragardless of the exact details. Definitely going to look what Nue is made of. It's refreshing to take a closer look at modern web standards — Nue or not.

    • By sheepscreek 2025-04-0121:301 reply

      A 10-second load time on a 10G connection??? That’s a peak throughput of 1.25 gigabytes per second. Even if we’re being conservative and assuming you’re only getting a quarter of that speed, that’s still around 3 GB downloaded in 10 seconds.

      There’s no legitimate way a dashboard or notes app should be anywhere near that size. That’s not “just a bit of JS bloat” — it’s multiple orders of magnitude beyond what would be reasonable. The claim is not just exaggerated — it’s wildly misleading for anyone unfamiliar.

      • By scsh 2025-04-0214:07

        fwiw, I did not have the same take away as you from that part of the comment. I think the intent, and the way I read it, was, "Even when eliminating bandwidth and latency as a factor it still takes 10 seconds to load."

    • By robertlagrant 2025-04-0110:251 reply

      > The issue is that these huge frameworks have made the web a horrible slow mess. I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible.

      If you make a React page you will see that it is absolutely instant to do things. React isn't a huge framework. It's a very fast library. Even if you add in all the extras such as routing, it's all instant. It's almost jarring how instant it is.

      A dashboard taking ages to load isn't going to be React.

      • By PaulHoule 2025-04-0114:101 reply

        "Instant" can mean different things to different people.

        I have an HTMX/Flask/Bootstrap app that feels instant for most requests on the LAN, except when it doesn't.

        Often React apps are pretty snappy, but if you want to do complex data validation on controlled forms, where the state updates for every keystroke, it can drag you down. There are good frameworks for doing uncontrolled forms in a disciplined way

        https://react-hook-form.com/

        but it's another thing to add to your bundle. React is also not fast enough to do animations so you have a lot of .show/.hide (or display: none) CSS has facilities to do transitions and animations that are pretty good but I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want.

        • By robertlagrant 2025-04-038:42

          > I always find it a little nervewracking for a JS application to have state in React state variables and any other kind of state. Some ImGUI frameworks have components that look superficially like React components but are fast enough to animate every frame, which makes me feel like I am in control and get the animation to look exactly what I want

          I know what you mean there. I had the same feeling back when I was doing frontend things.

    • By SebastianKra 2025-04-0111:40

      I dislike the disingenuous discussion around it.

      Last time this was posted, the author called out headlessui for being too complex, and presented a half-broken, non-accessible Select component as alternative.

      Digging around the code, I found questionable decisions such as throwing away the entire dom when re-rendering a list.

      I want framework authors to be clear about the tradeoffs they make. The Svelte and HTMX devs openly discuss the weaknesses of their solutions vs industry standards and are open about previous mistakes.

    • By nsonha 2025-04-019:33

      I'm a lot more open to "coding in untyped strings" these days, but if you ship yet another syntax on top of html without proper tools (lsp or whatever way for it to play nicely with typescript), then I find it rather lame. I'd rather just write truly vanila js and html, instead of using another "framework", for no apparent benefit.

    • By CodeCrusader 2025-04-0915:08

      I think with necessary effort websites with most of the frameworks could be loaded quite fast (with some obviously it is easier), the thing is it's rarely the priority compared to the business needs that are getting addressed.

    • By nine_k 2025-04-0116:591 reply

      Nue indeed looks interesting. I could not immediately understand whether it uses a one-way data binding. Without it, and without a reactive model of some sort, building large UIs becomes a pain.

      The React-based button from some framework is either over-engineered, or does way more than just a button. Using or not using such a component is a choice.

      React may be a bit large (like 30-50 kB for a "hello world"), but preact is below 6 kB and gives you 90% of the React power for lighter-weight apps.

      Also, the point of React is building huge and hugely complex dynamic UIs. There are much lighter-weight tools to add small bits of interactivity to mostly static pages, which are still the majority of the Web. (Ironically, HTMX is 14 kB, 2.5 timex larger than preact.)

      • By recursivedoubts 2025-04-023:381 reply

        We also created fixi, which is sort of preact to htmx’s react:

        https://github.com/bigskysoftware/fixi

        a goal of fixi is to be smaller uncompressed than preact is compressed, to force us to be minimalist

        • By nine_k 2025-04-026:15

          This is really nice and simple.

          I wonder how would the Web develop if something like this appeared in 1997 along with DHTML.

    • By maelito 2025-04-0112:27

      Most websites are fast before the marketing departments comes to bloat it with ads.

      10s of site loading time without ads or videos is crazy, none of the 100 websites I'm using daily are way faster than that.

    • By j-krieger 2025-04-019:21

      > I deal as DevOps/SRE daily with these services, and finding one that will do a first load under 10s is close to impossible

      Come on. That can't possibly be true.

    • By CyberDildonics 2025-04-0214:44

      Well said. The average person these days is mostly buying faster computers and phones so they can run more and more bloated web pages that just get in the way of getting to the text, images or video they want.

    • By lern_too_spel 2025-04-0116:29

      Qwik has the right idea for speeding time to interactive for complex web applications. This seems to be doing the same old thing as every other framework.

    • By jbreckmckye 2025-04-018:17

      Generally, the thing that slows down "bloated" pages (a somewhat broad term) is either chained API calls, or GTM

      Swapping out your render layer won't change that

    • By chidam333 2025-04-0212:35

      [dead]

  • By davedx 2025-04-018:316 reply

    This is what they're replacing react with: https://nuejs.org/docs/view.html

    It's an untyped view layer kind of along the lines of early angular 2.0.

    The model files are plain javascript.

    So no typings anywhere. Which is fine, I guess this is targeting the vuejs crowd. Maybe their marketing should pivot a little bit in that direction, most react people now use TypeScript because first class types in your view layer are super useful

    • By tipiirai 2025-04-018:5022 reply

      Author here: It’s true—Nue’s view layer is untyped. That’s by design. React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill. Nue flips it: presentation stays clean and semantic, web standards do the heavy lifting, and real static typing (like Rust or Go) shines in business logic where it counts. Thoughts on this?

      • By tossandthrow 2025-04-019:371 reply

        > ... slapping TypeScript on everything—even CSS—which is overkill

        Yikes, this framework will never fare well in any decent sized or above project.

        Even Typescript is problematic sometimes, as it has several forms of coercion.

        I manage 2 large scale production apps using Typescript (Along with the rest of the infrastructure) with a small team.

        This simply would not be possible, had I not been guaranteed that things at least type check when reading diffs from PRs.

        • By mplanchard 2025-04-0112:235 reply

          This is a silly take. There were certainly plenty of large projects written in JS before Typescript existed or became popular, some maintained by small teams or single individuals. There are plenty of large projects written in Python pre-typing, in PHP, etc.

          I personally choose to work with typed languages most of the time, and I’m thoroughly convinced of their value, but acting like it is literally impossible to write a large project without types is just inaccurate.

          • By tossandthrow 2025-04-0113:572 reply

            No, you are right, it is possible.

            But it would be significantly more expensive.

            So I should probably preface and say that it is not possible within the budget I have (We are ~2 full time developing and maintaining everything on a 140k LOC platform spanning from infrastructure, backend, multiple frontends).

            • By tshaddox 2025-04-0115:23

              Yeah, it just means those teams had to do a lot of work themselves which type systems do automatically. Given that the entire point of computing is automating things which a human could have done by hand, it makes more sense to talk about cost rather than capability.

            • By Nijikokun 2025-04-0119:301 reply

              That feels more like you're being abused rather than a framework problem.

              • By tossandthrow 2025-04-0121:10

                We are not really over worked. Nobody puts in more than 30 hours, and we deliver the features the business need.

                However, we do have types and don't do type coercion. Types are sound full stack db -> backend -> frontends. We don't do any funky things. We don't use SSR (as the business does not require it). We test well, but not too much. We keep a sane architecture.

                We can also skip out on a lot of project shenanigans and mostly focus on our work.

                We don't (yet) use AI as a part of our workflows, and frankly, I don't see we can keep this way of working with the current gen AI.

          • By avinassh 2025-04-0117:152 reply

            > There are plenty of large projects written in Python.

            There are, but they are certainly a pain in the ass to work with.

            I once had to work on a semi-large Python codebase and got so frustrated that I wanted to port the code to some other language. The best part? I wrote the majority of that codebase myself, just months earlier.

            I ranted about it here: https://avi.im/blag/2023/refactoring-python/

            • By mplanchard 2025-04-0118:37

              Yeah I mean, I've worked on a multi-million-line Python 2 codebase. It wasn't easy, but it certainly wasn't impossible.

            • By ddejohn 2025-04-0118:091 reply

              Not sure why you're being downvoted -- large, legacy, untyped Python projects are a nightmare to work with.

              • By joquarky 2025-04-0216:41

                Just keep in mind there are a thousand people right behind you who would be ecstatic to be able to work on this "nightmare" in order to earn a paycheck.

          • By andai 2025-04-0113:28

            The only way it's possible is if you keep them in your head.

          • By david422 2025-04-0114:31

            > There are plenty of large projects written in Python

            I've worked on one of those, and I would not recommend it.

          • By hu3 2025-04-0216:19

            > There are plenty of large projects written in Python pre-typing, in PHP, etc.

            Just a nit. Modern PHP is typed and has been for years.

      • By isqueiros 2025-04-019:051 reply

        This seems incredibly shortsighted. If you're building an application by yourself you're gonna remember the relations and dependencies - but even on a small team (say ~4 devs) or even if you don't pick it up after a while, there is going to be stuff you forget.

        It's also nice when you move stuff around, you can rely on the LSP to rename and fix everything that breaks. If you have a simple website it's fine, but when you start to have multiple components... Losing typing is a huge deal.

        • By joquarky 2025-04-0216:43

          WebStorm and the like do a fine job inferring types, saving me a lot of time.

      • By ko27 2025-04-019:523 reply

        Having the author come out and say that being untyped is a feature, is definitely one way to kill of any potential interest for that framework.

        • By CharlieDigital 2025-04-0111:106 reply

          For the record, author is not crazy.

          Svelte team also switched to JS with JSDoc a few months back[0].

          You can see the majority of their repo is JS and not TS[1]

          The cited reason[2]:

              > As a Svelte compiler developer, debugging without a build step greatly simplifies compiler development. Previously, debugging was complicated by the fact that we had to debug using the build step. In addition, using JSDoc does not affect compiler’s development safety because the type is almost equivalent to TS.
          There was a lot of noise when this happened. Rich Harris (Svelte team) even had a comment on this on HN[3]. Dev sphere similarly thought they were crazy. But Svelte seems fine and no one seems bothered by this now.

          As long as author ships type def, it should behave just like a TypeScript library for all intents and purposes.

          [0] https://news.ycombinator.com/item?id=35932617

          [1] https://github.com/sveltejs/svelte

          [2] https://github.com/sveltejs/svelte/pull/8569

          [3] https://news.ycombinator.com/item?id=35892250

          • By unchar1 2025-04-0111:342 reply

            From the link [3] you posted,

            > If you're rabidly anti-TypeScript and think that us doing this vindicates your position, I'm about to disappoint you.

            Rich and the rest of the Svelte team are still using typscript, just through JSDoc + type definition files.

            In contrast the Nue team seems to want to keep the view layer untyped.

            From the parent comment

            > real static typing (like Rust or Go) shines in business logic where it counts

            it seems they don't consider typescript to be "real" static typing.

            • By CharlieDigital 2025-04-0111:425 reply

              TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.

                  function fn(x: string) {}
              Will happily accept:

                  fn(2)
              At runtime (and thus the need for schema validators like Zod, Valibot, et al because dev-land "static typing" is a façade)

                  > Rich and the rest of the Svelte team are still using typscript
              To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.

              Their codebase (as in the actual code they are writing) is undoubtedly JS[0] with `.d.ts` bindings for TypeScript[1]. Author can also do the same and provide TS bindings at any point in the future.

              [0] https://github.com/sveltejs/svelte/blob/main/packages/svelte...

              [1] https://github.com/sveltejs/svelte/blob/main/packages/svelte...

              • By tossandthrow 2025-04-0111:591 reply

                And this is definitely a problem.

                Had I had the opportunity to choose a language across the entire stack with mature wide adopted frameworks and libraries, I had done it.

                Had there been something line Rust, Go, Java, C#, etc. that would work end to end, that would have been amazing.

                In practice, even the weak safety typescript provides catches so many bugs before they hit production that it is indeed worth it - I have more than 140k LOCs of Typescript in production, and that would not be manageable without types.

                • By CharlieDigital 2025-04-0112:073 reply 

                      >  I have more than 140k LOCs of Typescript in production, and that would not be manageable without types
                  The Svelte team achieved it with JSDoc. Google's JS style guide also focuses on JSDoc for the same reasons[0].

                  And to be just a tad pedantic: you have JS in production; your TS is only in dev.

                      > Go, Java, C#, etc. that would work end to end, that would have been amazing.
                  It's not that you can't; it's that you choose not to (and yes, generally for good and valid reasons). There are end-to-end solutions for C# (e.g. Blazor), for example, that are perfectly fine depending on your use case (not great for all use cases). Fable is another example using F#[1]

                  There are also libraries like Bootsharp[2] that are doing interesting things, IMO, and has some of the same energy as OP's project (moving the typing and logic into a runtime that supports runtime static types and interfacing minimally with JS)

                  [0] https://google.github.io/styleguide/jsguide.html#jsdoc

                  [1] https://fable.io/docs/

                  [2] https://sharp.elringus.com/

                  • By tossandthrow 2025-04-0113:391 reply

                    > you have JS in production; your TS is only in dev.

                    As my sibling says, this is wrong. We indeed have TS in production.

                    Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.

                    The fact is that we don't write any JS as a part of our platform.

                    > It's not that you can't; it's that you choose not to

                    I think I made that quite clear in my comment.

                    > a language across the entire stack with mature wide adopted frameworks and libraries

                    • By CharlieDigital 2025-04-0114:102 reply 

                          > Even for the parts that are being compiled to JS: You wouldn't say: You can not have C++ in production, only binaries.
                      I would say that because it can be decompiled; the type information is still present. Same with C#. I can decompile the binary and still see the type information.

                      The process of going from TS to JS is lossy; you cannot get back the type information.

                      I would absolutely say "I have C++ in production" or "I have C# in production" but not say "I have TypeScript in production". "We build our app with TypeScript" is accurate, but it is transpiled -- not compiled -- into JavaScript. Your Node.js server then interprets that JavaScript and executes C++.

                      • By tossandthrow 2025-04-0114:391 reply

                        That is not right, When you compile to binaries, you do type erasure in CPP, som of the stuff can not be reconstructed or inferred, especially when using o flags.

                        JS -> TS is easy, you just re-anotate with `: any` everywhere.

                        Anyways, you are word juggling now.

                        • By Nijikokun 2025-04-0119:36

                          Type definitions are definitely compiled with CPP. Type erasure only happens with polymorphism types. You can actually view the types with ghidra.

                      • By unchar1 2025-04-0118:20

                        > Your Node.js server then interprets that JavaScript and executes C++.

                        Umm...no? V8 specifically compiles it into machine code directly.

                        There used to be a pseudo-translation layer in the CrankShaftScript days, but that hasn't been true in almost a decade.

                        > I can decompile the binary and still see the type information.

                        Also no. The de-compiler can _infer_ the types, much like how V8 tries to infer the type. But the actual type information is gone.

                        Even in languages like Java where most of the type information is preserved, some things are still lost (e.g. generic methods with dynamicinvoke)

                  • By gcau 2025-04-0113:19

                    >And to be just a tad pedantic: you have JS in production; your TS is only in dev.

                    This is not even pedantic, it's wrong. You have JS/TS in both dev and prod, with javascript being the actual runtime code in both, and typescript checking your code at build time in both. If you're running javascript compiled/checked by , and written in, typescript, it's not uncommon or unreasonable to call it typescript.

                  • By mubou 2025-04-024:07

                    > Google's JS style guide also focuses on JSDoc for the same reasons

                    Google uses TS internally. Any JS is strictly legacy code at this point. The link you posted even says this at the top:

                    > Please note: This guide is no longer being updated. Google recommends migrating to TypeScript, and following the TypeScript guide.

                    Also, Google's style guides are not really authoritative outside of Google. They are for some people, who choose to adopt them as their own, but you really shouldn't point to them as the end-all-be-all argument-stopper. Google has a lot of its own idiosyncrasies. Their C# style guide puts braces on the same line, for example, because Google primarily uses Java internally.

              • By unchar1 2025-04-0113:39

                > To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.

                Interesting that you say it's more about providing "bindings", and not really "using". Much of the types in the svelte codebase are never exported outside of svelte, and they are only consumed internally.

                The problem they were having was with transpilation, since the browser doesn't run JS.

                From Rich Harris (months after svelte switched to JSDoc) [1]:

                > removing types from your own code is clownish, epically misguided behaviour, but whatever — to each their own

                I would suggest going through the issues and PRs in the codebase to see how invested the Svelte team is in typescript.

                > TypeScript is not "real" static typing in the same sense as Go, Rust, C#.

                That is true for Go, Rust, C#. But the same thing is also true for languages like C, and Generics in Java. I'm sure both of those languages have weak type systems, but are definitely statically typed.

                I think the fact that type information is lost after being compiled isn't really a classifier for typed/non-typed. Ultimately it all comes down to machine code, and that certainly isn't typed either.

                [1]: https://x.com/Rich_Harris/status/1699490194565578882

              • By tshaddox 2025-04-0115:27

                Does Go’s type system perform runtime type validations? My impression was that it does not. But Go probably supports reflection on the type information at runtime which could be used to implement a runtime type validator, right?

              • By empw 2025-04-0119:07

                You can write a function in go or rust, then write code in assembly to call it with any old nonsense. It is no different. The whole point of static typing is that it happens at compile time, not runtime.

              • By MrJohz 2025-04-0122:00

                > TypeScript is not "real" static typing in the same sense as Go, Rust, C#; the type information disappears the moment you build it.

                The type information in both Rust and Go disappears the moment you build it. The generated assembly is completely untyped: if you pass invalid objects to a compiled Rust function that you've dynamically loaded, you will cause problems, even memory safety issues, because Rust does not do any type checks at runtime.

                In the same way, if you call Typescript-defined functions from Javascript with the wrong types, you'll get problems. But if you write everything in Javascript, and don't ever use type assertions, you won't have issues. (In practice, I believe there are a couple of other issues you can run into, typically involving variance and mutability, but these are very rare. Also, some older APIs return `any` that should return `unknown`, but that can be fixed.)

                It's also worth keeping in mind that all languages have and require schema validation, it just might look different. Both Rust and Go have schema validation libraries - typically they parse the data directly into the correct format, but in Rust you could do something like `let x: HashMap<String, JsonValue> = string.parse()` and get roughly the same effect as Javascript's JSON.parse, it's just that JS/TS has a built-in data structure to represent arbitrary JSON data, whereas Rust does not.

                > To be clear, they are not "using" TypeScript, it's more accurate to say they are providing TypeScript bindings.

                To be clearer: they are absolutely using Typescript. The functions (and other parts of the code) are annotated using Typescript's extension of JSDoc types, which means Typescript can parse and typecheck this code as if it were "normal" Typescript, including generating type definition files. The .d.ts files in the source code are used to define additional types and interfaces that can be used in the .js files (you can see the first file you linked to import type definitions from ESTree, for example). The type checking step can be seen in the package.json file[0]. This is all explained in the comment from Rich Harris that you linked before.

                Using JSDoc rather than conventional Typescript syntax makes writing your source code more complicated, but in this case the Svelte team figured it would benefit them more in the long run to still be writing code that could be interpreted by a normal Javascript runtime. However, it really is just a different syntax for Typescript, and that's how they are using it.

                [0]: https://github.com/sveltejs/svelte/blob/80557bbc1c8a94c43a95...

            • By mplanchard 2025-04-0112:253 reply

              It’s not real static typing. A compiled typescript project is just javascript, which will still gladly accept incorrect types. The types only matter during compilation.

              • By recursive 2025-04-0117:501 reply

                This is the real-est static typing that exists. "Static" refers to build time. By definition static types are checked at build time, not run time. If you want types to be checked at run time, that's called "dynamic" typing.

                • By mplanchard 2025-04-0118:433 reply

                  Sure, you're technically correct. But TS is compiled in to JS, which is dynamically typed at runtime. You're still ultimately in a dynamically typed language.

                  In addition, in a typical statically typed, compiled language, your only place where you interact with data that isn't guaranteed to be type-conformant is at a foreign function interface, whereas in Typescript all your interaction with third-party libraries is via regular JS and may or may not be type conformant.

                  • By throwaway894345 2025-04-0119:12

                    Rust compiles into WASM, x86, etc, which are dynamically typed for all intents and purposes. They certainly don't understand or enforce Rust's type system invariants any more than JavaScript enforces TypeScript invariants. If you call a Rust function from WASM and pass it malformed data, the WASM runtime will happily execute it.

                    (pretty sure WASM actually has some integer types, so I guess maybe it is technically "statically typed" but not in any interesting sense--we could similarly say that JavaScript is "statically typed" because every variable has a static "any" type).

                  • By recursive 2025-04-0119:08

                    Is there such a thing as a statically typed language? CPU opcodes don't type-check their parameters.

                  • By johnfn 2025-04-021:36

                    And Go/C/Rust compiles to ASM, a dynamically typed language at runtime.

              • By oynqr 2025-04-0118:29

                > The types only matter during compilation.

                That's pretty much the definition of static typing.

              • By throwaway894345 2025-04-0119:09

                You're confusing "real static typing" with runtime type information. TypeScript has "real static typing" (if you disagree, ponder for a moment the meaning of "static"). A TypeScript program cannot natively query the _TypeScript type_ (not to be confused with the corresponding JavaScript type) of one of its variables in the way, for example, Go can. But neither can C, or C++, or Rust, all of which are unquestioningly statically typed.

          • By tshaddox 2025-04-0115:252 reply

            Svelte is a bad example. They have roughly identical type checking before and after that switch. The switch is mostly just an aesthetic preference for one syntax over another and an ideological stance about being able to run code directly in a browser without a build step.

            • By CharlieDigital 2025-04-0115:263 reply

              It's not an "aesthetic preference"; it's a functional preference for debugging and iteration speed as cited by the team.

              • By tshaddox 2025-04-0115:39

                Fair enough. Perhaps what I mean is that they don’t have a strong aesthetic opposition to JSDoc, which is presumably rare among TypeScript developers.

              • By joquarky 2025-04-0216:51

                This is why I prefer to stick with JS and JSDoc.

                I have been doing pro webdev since 1995 and since I got my initial experience without all of the contemporary tooling, my process has evolved to require very rapid iteration: the delay of a compile step can often break my concentration and prevent a flow state.

              • By nsonha 2025-04-0123:50

            • By sureIy 2025-04-0116:24

              Which is quite hypocritical coming from a compiling framework and thus such a ridiculous stance.

              We hate build steps in our build step.

          • By troupo 2025-04-029:59

            > Svelte team also switched to JS with JSDoc a few months back

            1. They still use types via JS Doc

            2. They only switched to that for their internal development

            3. User-facing code has all the type support and TS support you'd expect

            > Rich Harris (Svelte team) even had a comment on this on HN[3].

            And here's literally what he said:

            --- start quote ---

            Firstly: we are not abandoning type safety or anything daft like that — we're just moving type declarations from .ts files to .js files with JSDoc annotations. As a user of Svelte, this won't affect your ability to use TypeScript with Svelte at all — functions exported from Svelte will still have all the same benefits of TypeScript that you're used to (typechecking, intellisense, inline documentation etc). Our commitment to TypeScript is stronger than ever

            --- end quote ---

            Compare that to Nue's author's take

          • By johnfn 2025-04-021:24

            Svelte uses JSDoc and has TS validate that. Nue uses nothing. This analogy makes no sense.

          • By chamomeal 2025-04-0117:31

            Svelte still exposes types though, right? Like as a svelte user, you wouldn’t know it was written in JS?

            I don’t use svelte, that’s just my understanding from when the TS -> JS switch was announced

          • By IshKebab 2025-04-0112:101 reply

            JS with JSDoc is basically just awkward Typescript.

            • By joquarky 2025-04-0219:10

              You're speaking as though it is a fact, but I think it depends on your coding style and temperament for iteration delays.

        • By tipiirai 2025-04-0114:363 reply

          Author coming out here: Types matter, and Nue’s take is to use them where they truly shine. Adding them to naturally untyped spots like HTML or CSS? That’s just extra weight we can skip.

          • By dimal 2025-04-0123:06

            I prefer types over tests everywhere. If I’m passing props to a component and I get a TypeScript error, that’s a test I didn’t need to write or run. I love finding errors like this at compile time instead of at runtime. Just because HTML and CSS are untyped by default doesn’t say anything about whether types are useful for them. Does Nue have any way to protect against those kinds of errors or does some other architectural decision obviate the need for this kind of protection?

            I’m not hating on Nue. At first glance, there’s a lot to like here, but I have to disagree on this point.

          • By tossandthrow 2025-04-0119:192 reply

            Neither HTML, nor CSS are naturally untyped.

            Actually, React is not typed enough.

            Looking at the mozilla docs: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/sp...

            You can see that eg. <span /> is not allowed to hold all types of elelemts.

            How awsome weould it be, if th type system actually captures this.

            • By zelphirkalt 2025-04-026:201 reply

              I guess many web developers would climb on a roof and throw stones, because then they really needed to learn HTML and using its elements semantically. And probably many of their web components would no longer type check either, forcing them to reimplement or use simpler elements.

              • By tossandthrow 2025-04-027:331 reply

                There was a time where front-end devs would have sat down and cried had they had to make closing tags.

                • By joquarky 2025-04-0219:21

                  Ever heard of XHTML?

                  There's a reason it's dead.

            • By tipiirai 2025-04-027:48

              This is a great idea!

          • By troupo 2025-04-0210:05

            Your views are not "naturally untyped spots like HTML or CSS". They are custom templates with custom syntax and logic. And they would definitely benefit from types.

        • By joquarky 2025-04-0216:43

          Some people like things that you might not like.

      • By spiffytech 2025-04-0112:491 reply

        Personally, I consider it a strike against a frontend framework if I can't type check my templates. They're entirely data-driven — exactly the kind of place where type checking is the least effort but still a a big help.

        In any nontrivial project, templates become a large fraction of my LOC, and it's already challenging to confirm they work right and don't break. Type checking that I'm passing in the data they expect, and that they're reading valid properties, is a cheap way to get a big win.

        Web standards are great, but I'm not sure what "heavy lifting" they do that would make me feel like type checking was unnecessary.

        • By mubou 2025-04-024:18

          I agree. It's far too easy to make a change to your model that removes/renames some property, but not update one template that you forgot uses it too. Without screendiff testing, that sort of bug will easily make it into prod.

          This is one of the reasons I like C#'s .cshtml (Razor) syntax. The entire file is compiled to C#, so when you do `<div>@Model.Foo</div>` the build will fail if Foo doesn't exist. String-based (rather than compiled) view templating is, IMO, a mistake.

      • By anentropic 2025-04-0110:07

        I am not on the React bandwagon, currently using HTMX

        But I would very much prefer to see TypeScript in a framework. Optional TS is ok but "untyped by design" feels like an anti-pattern, even HTMX has TS types available.

      • By mexicocitinluez 2025-04-0111:571 reply

        > React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill

        "We don't use Typescript because there are people that exist who use it for CSS when using React" is one hell of an argument that makes absolutely zero sense.

        • By ellinoora 2025-04-0115:281 reply

          Making zero sense of your own take of the argument makes absolutely zero sense

          • By mexicocitinluez 2025-04-0116:101 reply

            what?

            • By leptons 2025-04-0119:312 reply

              >"We don't use Typescript because there are people that exist who use it for CSS when using React"

              This not at all what was being conveyed, you made that up in your head. The OP didn't say they were not using Typescript because someone else used it for CSS, but that's what you seem to have written.

              • By mexicocitinluez 2025-04-0123:09

                > React’s ecosystem has devs slapping TypeScript on everything—even CSS—which is overkill

                It's actually EXACTLY what they're saying. They're using it as an example of why they don't use Typescript (ie people use React take it too far by using it for React). What does React that have anything to do with not using Typescript?

              • By vile_wretch 2025-04-0119:46

                I mean it's quite literally "we don't use typescript because some developers over-use it" which is essentially the same thing

      • By tshaddox 2025-04-0115:19

        I probably have nearly the exact opposite opinion of where static typing is the most beneficial. I think it’s precisely at the UI rendering layer, because that tends to be where you’re dealing with the data types with the largest number of properties, deep nesting, etc.

      • By littlecranky67 2025-04-0111:59

        I pretty much enjoy using MaterialUI with React (MUI) and have statically typed CSS: `<Stack sx={{ alignItems: "center"}}></Stack>` - I get full IntelliSense/autocompletion for the sx props (i.e. alignItems when typing 'al') and their value (i.e. 'center' when typing 'c') etc. Sx-props are composable, so you can centralize common used sx/css etc.

        Any typos or invalid props/value will result in a compiler error.

      • By herrherrmann 2025-04-0110:44

        I agree with most other commenters: Type safety is a great feature to have. And to intentionally dismiss it or only grant it to certain aspects of the application (where does business logic start and end anyway?) is a really bad sign for me.

      • By davedx 2025-04-0110:14

        I worked with react before typescript, react with flow, angular 1 (large projects), and these days I mostly use react with typescript.

        I don’t use it for css, but for the view components and code I find typescript actually makes me both faster and my code is more reliable. To me this is one of the killer features of react that other libraries are in various stages of catching up to: full static type checking end to end. (Also through the API to the backend with a little more work).

      • By arewethereyeta 2025-04-0111:33

        how can "not typed" be "by design" and presented to us as a feature. Your project looked interesting but your presentation here makes me have big doubts

      • By dalmo3 2025-04-019:12

        That's one way to find a niche audience.

      • By johnfn 2025-04-021:32

        Typed JSX is one of the handful of key innovations that made React successful, IMO. I think you need to really understand what you're replacing before you can replace it.

      • By troupo 2025-04-0112:411 reply

        Nothing in your view is "web standards". And nothing in web standards can do the heavy lifting of showing things like "`nam` is not defined on object `user`"

        • By joquarky 2025-04-0219:311 reply 

            if (!user || typeof user.nam !== 'string') {
    throw new Error("Missing or invalid 'nam' on user");
  }
          Contemporary JavaScript has optional chaining, default values, and reflective tools like Object.hasOwn, which are all web standards. You just have to know how to use them.

          • By troupo 2025-04-039:16

            You really don't understand what types give you, do you?

            Where are you going to put the code above in this:

              <section @name="user-details" class="user">

  <media :image="/app/icon/cc/{cc}.svg" :title="name">
    <p>{ email }</p>
  </media>

  <dl :if="org">
    <dt>Company</dt>      <dd>{ org }</dd>
    <dt>Country</dt>      <dd> { country }</dd>
    <dt>Company size</dt> <dd>{ size.desc } ({ size.label })</dd>
    <dt>Website</dt>      <dd><a class="action">{ website }</a></dd>
    <dt>Plan</dt>         <dd><pill icon="dot" :label="{ plan }"/></dd>
  </dl>

  <media-thumbs :items="shots"/>

  <chat-thread :thread="thread"/>
            </section>

            Are you going to write ifs for every permutation of possible typos? (Let's ignore for a second that it's not just typos)

      • By madeofpalk 2025-04-0111:59

        > slapping TypeScript on everything—even CSS—which is overkill

        Nope. Hard disagree. I want the developer experience of autocompletion of CSS variables, and I want build errors when someone makes a mistake.

        Type everything.

      • By turnsout 2025-04-0110:30

        At that point, why not just use vanilla JS and no framework? Literally zero build time and zero bytes of framework code. And it's fast as hell.

      • By Etheryte 2025-04-0114:44

        Frankly that's a good reason to never give Nue serious consideration. It's all fine when you're building small apps one view at a time. When you have an application with hundreds of views and you need to refactor, that's when you need the types, otherwise you'll never see the tail end of oh we missed that this needed to be renamed there too.

      • By mmkos 2025-04-019:401 reply

        I honestly can't see what's wrong with using TypeScript anywhere in place of JavaScript. Unless you're making a simple script or a throwaway prototype, then you're pretty much always better off with it. It's invaluable during development and it's compiled away at build time.

        • By joquarky 2025-04-0219:29

          I respect those who use and enjoy TS, but I have less respect for the argument that it should be used in place of JS everywhere.

          You’re replacing runtime trust with compile-time trust, but at the cost of flexibility and speed. That’s not always worth it.

          TypeScript solves problems I stopped having 20 years ago.

      • By jack_riminton 2025-04-019:42

        Uh oh, you've summoned the typesetters

      • By seivan 2025-04-018:57

        Jesus, this is a regression not a feature, for christ sake. Typed CSS via emotion/styled-components is an amazing feature to call it overkill. This alone is enough to dismiss nue.

      • By jeffhuys 2025-04-0115:111 reply

        Last time, I promise: please, PLEASE don't use ChatGPT (or others) on us. It's _extremely_ obvious, and it takes away 90% of your credibility. I'd much rather read a bit of broken English than read this kind of slop. It's a huge reason why I can't take this seriously.

        ALL your docs are chatgpt. All of them. All your issues. Your comments here. Are you even real? Yes? Then TALK to us.

        /rant.

        • By tipiirai 2025-04-0115:181 reply

          Please. It's me typing: Tero "tipiirai". I’m Finnish, not a bot. Documentation? Mostly me, some help from contributors. Comments here? Check my HN history. This stuff is impossible to prove.

          • By jeffhuys 2025-04-0115:34

            Of course it's impossible to prove, which is why so many people are doing it, like you/your team, at least recently. At some point in the past your blog seems to have gone from "real" to "slop".

            I've seen enough LLM sh*t to know.

            I know you'll never admit this. I don't care about that. But please understand that your credibility goes out of the window with this; it doesn't make it look more professional, especially to developers.

            If I'm extremely wrong here, I genuinely apologize, but I would be very, very surprised.

      • By barrell 2025-04-0114:31

        There’s a lot of negativity around this so I just thought I’d chip in and mention my appreciation for it. Projects are allowed to not be typescript, and I actively stay away from it as much as possible when working with browsers.

        I don’t work in TypeScript, I don’t write in typescript, and I (along with everyone) don’t deploy typescript. I have multiple different build processes in my project to remove different types from different dependencies that are incompatible with one another just to untype them.

        So personally I find standard js a huge selling point :)

    • By epolanski 2025-04-0110:282 reply

      > I guess this is targeting the vuejs crowd

      Vue is written in TS and has first-class support for it, even at the template layer.

      • By silverwind 2025-04-0216:26

        Vue with SFCs is not actually typescript because typescript can not parse the SFC syntax, you need a forked typescript called `vue-tsc` for that.

        Shows what a hack vue really is.

      • By IshKebab 2025-04-0112:091 reply

        Only since Vue 3 though, and the types are still not as good as React.

        • By epolanski 2025-04-0112:171 reply

          Vue 3 has 6 years at this point.

          Also, could you expand on the fact that types are "still not as good" as React?

          Can you make an example?

          • By IshKebab 2025-04-0114:101 reply

            Sadly not because it's been about 6 years since I looked at it! (We ended up switching to React.)

            IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.

            I'm sure I would find many more issues if I was using it in anger, because it's building on a foundation that didn't have Typescript in mind. E.g. see this thread:

            https://www.reddit.com/r/vuejs/comments/l456fl/is_vue_3_real...

            • By Timon3 2025-04-0114:361 reply

              > IIRC it's pretty close, but you'll still end up writing things like `{ type: String, required: false }` where in React you'd just write `string | undefined`.

              In Vue you also write `string | undefined` since Vue 3.

              Also note that the thread you linked is 4 years old.

              • By IshKebab 2025-04-0115:001 reply

                > In Vue you also write `string | undefined` since Vue 3.

                I took that example from the current official Vue 3 docs: https://vuejs.org/guide/typescript/overview#general-usage-no...

                > Also note that the thread you linked is 4 years old.

                So 2 years into Vue 3. Has anything changed?

                I mean it's not bad enough to be a dealbreaker any more like it was with Vue 2. The real dealbreaker is still the reactivity system which leads to spaghetti very quickly.

                • By Timon3 2025-04-0115:111 reply

                  > I took that example from the current official Vue 3 docs:

                  Yes, that API also exists as compatibility with the Options API, but this is what you should use:

                  https://vuejs.org/guide/typescript/composition-api.html#typi...

                  > So 2 years into Vue 3. Has anything changed?

                  Yes, e.g. templates are type-checked now. If you have specific things that aren't supposed to work, please list them.

                  > The real dealbreaker is still the reactivity system which leads to spaghetti very quickly.

                  I've had much better experiences with Vue than with React in this regard.

    • By dlisboa 2025-04-0115:161 reply

      > most react people now use TypeScript because first class types in your view layer are super useful

      Most people use TypeScript because React apps have grown to 200k lines of mostly entangled code with business logic and are unmanageable without it.

      If one goes in a different direction there's less need for it.

      • By cruffle_duffle 2025-04-0116:041 reply

        I mean a rapidly changing front end codebase is always going to be entangled mess no matter if it’s react, plain JavaScript or even “native app code”. Front ends are where the rubber meets the road and have to deal with fuzzy weird human shit and miles of edge cases. That is just the nature of the beast.

        Even if you attempt to tame it and make “the prefect codebase” it’s still gonna be a mess.

        If anything React and typescript help it from being an even larger mess full of homegrown idioms that are normally baked into the framework.

        There is no such thing as not using a framework. You either pick an existing one or build your own. Very often the sensible choice is to pick an existing one.

        • By dmix 2025-04-0123:04

          You could always massively reduce the frontend by not duplicating half the backend business logic in the browser. By not having isolated backend/frontend teams off in their own worlds and only using fancy JS where fancy JS is actually needed.

          Server rendering of JS only gets you partially in a better state when the fundamental idea is based around generating a massive amount of JS for the browser.

    • By bigjump 2025-04-018:38

      Most of the Vue devs I know, also use TypeScript for the same reasons.

    • By WuxiFingerHold 2025-04-0116:09

      > I guess this is targeting the vuejs crowd

      Typescript support and usage with Vue is very large. Vue itself is written in TS and most large libs are also written in TS. According to /r/vuejs and my personal experience also most new apps.

  • By wg0 2025-04-019:504 reply

    This is great. But I went for Svelte. Invested in Svelte and SvelteKit. Wrote a decent sized app (not toy example, pretty feature right, tens of forms and screens if you will) and later I looked back at React.

    And I discovered that:

      - React is not that hard if you understand the hooks.

  - React is lightweight too. For my use case at least.

  - React is boring technology at this point which is good.

  - The ecosystem is huge. You cannot have React Query like library and that's just one example.
    So I'm sticking to React for next few years especially when the React compiler is already being used inside Facebook and Instagram and released as public beta.

    Even React Native supports React compiler and I don't see this support going away rather getting better.

    PS Edit: React compiler leaves not much for runes in Svelte or its compiled nature. I don't like Svelte much after runes because it feels like you're not writing Javascript rather a notation that looks like Javascript. Post React compiler, much of the hooks hell is not needed in complex scenarios.

    • By brulard 2025-04-0110:501 reply

      TanStack Query (formerly known as React Query) is absolutely compatible with Svelte. https://tanstack.com/query/latest

      I work with react for a decade now, and with Svelte for past 3 years. Svelte is obviously a newer generation of framework, and works for me a lot better than React. But I agree there are some rough edges, mostly around the ecosystem

      • By wg0 2025-04-0117:08

        No, the support is quit limited not as many features are supported.

    • By pier25 2025-04-0115:06

      Svelte is definitely much less verbose and requires less code. Performance is also way better but it might not matter for many use cases.

      The drawback is that since Svelte is really a language[1] you now need a compiler and custom dev tools to make it all work. This requires some serious effort to maintain and evolve.

      I love Svelte and have been using it almost daily for years... but the team really needs more resources to accomplish their vision and maintain it for the foreseeable future. It's amazing that huge companies like Apple are adopting Svelte (eg: Apple Music) and not investing in it.

      [1] https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c321...

    • By iammrpayments 2025-04-0111:17

      I transitioned to svelte and I’m finding it around 3x to 2x times less complex than React

    • By newswangerd 2025-04-0116:352 reply

      I learned React back in the class component days. I recently picked it back up and found functional components and hooks to be absolutely baffling. Does anyone know why they went down this route?

      • By wg0 2025-04-0117:05

        Trust me, the function based components are way too simpler. Just a function that returns HTML. That's it. compose your UI as those functions. These functions can take arguments to customise their output (rendered HTML) as arguments (called props) or can call special functions from React (called hooks) such as asking the React to "remember" a value for you (state) or cache something for you (useMemo) so as to not compute it every time or trigger rendering if value of certain variables change (useEffect) or at the component start (useEffect with no dependencies mentioned) and that's all the React that you need to know for I would say your 95% of the needs.

        React compiler (already used for Facebook and Instragram code base) further renders the use of certain hooks unncessary thus making React a lot more simpler.

      • By jfcisco 2025-04-0116:44

        Hooks require less boilerplate to set up and reuse stateful logic across components

        If you havent watched it yet, the talk that introduced hooks explains much better than I can: https://youtu.be/dpw9EHDh2bM

HackerNews

About