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.

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.

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.

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.)

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.

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.

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.

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.

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

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

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.

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..

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

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

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

We didn’t do lazy loading or caching either.

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.

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

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

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

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.

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.

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.

(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)

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.

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.

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.

More abstraction != easier to use.

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)

- 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.

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.

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

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.

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.

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.

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

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.

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.

  if (!user || typeof user.nam !== 'string') {
    throw new Error("Missing or invalid 'nam' on user");
  }

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

Can you make an example?

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.

I really dislike how all the other JS UI libraries are basically the same and espouse the same ideas.

Svelte was way better when Rich Harris was straight up attacking react devs at conferences and shaming them for poor performance.

Being "nice" just ensures entrenched players stay entrenched.

I think most people get uncomfortable because it's often untrue in marketing. So if it's true (to the best of your knowledge and after outside probing) then by all means.

https://en.wikipedia.org/wiki/Conway%27s_law

The law is based on the reasoning that in order for a product to function, the authors and designers of its component parts must communicate with each other in order to ensure compatibility between the components. Therefore, the technical structure of a system will reflect the social boundaries of the organizations that produced it, across which communication is more difficult. In colloquial terms, it means complex products end up "shaped like" the organizational structure they are designed in or designed for. The law is applied primarily in the field of software architecture, though Conway directed it more broadly and its assumptions and conclusions apply to most technical fields.

(Strictly speaking you can have a web service that's purely about spitting out raw data in a form that other organizations can use, but that's the kind of thing that Semantic Web and Linked Data standards are intended to address. Not something that your garden-variety website has to be concerned with.)

What react does do is give you a clean separation of concerns across team boundaries and allow for reusable components . But the cost you pay for that is a boat load of overhead, complexity, maintainability concerns, and react specific edge cases

That said, how does Nue compare to, say, Svelte?

For having built what is essentially a bundler, I would've guessed you were more familiar with what it does, or, perhaps even have used it to build your tool.

Vite can bundle framework-less html files. It can create an SPA without any JS faff. You just have to point it to the right direction. When you instantiate a Vite app, you have to make the conscious decision to use React under the hood.

As for Nue, I think it's a cool idea, but I don't see what it does that I couldn't do with Astro, which has way larger community support and can work with pretty much all JS frameworks OOB.

BTW, I think it's really disingenuous to compare a React SPA bundle with an SSG output. You have essentially no functionality for handling state mutations beside events. You could achieve a much better middle ground by using a compiled framework like Svelte or Solid.

It's still a neat toolkit, since not every website needs a big framework - but comparing runtime sizes is like choosing C over C++ because a `int main() { printf("Hello World\n"); }` binary is smaller.

https://www.grammarly.com/blog/vocabulary/moot-point/

IMO, those who have only worked in React tend to be unfamiliar with the layers of native capability that React is built upon, and so they are stuck in the React bubble unless they want to learn a ton of (admittedly crufty, but useful) web fundamentals.

> Built with Vite, TypeScript, Tailwind, and Shadcn/UI, following the official ShadCN/Vite documentation exactly — no additions or removals.

Would be interesting to run Webpack Bundle Analyser [1] (or similar for vite bundler) to see if the proposed stack in the doc is bloated by some major dependencies.

0 https://nuejs.org/docs/react-button-vs-nue.html

1 https://www.npmjs.com/package/webpack-bundle-analyzer

Edit : seems the question I was responding for was a rhetoric question posted by the author. I guess the « smaller that a button » is a smart catchphrase but I wouldn’t use it for too long as soon a Nue becomes popular. Great work, I wish you much success and hope to use it in day to day work some time soon !

I'm sorry if it does, then I'll take my accusation back, but I've seen this happen in almost all of your Nue submissions. People keep bringing up this criticism, and you never retract your misleading comparisons.

This works, plain JS 150k rows

    <style>
        #viewport {
            height: 600px;
            overflow-y: scroll;
            position: relative;
            border: 1px solid #ccc;
            width: 400px;
            margin: auto;
        }

        .item {
            position: absolute;
            left: 0;
            right: 0;
            height: 30px;
            padding: 5px;
            box-sizing: border-box;
            border-bottom: 1px solid #eee;
            font-family: Arial, sans-serif;
        }
    </style>

    <div id="viewport">
        <div id="content"></div>
    </div>


    <script>
        const viewport = document.getElementById('viewport');
        const content = document.getElementById('content');
        const itemHeight = 30;
        const totalItems = 150000;

        const items = Array.from({length: totalItems}, (_, i) => ({
            id: i + 1,
            name: `User #${i + 1}`
        }));

        content.style.height = `${totalItems * itemHeight}px`;

        function render() {
            const scrollTop = viewport.scrollTop;
            const viewportHeight = viewport.clientHeight;
            const start = Math.floor(scrollTop / itemHeight);
            const end = Math.min(totalItems, start + Math.ceil(viewportHeight / itemHeight) + 10);

            content.innerHTML = '';

            for (let i = start; i < end; i++) {
                const div = document.createElement('div');
                div.className = 'item';
                div.style.top = `${i * itemHeight}px`;
                div.textContent = items[i].name;
                content.appendChild(div);
            }
        }

        viewport.addEventListener('scroll', render);
        render();
    </script>

https://github.com/nuejs/nue/blob/master/packages/examples/s...

There is currently no demo about the crash, but you can setup this locally.