[HN Gopher] Show HN: Nue - Apps lighter than a React button
___________________________________________________________________
Show HN: Nue - Apps lighter than a React button
Author : tipiirai
Score : 661 points
Date : 2025-04-01 05:47 UTC (17 hours ago)
(HTM) web link (nuejs.org)
(TXT) w3m dump (nuejs.org)
| tipiirai wrote:
| Nue's a web framework I'm building to slice through modern web
| dev bloat. When a Vite/ShadCN/Tailwind button is 40% heavier than
| a full-blown SPA, it's time to do things differently. We're
| retooling from the ground up--web standards first, no bloat. It's
| for frontend architects, design engineers, and UX folks craving
| simpler, saner workflows. Still in progress, but the shift's
| coming. Curious to hear your thoughts!
| whatever1 wrote:
| How is Vite relevant to the discussion? It's like saying the UI
| based on Visual Studio is lighter.
| tipiirai wrote:
| Because Vite emphasizes "Optimized build" in their marketing
| notpushkin wrote:
| Slower builds might make developers more thoughtful of the
| bloat, but I still think it's tangential.
|
| That said, how does Nue compare to, say, Svelte?
| isqueiros wrote:
| I'm not sure if I got this correctly, but it seems like
| you're misunderstanding what Vite actually is or does.
|
| 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.
| n2d4 wrote:
| What do you mean by "lighter than a React button"? Do you mean
| lighter than the entire React runtime, plus a React button?
|
| If so, that's somewhat disingenuous because even though a page
| with a single button would require the entire runtime, a second
| React button would be significantly cheaper than that.
| tipiirai wrote:
| Yes. React runtime included. Benchmark and details here:
| https://nuejs.org/docs/react-button-vs-nue.html
| Fulgen wrote:
| As the previous commenter said - you don't need a new
| runtime instance per button, so the comparison doesn't
| really work (for the smallest binary size, you could
| provide a native application doing the bare minimum to
| display the UI too, if the platform has an OS-provided UI
| framework).
|
| 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.
| audunw wrote:
| I think it's relevant in the sense that it shows if
| you're building a simple app, there's a lot of overhead.
|
| It doesn't claim that you're going to get that overhead
| for every time you instance a button. I don't see how
| anyone would think that.
|
| I think the comparison works fairly well. It should be
| clear to everyone that it compares apples and oranges,
| since it's two different kind of apps it's comparing. So
| it makes you think. If they just compared the size of the
| framework itself, or a single button vs a single button,
| you may think "oh but as soon as you add any kind of
| complicated code, there will probably be so much
| boilerplate with Nue that it'll end up being bigger"..
| muspimerol wrote:
| This comparison is disingenuous and off-putting. When I
| read "a React button" I assume you are talking about
| `<button>` and the React runtime, not some third party
| libraries.
| JodieBenitez wrote:
| At this point I don't even understand why everything has to be
| a SPA. It's complicated and inefficient and should probably be
| only used with highly interactive applications like some kind
| of Photoshop or Ableton live for the web, which means very few
| apps should use this paradigm. Granted, I'm not much of a
| frontend dev... but what I know is that if "instant search and
| other operations over 150,000 records" is a problem then it's
| probably best to re-think the paradigm.
| n2d4 wrote:
| SPAs are great for the hordes of B2B SaaS apps out there,
| which for the most part are just some fancy variants of a
| table. They're not a Photoshop, but they're still highly
| interactive.
| jack_riminton wrote:
| I think the exact opposite is true, B2B SaaS apps don't
| need to be an SPA to deal with fancy variants of a table.
| You can create highly interactive UI with things like Rails
| and Hotwire, sprinkles of JS or even HTMX. SPA's are bloat
| and often driven by designers who focus on flashiness
| rather than good UX.
| n2d4 wrote:
| Even if you use Rails or HTMX to get it done, you're
| still building an SPA.
| jack_riminton wrote:
| Couldn't be more wrong
| tipiirai wrote:
| If you look at the documentation at nuejs.org/docs, you'll
| see how Nue is really more about apps that focus on content
| rather than single-page apps (SPAs). However, this release is
| all about SPAs.
| JodieBenitez wrote:
| Yes, sorry for venting on your thread. I do appreciate the
| idea of leveraging web standards though.
| DecoySalamander wrote:
| With SPA, all your backend has to do is spit out data and
| sometimes validate it, leaving your front-end completely in
| charge of presentation and user interaction. You can even
| have completely separate teams working on it. It feels a lot
| less complicated than the alternative.
| JodieBenitez wrote:
| That's a debate spanning multiple decades. Your last
| sentence is not true all the time.
| Sammi wrote:
| Yes Conway's Law:
|
| 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.
| pier25 wrote:
| OTOH you now need an API and glue code in the frontend. I'm
| not saying it's not worth it but it's definitely more work.
| zozbot234 wrote:
| That "backend" vs. "frontend" split is entirely artificial.
| That code you would run server-side to convert your data
| into a fully-rendered page is still very much part of your
| "frontend" organizationally, even though it might be hosted
| on the server.
|
| (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.)
| furstenheim wrote:
| Not the discussion, but SPAs are fundamentally safer against
| XSS, in the sense that data and code have different paths.
| Cthulhu_ wrote:
| There's a crossover with crossplatform apps (like React
| Native), which is a force multiplier for some applications /
| orgs / etc.
| neals wrote:
| Both way can work fine, enough great examples out there. The
| real problem is, imho, we shouldn't need a (graphical) UI at
| all. That's where all this discussion comes from. When the
| whole "frontend" disappears in a year or 10, it will make a
| lot more sense.
| bodantogat wrote:
| This happened to a team I know. They built a flashy SPA
| dashboard because it was easy to copy-paste from templates.
| It worked great--until a real-world requirement, like a data
| grid, came along.
| WuxiFingerHold wrote:
| I recently thought about just using ASP.NET MVC with Razor
| pages for a quite simple app at work. But I'm already
| familiar with SPAs, so with that background I chose to "just
| use Vue as always (or Solid or Svelte, I like all three of
| them)" as SPAs have some advantages, e.g. separation of
| concerns, easier integration of libs like agGrid or eCharts.
|
| Without that knowledge, I agree that good old SSR (MPA) is
| easier and more maintainable. And more robust.
| Cthulhu_ wrote:
| I don't think the "a button in X is 40% heavier than an SPA" is
| a fair comparison; including a framework will add weight, but
| these frameworks are not intended for single components.
| Compare apples to apples, then we can make a fair comparison.
|
| That said, how does Nue compare to htmx and other frameworks
| leveraging the modern web standards?
| t-writescode wrote:
| - htmx = 14k as min.gz - solidjs = 7kb as min.gz
|
| htmx for "easy" html, solid for reactivity. Don't know how
| much more Nue provides; but, there you go for numbers.
| MartijnHols wrote:
| There is no such things as a true apples to apples comparison
| for libraries such as this. They all cherry pick something
| and ignore a ton of things such as: -
| accessibility - amount of libraries with plug-and-play
| solutions to common problems - security -
| scalability - rendering performance -
| maintainability - browser support - browser
| extension interference - hundreds of other niche edge-
| cases that someone will eventually run into but are non-
| obvious until it's widely used
|
| React is really well-thought out and well made by hundreds of
| professional contributors that have worked on it for years.
| The premise that hobbyists can make a better overall solution
| in less than 8 months is strange. At best they can make a
| smaller solution, but it will have to sacrifice in other
| areas.
| maccard wrote:
| React and the react ecosystem fail at many of the criteria
| you've listed. You might argue "that's not reacts fault"
| but when I look at a website that takes 15+ seconds to load
| its content on a gigabit connection , I'm never surprised
| when it's react. Lots of sites have massive issues with
| rendering performance, scalability and maintainability even
| with react.
|
| 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
| MartijnHols wrote:
| A 15+ second load on a gigabit connection is impossible
| to have anything to do with the React library, as React
| is only kilobytes big and has no impact on the host.
| maccard wrote:
| > You might argue "that's not reacts fault" but when I
| look at a website that takes 15+ seconds to load its
| content on a gigabit connection , I'm never surprised
| when it's react.
|
| > A 15+ second load on a gigabit connection is impossible
| to have anything to do with the React library, as React
| is only kilobytes big and has no impact on the host.
|
| Perfectly proving my point.
|
| It's not react-the-framework's fault, yet those sites are
| always react sites.
| pier25 wrote:
| So what stack are you using with React?
| arewethereyeta wrote:
| flawed example for a framework. Tell me...are 2 buttons going
| to be 80% heavier? why use react if all you build is a button?
| you need a tractor to pick your groceries from store?
| klysm wrote:
| Incredible marketing blurb! Not a single bit of detail about
| how this works
| pier25 wrote:
| Nue is a very cool project but if you want people to take the
| project seriously you should probably tone down your
| confrontational marketing :)
|
| Also, I checked the demo and there's like 100kB of WASM code
| you're not taking into consideration in that React button
| comparison?
|
| Anyway, congrats on the project. I'm really curious to see how
| the whole vision will turn out.
| kigiri wrote:
| 100% agree, I felt very put off by the tone, I think HTMX
| pull it off by not taking itself too seriously and also
| having good insights.
|
| I wish the homepage talked more about how nue approach the
| problems rather than how better than other framework it is.
| tipiirai wrote:
| I think you're right on the marketing. I'll tone down.
|
| The comparison uses the non-wasm version at mpa.nuejs.org
| azemetre wrote:
| If you want an alternative view, I like the confrontational
| tone. You know what you excel at and attack your
| competitors with it.
|
| 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.
| pier25 wrote:
| I wrote "tone down" not "completely remove" ;)
|
| Rich and HTMX have a much different tone while shaming
| React.
| tipiirai wrote:
| Not an April fool's joke btw!
| futhey wrote:
| I thought it was an April fools joke, glad I'm not the only
| one.
| mirzap wrote:
| > 150,000 records -- far past where JavaScript (and React) would
| crash with a stack overflow error
|
| I think react-virtualized and stack tables can easily handle 1
| million rows client-side without a problem (I saw the demo
| somewhere).
|
| Web development is about convenience, and the speed of
| development is far more important than ultra optimizations.
| People simply don't care about super optimizations because
| servers are so fast these days, and bandwidth is cheap, almost
| free.
|
| But it's an interesting project. Good luck.
| tipiirai wrote:
| This exact demo will crash with vanilla JavaScript (in Chrome
| 134.0). This React would also crash -- unless the computation
| relies on WASM
| Farseer_ wrote:
| Could you give a code example? Also, by crash, do you mean
| the mentioned stack overflow error?
|
| If so, why would the stack be involved when talking element
| count?
| tipiirai wrote:
| The exact error is "Maximum call stack size exceeded" when
| the WASM- engine is replaced with this JS engine:
|
| https://github.com/nuejs/nue/blob/master/packages/examples/
| s...
|
| There is currently no demo about the crash, but you can
| setup this locally.
| uasi wrote:
| `events.push(...arr)` puts all arguments on the call
| stack before calling the method, which causes the error.
| Don't push tens of thousands of items at once.
| tipiirai wrote:
| If you're architecture is based on event sourcing, this
| is kind of the point
| uasi wrote:
| What do you mean?
| mirzap wrote:
| It has nothing to do with architecture, but rather
| understanding how the DOM works. The DOM is notoriously
| slow, so you should never render a huge number of rows at
| once. You can render millions of rows in plain JavaScript
| without impacting performance.
|
| Here, I have recreated your JS example with searching and
| filtering and it does not crash. It's trivial to reuse a
| similar approach with the real backend and real events
| from the event source.
|
| https://htmlpreview.github.io/?https://gist.githubusercon
| ten...
|
| *Update: Here is 1 million rows table with search,
| filtering and pagination. In plain Javascript:
|
| https://htmlpreview.github.io/?https://gist.githubusercon
| ten...
| SkiFire13 wrote:
| The point should not be using the spread operator at all
| costs. There are other ways in javascript to push
| multiple elements in an array that are more efficient
| than the spread operator.
|
| The fact you didn't even stop to wonder why the error was
| a stack overflow when you weren't using recursive
| functions is also telling.
| jeffhuys wrote:
| You're solving a problem nobody has. If you encounter
| this problem, you shouldn't think "ah, let's yeet the JS
| engine because it clearly isn't good enough for my
| awesome SPA", you should think "hm, maybe I shouldn't
| render 10000000000 records in the DOM".
|
| What's next? "Oh I have a memory leak, let's get a
| subscription on RAM modules and just keep adding them!"
| mirzap wrote:
| Because he constructs a giant JSON by joining individual
| entries. Rendering that directly on the DOM will always
| cause the performance issues (even at the 10k entries).
| That's why you need to use virtualized list, it can be done
| in plain JS or using libraries like react-virtualized.
|
| 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>
| wordofx wrote:
| No. Back when supporting ie 9 we had tables with a million
| rows and dozens of columns and it runs fine.
| mirzap wrote:
| Make a demo with react-virtualized[0] and see if it crashes.
| Hint: It will not[1]. React can easily render 1 million rows
| with high performance without relying on WASM [2]
|
| Here is the demo of react-virtualized[3], in which I entered
| 10m as the row count and scrolled to the bottom without
| crashing.
|
| [0] https://github.com/bvaughn/react-virtualized
|
| [1] https://www.youtube.com/watch?v=1JoEuJQIJbs
|
| [2] https://medium.com/@priyankadaida/how-to-render-a-
| million-ro...
|
| [3] https://bvaughn.github.io/react-
| virtualized/#/components/Lis...
|
| *Update: Here I made a table with 1 million rows with search,
| filtering, and pagination. In plain Javascript:
|
| https://htmlpreview.github.io/?https://gist.githubuserconten.
| ..
| ykonstant wrote:
| >People simply don't care about super optimizations because
| servers are so fast these days, and bandwidth is cheap, almost
| free.
|
| Sigh.
| tipiirai wrote:
| > People simply don't care about super optimizations
|
| Could be, but some optimizations in Nue really stand out. Check
| out bundle size, HMR speed, build speed, and especially
| repository size. An empty Next.js project weighs over 300MB, a
| Vite button is around 150MB, while a Nue SPA clocks in at just
| 2MB.
| Timon3 wrote:
| I would love to check out the bundle size! Will you ever
| create a fair comparison, where your Nue implementation has
| all the same features as the versions you compare it to? All
| the comparisons I've seen so far are deceitful since they
| implement much less. If Nue actually produces smaller
| bundles, why not create an actually fair comparison?
| jeffhuys wrote:
| A Vite button? You mean Vue? Vite is just a bundler lol.
|
| Also, would like to see some comparisons to Preact, as that's
| an (almost) drop-in replacement for React with SUPER small
| bundles. I'd be impressed if you manage to beat that.
| wordofx wrote:
| The animation makes it look so incredibly slow...
| tipiirai wrote:
| Which animation exactly?
| codelord wrote:
| Fade in/out animation.
| wordofx wrote:
| The videos. The very first video. Animations like this are
| done to hide the fact it's slow by hiding it behind a fancy
| animation. Used to do this when we were stuck on 3g
| connections...
| morganherlocker wrote:
| All of them? It should feel instant. A UI does not benefit
| from artificial delays.
| tipiirai wrote:
| Gotcha. This is something Nue will tackle later trough
| design systems, where motion design is an option to choose,
| ditch, or tweak.
| sandebert wrote:
| Yeah, they should remove all animations so it feels instant and
| really snappy instead.
| jbverschoor wrote:
| Disable the "appears" class in chrome inspector, and it's all
| instant. (faster than the macos mail.app)
| mary-ext wrote:
| The animations makes it feel slow, the lack of any
| throttling/debouncing means that my input feels slow too.
| tipiirai wrote:
| Are you talking about this 150,000 record Rust version?
|
| https://mpa.nuejs.org/app/?rust
| akx wrote:
| Yes. On that version, Chrome 134.0.6998.89's devtools on my
| Macbook (M2 Max) are indicating 100 to 250 millisecond
| interaction times and a 160 ms frame when entering text into
| the search field.
| tipiirai wrote:
| I get the same numbers. Interestingly, JavaScript performs
| faster below 100,000 entries due to the lack of a JS-to-
| WASM bridge, but it eventually crashes when the records
| keep increasing
| dimgl wrote:
| Why would you ever have 100,000 entities on a page? What
| is the business use case for this?
| petetnt wrote:
| Loading the page on Fast 4G connection takes 9,61 seconds
| before I see _any_ content on the screen. This is loading the
| "all contacts" page that shows 12 items with a title,
| excerpt, time stamp and user name. Is this expected
| performance? Network shows the app downloading huge 4/1
| megabyte chunks.
| hexo wrote:
| The animations are always a deal breaker. And then WASM.
| m00dy wrote:
| why would 150,000 records break React and throw overflow
| exception ?
| tipiirai wrote:
| Because that demo crashes with vanilla JavaScript at around
| 110,000 records
| m00dy wrote:
| it doesn't make sense.
| muspimerol wrote:
| Here's the react-table example app with 112,500 records, just
| like your example. I am not really seeing much of a
| performance difference (and this is in dev mode - it would be
| faster if built for production):
|
| https://n9vr4n-5173.csb.app/
| leonhard wrote:
| I really like the approach but the demo [0] doesn't really work
| on iOS Safari (although might be my outdated 16.7.8 version).
| Scrolling doesn't work, the layout and buttons have weird line
| breaks, the native search button is embedded in the custom
| designed one, leading to 2 icons...
|
| [0] https://mpa.nuejs.org/app/
| Timon3 wrote:
| The author is using a trick they've used in almost every past
| submission: They implement much less than the component they
| compare themselves to, and then show how much smaller their own
| solution is.
| tipiirai wrote:
| How is the SPA less than the button?
| Timon3 wrote:
| Does your button component implement _all_ the
| functionality included in the Vite /shadcn bundle? E.g. the
| different variants, states, loading etc.?
|
| 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.
| tipiirai wrote:
| The Nue button demo isn't claiming to replicate every
| feature of the Vite/ShadCN bundle--no variants, states,
| or loading spinners here, just a lean example to show
| size and simplicity. The point's not to 'beat' ShadCN at
| its own game but to highlight how web standards can cut
| bloat dramatically, like a button smaller than a full
| SPA. I get the criticism--comparisons can feel loaded--
| but it's less about misleading and more about
| spotlighting a different approach. Happy to tweak the
| framing if it's coming off wrong.
| Timon3 wrote:
| > The point's not to 'beat' ShadCN at its own game but to
| highlight how web standards can cut bloat dramatically,
| like a button smaller than a full SPA.
|
| Then why isn't there any disclaimer or explanation that
| your Nue button has fewer features than the one you
| compare it to? You clearly intend for the reader to make
| this comparison, but you deceive them by not mentioning
| that your solution _isn 't equivalent_.
|
| > Happy to tweak the framing if it's coming off wrong.
|
| It would be great if you could do that! Though I'm not
| holding my breath - you've done this many times before,
| people have complained many times before, and you keep
| doing it.
|
| I know I'm just one voice, but your marketing strategy is
| so deliberately deceitful that I'll honestly never
| consider Nue as a serious contender for any project, nor
| other software you write, until you stop doing this.
| albedoa wrote:
| Let's try this a different way: What would it take for
| you to retract your misleading comparisons?
|
| You keep acknowledging and then repeating the deceit. You
| even solicit ways to stop being deceitful only to reject
| the many suggestions.
|
| > Happy to tweak the framing if it's coming off wrong.
|
| It's coming off wrong (because it is wrong). So go ahead,
| your move.
| aziaziazi wrote:
| It's not the button that's big but the stack [0]
|
| > 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 !
| aziaziazi wrote:
| Scrolling works now on iOS safari! That was a quick fix. Thanks
| to the author (and bug reporter!)
| jeffhuys wrote:
| Now do macOS Safari......
| jampekka wrote:
| Page height/vertical scrolling is also broken in both Chrome
| and Firefox on Android. On FF the comment box gets hidden under
| the menu bar.
|
| Probably the page height gets forced with percentage or vh,
| which should be usually avoided. If forcing is wanted, svh or
| dvh should be used.
| handfuloflight wrote:
| Would you be able to hook this up to https://www.convex.dev/?
| n2d4 wrote:
| Are there any code examples? I've looked for a bit but haven't
| found any. That should IMO be the first thing on any blog post
| about new frameworks.
| tipiirai wrote:
| There are currently two examples:
|
| - `nue create simple-blog` This highlights content-driven
| websites.
|
| - `nue create simple-mpa` This is today's SPA demo, where 'MPA'
| stands for multi-page applications. It shows how client-side
| routing and view transitions can seamlessly connect content-
| heavy pages with app-like views.
|
| Source code here:
|
| https://github.com/nuejs/nue/tree/master/packages/examples
| noodletheworld wrote:
| Is there any documentation about them?
|
| For example what is this 200kb binary for?
|
| https://github.com/nuejs/nue/blob/master/packages/examples/s.
| ..
| jeffhuys wrote:
| Here's the source, I believe: https://github.com/nuejs/nue/
| blob/master/packages/examples/s...
| brundolf wrote:
| I also spent five minutes clicking around and couldn't find a
| sample of what the code looks like
| farzd wrote:
| love the demo and overall reason for this, hope it gets the
| following and support it deserves!
| zol wrote:
| Today it's Nue. Tomorrow it'll be Olde and we'll complain about
| all the boilerplate or repetitive update logic we now have to
| write.
| tipiirai wrote:
| Fair point--new tools pop up constantly, often just piling more
| layers on React's bloated stack. Nue's not that. It's a fresh
| start, built on web standards and closer to the metal, not
| another abstraction treadmill. That's why a button can be
| lighter than a whole app--less cruft, not more boilerplate.
| Tomorrow's Olde might still fight yesterday's bloat; Nue's
| dodging that trap from day one
| Garlef wrote:
| Looks interesting!
|
| Regarding the code examples in the docs:
|
| It would be great if the examples for models and views would be
| from the same example.
|
| Currently, the view example is something about users and the
| model is something about customers?
|
| The interesting part for me is not how the individual components
| of the architecture work but how they connect...
| tipiirai wrote:
| They are from the same example. Here's the source code:
|
| https://github.com/nuejs/nue/tree/master/packages/examples/s...
|
| Look for "view" and "model" folders
| mentalgear wrote:
| Congrats, Nue seems to be an impressive and well-thought-out
| design system & framework. It feels like a strong candidate to
| become the "Web Standards Stack" --finally freeing developers
| from the complexity and bloat of modern frontend tooling.
|
| I've been following Nue for a while now, and I'm eager to use it
| for real world apps. Any updates on when the design system will
| be released? I know you're ambitious, but I'd suggest launching a
| single design system first to test the waters, gather feedback,
| and gain traction -- rather than waiting to release everything at
| once (but losing out to the ecosystem).
| tipiirai wrote:
| I'm eager to dive into the design systems, definitely coming.
| But first, I wanted this release to prove Nue isn't just for
| 'hobby projects,' a label plain website generators often get
| stuck with. This SPA demo was key--showing how working closer
| to web standards really shines for complex apps, not just
| simple sites.
| throwaway290 wrote:
| 1. It's an SSG and competes with projects like Astro or Solid or
| Next. Comparing to React is apples to oranges.
|
| 2. Benchmarks are just numbers without details. React+ReacDOM
| gzipped/minified is 40 kb in 2025. I doubt a button adds 30 kb.
| But if you really want to make small SPAs, Preact is just 4 kb
| and it doesn't require to learn a new bespoke templating DHTML-
| style thing.
|
| 3. From FAQ
|
| > The WebAssembly example in our demo isn't about raw performance
| -- it demonstrates something far more important: what becomes
| possible when your business logic is properly separated from
| presentation.
|
| > But when your business logic lives in its own pure layer,
| entirely new possibilities emerge. Rust is just one example --
| you could model complex financial calculations, build
| sophisticated data visualization engines, or create real-time
| collaboration systems. Your logic can evolve independently of the
| interface, enabling the kind of architectural advances that the
| React monolith prevents.
|
| The writer was high or delusional or bad at explaining the point.
| Nothing prevents you from putting logic into "its own pure layer"
| in any language. You can make it messy and impure with
| Rust/WASM/... just as you can keep it pure with pure JS. And it's
| not "entirely new" because people separated business logic for
| literally decades (and believe it or not many of them even did it
| while using React at the same time)
|
| And meanwhile the Rust version is slower and bigger. "What
| becomes possible" is a mystery.
|
| "React monolith" just takes the cake. React literally doesn't
| care how you separate your business logic, it's just a rendering
| layer. This ironically is a monolith SSG that does routing, YAML
| frontmatter, Markdown extensions, syntax highlighting and what
| not. Again, you are thinking about something like MarkoJS or
| QwikJS. Before you are trying to take something down you should
| probably understand the basics.
|
| Don't get me wrong, it's a cool project. But it could be more
| humble because authors don't seem to fully understand themselves
| what exactly they are proposing.
| boyka wrote:
| Regarding Rust, are we talking about a Rust backend with RPC/REST
| or is it simply WebAssembly compiled from Rust? If the latter,
| how is the data synced for CRUD?
| aziaziazi wrote:
| > frontend architect, design engineer, and UX engineers
|
| Damn should I update my resume again? I've used webmaster, web
| developer, full stack developer in the past. Can I use "internet
| creationist" to leap directly to the next call phrase?
|
| More seriously, I'm lost when using a search bar in a job
| listing. Now I just type "JavaScript" but that miss the posts
| only mentioning the higher stack and/or typescript.
| once_inc wrote:
| "internet creationist" make you sound like God either chose you
| to be a content creator, or ordained the internet into being...
| sam_goody wrote:
| I know a guy whose middle name is "Almighty God".
|
| I've actually wondered how that looks on a resume :D
| 7bit wrote:
| If you still use webmaster, perhaps updating is a good idea.
| Haven't seen that term used in the wild since the early? 2000s
| owebmaster wrote:
| it is time for a comeback
| tipiirai wrote:
| 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.
| eurekin wrote:
| Don't forget to mention "vibe coding" somewhere too
| greg0r wrote:
| If the authors of this project mean to say that a button in react
| wouldn't work without including the react library (which is why
| the button is supposed to be 73kb), it's a weak point, because
| the react library would be reused by other parts of the app
| bundle at this point.
|
| This is misleading to people and the promise is so shallow that
| it almost feels insulting.
| tipiirai wrote:
| I'm the author. To clarify: a button installed via
| ShadCN/Vite's official docs
| (https://ui.shadcn.com/docs/installation/vite) ends up way
| heavier than a full Nue SPA. It's not a jab at React devs--just
| showing how web standards can flip the script on bloat. Any
| thoughts on framing this comparison better?
| mapcars wrote:
| Can you give some examples of some of these standards that
| make Nue stand out and other frameworks don't use? It seems
| that if other frameworks make use of these standards we would
| get a similar performance boost across the ecosystem.
| xoxosc wrote:
| Seems like it should be Meta with billon dollars that
| should be doing that. The whole point is framework like
| React are made for DX and dev flow at company of that size.
| xandrius wrote:
| It's like someone making a hello world in C using the std,
| then one hand crafting the console print but losing literally
| everything else. Of course, if my goal was to just write
| hello world then it would make sense but 99.9% of people in
| the world will use something else, invalidating the point.
| chippiewill wrote:
| Maybe don't compare apples to oranges at all. No one is using
| react for a single button.
| haburka wrote:
| Mention that you know you are missing dozens of features
| instead of blaming it on "web standards" would definitely
| help frame it better. Do you think Vite doesn't know about
| web standards? It reads pretty naively.
|
| Also I recommend just not making a web framework. There are
| many of them, some very similar to Nue. Your effort could be
| placed on improving what is out there. I suspect that is a
| lot harder and less fun than just making something new. But
| if you manage to contribute then you'll be helping an entire
| community of people whereas a new web framework will likely
| see almost no adoption before it is abandoned.
| smusamashah wrote:
| I find the blurring/fade-in effect jarring. It makes it feel
| slower rather than faster. Feels like fade-in is used to hide the
| performance.
|
| Please add a button or something to disable that effect.
| ilrwbwrkhv wrote:
| Absolutely brilliant I've been following Nue for a while and
| every release gets more and more impressive.
|
| Thank you so much for putting in the hard work by making it and I
| hope others can understand why this is important and use it
| instead of cargo culting React and making the web worse every
| single year.
| fcpk wrote:
| 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.
| martinsnow wrote:
| Rarely is that a problem with react itself. Poorly written
| applications exist in every flavor of language, framework and
| library.
| mentalgear wrote:
| Some frameworks though make it easy to fall into a good
| default, and others don't.
| jack_riminton wrote:
| Yep, the more complex an app can be, the more complex the
| app will be
| jeffhuys wrote:
| 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.
| _Algernon_ wrote:
| 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.
| jeffhuys wrote:
| 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!
| YetAnotherNick wrote:
| 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.
| PaulHoule wrote:
| Could be a desktop PC with 25/3 ADSL where somebody is
| streaming Netflix and a game console is updating itself.
| docmars wrote:
| 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_.
| InsideOutSanta wrote:
| 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.
| black_puppydog wrote:
| 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)
| jeffhuys wrote:
| 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).
| jeffhuys wrote:
| 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.
| mariusor wrote:
| 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.
| spockz wrote:
| 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.
| mariusor wrote:
| 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.
| jeffhuys wrote:
| Interesting that you think that I'm not aware of the
| difference, lol. Whatever.
| mariusor wrote:
| 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.
| alabastervlog wrote:
| 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.
| throwaway290 wrote:
| 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
| tipiirai wrote:
| 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
| throwaway290 wrote:
| 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.
| troupo wrote:
| 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.
| tipiirai wrote:
| Nue JS reactive library is based DOM diffing. The next
| version also has keyed rows.
| troupo wrote:
| 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)
| ellinoora wrote:
| 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.
| jbreckmckye wrote:
| 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
| ikurei wrote:
| 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?
| brundolf wrote:
| 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
| regularfry wrote:
| > 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.
| soulofmischief wrote:
| 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.
| injidup wrote:
| > 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
| soulofmischief wrote:
| 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!
| RUnconcerned wrote:
| mithril is hardly the new paradigm of the year
| bryanrasmussen wrote:
| I'd think it has about 60% cohesive vision, but that's
| just a ballpark, 0 seems way to low though.
| soulofmischief wrote:
| Fair. I'm curious, what do you think are the best-
| designed and most cohesive parts of React?
| bryanrasmussen wrote:
| 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.
| threetonesun wrote:
| 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.
| bryanrasmussen wrote:
| 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.
| branko_d wrote:
| 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!
| johnisgood wrote:
| > 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.
| maccard wrote:
| They still existed and wrote shitty code 20 years ago, or
| 30 years ago.
| branko_d wrote:
| > 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.
| lexlash wrote:
| 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/
| cbm-vic-20 wrote:
| 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..
| tonyedgecombe wrote:
| 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/
| pmontra wrote:
| 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.
| edoceo wrote:
| I'm still designing on paper with crayons (not a joke)
| mattgreenrocks wrote:
| 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.
| friendzis wrote:
| 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?
| HappMacDonald wrote:
| Maybe they're not doing Scrum?
| maccard wrote:
| 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.
| andrewingram wrote:
| 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.
| MartijnHols wrote:
| 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.
| tipiirai wrote:
| 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.
| dhruvrajvanshi wrote:
| > 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.
| ipsento606 wrote:
| > 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.
| whstl wrote:
| 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.
| MartijnHols wrote:
| 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.
| whstl wrote:
| 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.
| afavour wrote:
| 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.
| PaulHoule wrote:
| 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.
| afavour wrote:
| 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.
| chrisweekly wrote:
| 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.
| MartijnHols wrote:
| 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.
| troupo wrote:
| > 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.
| MartijnHols wrote:
| 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.
| troupo wrote:
| 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.
| afavour wrote:
| Not really. Developers are as susceptible to marketing as
| anyone. React is backed by Facebook. Preact is... not.
| cowsandmilk wrote:
| > 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.
| jack_riminton wrote:
| 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
| branko_d wrote:
| 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.
| ben_w wrote:
| > 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.
| pavlov wrote:
| 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.
| CodesInChaos wrote:
| > 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.
| spockz wrote:
| 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.
| whstl wrote:
| 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...
| mpweiher wrote:
| > 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.
| tmpz22 wrote:
| 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.
| troupo wrote:
| 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-...
| HappMacDonald wrote:
| 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.
| mpweiher wrote:
| How would you spec such a "lower powered" Android device?
| nicce wrote:
| > 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.
| branko_d wrote:
| > 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.
| ksec wrote:
| >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.
| ivan_gammel wrote:
| > 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.
| PaulHoule wrote:
| 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.
| ksec wrote:
| 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.
| ivan_gammel wrote:
| >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.
| whstl wrote:
| 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.
| mapcars wrote:
| > 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.
| bambax wrote:
| 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.
| j-krieger wrote:
| > 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.
| TickleSteve wrote:
| Pure JS _is_ that interface... you 're arguing for multiple
| unnecessary abstraction layers piled on top of each other.
|
| More abstraction != easier to use.
| tipiirai wrote:
| 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.
| troupo wrote:
| > 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
| skydhash wrote:
| > _> 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.
| j-krieger wrote:
| 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.
| onion2k wrote:
| _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.
| arvinsim wrote:
| 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.
| GuB-42 wrote:
| 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.
| j-krieger wrote:
| You still can't style select elements in anything but
| brand new alpha chrome. It's been 20 years since that
| feature was requested.
| koshergweilo wrote:
| > 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
| troupo wrote:
| > 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.
| skydhash wrote:
| > _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.
| j-krieger wrote:
| Any user facing website that is not a portfolio site is
| interactive. The days where the web is display-only are
| long past.
| j-krieger wrote:
| ,,The browser" doesn't exist. So no, we don't have one.
| sparin9 wrote:
| 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.
| brulard wrote:
| 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.
| sensanaty wrote:
| 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?
| bambax wrote:
| > _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.
| OscarDC wrote:
| > 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.
| cruffle_duffle wrote:
| 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.
| j-krieger wrote:
| > 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.
| geocar wrote:
| > 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.
| zwnow wrote:
| Well most stuff going wrong in apps is actually managements
| fault. At least in my experience. Either directly or hidden
| in their decision making.
| nsonha wrote:
| 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.
| andai wrote:
| 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)?
| johneth wrote:
| > 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?)
| robertlagrant wrote:
| > 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.
| PaulHoule wrote:
| "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.
| maxloh wrote:
| 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.
| tipiirai wrote:
| 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!
| girvo wrote:
| > 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)
| maxloh wrote:
| 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.
| tombl wrote:
| 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.
| sensanaty wrote:
| > 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.
| SebastianKra wrote:
| 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.
| oefrha wrote:
| 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.
| tipiirai wrote:
| 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.
| oefrha wrote:
| 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.
| sgc wrote:
| 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.
| troyvit wrote:
| > 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.
| yuskii wrote:
| > 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
| senordevnyc wrote:
| This sounds like ChatGPT's voice :)
| balamatom wrote:
| ChatGPT learned that voice from actual people, you know.
| senordevnyc wrote:
| 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.
| balamatom wrote:
| 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.
| tipiirai wrote:
| Would love to get some help on documenting Nue! Crazy
| amount of work for a non-native English speaker doing
| both coding and docs.
| jeffhuys wrote:
| It does, and it muddies the waters a lot. Why does it
| read like a sales pitch?
| dragonwriter wrote:
| 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.
| senordevnyc wrote:
| 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.
| dragonwriter wrote:
| 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.
| rob wrote:
| 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.
| mvdtnz wrote:
| 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.
| nicce wrote:
| 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.
| hombre_fatal wrote:
| 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
| mvdtnz wrote:
| > 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?
| jmaw wrote:
| Are you really going to build a site which just consists
| of a button?
| mvdtnz wrote:
| If I'm working with a payload budget and I'm using React
| I guess so?
| albedoa wrote:
| Your question is, incredibly, more dishonest than the
| original claim. Truly impressive.
| mvdtnz wrote:
| What's dishonest about my question? Please keep your
| personal attacks to yourself.
| hombre_fatal wrote:
| 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.
| programmarchy wrote:
| 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.
| nicce wrote:
| 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.
| mvdtnz wrote:
| > 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?
| nicce wrote:
| 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.
| PaulHoule wrote:
| 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.
| kylecordes wrote:
| 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.
| a022311 wrote:
| 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.
| schwartzworld wrote:
| > 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.
| 9question1 wrote:
| 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?
| mvdtnz wrote:
| > 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.
| eastbound wrote:
| > 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.)
| code_biologist wrote:
| I'm old enough to remember when this simplified model was
| why people thought React was better than alternatives.
| lastdong wrote:
| I know, right? And where is Preact, Inferno and others
| sped-up React-like now?
| teg4n_ wrote:
| 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.
| balamatom wrote:
| >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.)
| actinium226 wrote:
| > 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?
| floydnoel wrote:
| 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!
| ToucanLoucan wrote:
| 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?
| oefrha wrote:
| 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.
| trgn wrote:
| 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.
| knubie wrote:
| Downloading 60kb of compressed javascript takes way longer
| than executing it.
| viraptor wrote:
| Executing 60kb of JS can take between 0s and infinity.
| You can't summarise it like this.
| ToucanLoucan wrote:
| 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.
| azemetre wrote:
| 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.
| FridgeSeal wrote:
| The PNG also doesn't then go off and start pulling even
| more data down off the network.
| Tadpole9181 wrote:
| 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.
| aubergene wrote:
| 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
| jsight wrote:
| > 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.
| maelito wrote:
| 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.
| rdsubhas wrote:
| 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.
| docmars wrote:
| 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.
| lern_too_spel wrote:
| 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.
| nine_k wrote:
| 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.)
| sheepscreek wrote:
| 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.
| gr__or wrote:
| The FAQ (https://nuejs.org/docs/faq.html) describes pain points
| that seem pretty foreign to me, the exact thing I appreciate
| about React is that I can focus on the domain and the tech MOSTLY
| does fade into the background. It has been an improvement in that
| regard, to all the frontend MVC I've done before and the
| architectural pattern has been adopted for good reason by all the
| native platforms.
|
| TBC in React and its offspring, you can still model business
| logic outside of components, we just learned that most UI
| development is better served by keeping UI and its state closer.
| Cthulhu_ wrote:
| "mostly" for sure; it's a good mental model and allows me to
| build modular applications etc, but I hate that a nontrivial
| amount of code and headspace is spent on things like re-
| renders, memoization, useCallback, dependency arrays, etc. I
| hope the React compiler will finally solve this, because the
| competition (apparently?) has (I haven't had the time to look
| into e.g. vue yet).
| gr__or wrote:
| Absolutely, it would be nice if we found the right
| abstraction to get rid of that part as well. Basically every
| non-React framework's answer to that is Signals (aka change
| tracking), where React is doubling down on unidirectional
| data flow and thus dependency arrays. React Compiler indeed
| solves the 99% of performance related memo-s.
|
| For effects you still will have to understand the mental
| model (which I'd argue is inherent in the domain and not
| incidental to the tech).
|
| From reading Nue's docs on Interactivity, it seems to opt-out
| of the discussion by going back to good old manual UI
| refreshs. I personally would not choose that, too many pre-
| React debugging nights spent on chasing state<->UI
| desynchronization bugs.
| edweis wrote:
| Looking at the project: - Why is the demo
| impressive https://mpa.nuejs.org/app/ I believe someone can do
| the same web-app in React with the same performance. - I'd
| like to quickly see some code samples on the home page. I had to
| dig the documentation to find some code samples
| (https://nuejs.org/docs/view.html#clean-html-templating), is it
| inspired from Svelte ? - How is new faster and lighter
| compared to other tech? Specifically, compared to raw HTML/js.
|
| To convince me that Nue is a framework worse using, please show
| that Nue: 1. Is simpler than HTML+JS (or at least
| simpler than react): like https://alpinejs.dev/ 2. Is easy
| to understand: maybe the markup and logic are close to HTML or
| something else I already know 3. Has a better DX with good
| build time and HMR: you nailed this one 4. The tech is
| better: low overhead? highly based on WASM? virtual DOM? Server
| islands? 5. Show me metrics: https://esbuild.github.io/
| nailed this one
| arijun wrote:
| > Why is the demo impressive https://mpa.nuejs.org/app/ I
| believe someone can do the same web-app in React with the same
| performance
|
| Weren't the main points on the main page that it was small
| ("lighter than a React button"), and could handle large amounts
| of records ("far past where JavaScript (and React) would crash
| with a stack overflow error")?
| KTibow wrote:
| Those points are only true if you're comparing to a React app
| that uses bloated frameworks and inefficient list
| manipulation (as other commenters pointed out,
| `list.push(...items)` causes problems)
| davedx wrote:
| 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
| bigjump wrote:
| Most of the Vue devs I know, also use TypeScript for the same
| reasons.
| tipiirai wrote:
| 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?
| seivan wrote:
| 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.
| isqueiros wrote:
| 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.
| dalmo3 wrote:
| That's one way to find a niche audience.
| tossandthrow wrote:
| > ... 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.
| mplanchard wrote:
| 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.
| andai wrote:
| The only way it's possible is if you keep them in your
| head.
| tossandthrow wrote:
| 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).
| tshaddox wrote:
| 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.
| Nijikokun wrote:
| That feels more like you're being abused rather than a
| framework problem.
| tossandthrow wrote:
| 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.
| david422 wrote:
| > There are plenty of large projects written in Python
|
| I've worked on one of those, and I would not recommend
| it.
| avinassh wrote:
| > 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/
| ddejohn wrote:
| Not sure why you're being downvoted -- large, legacy,
| untyped Python projects are a nightmare to work with.
| mplanchard wrote:
| Yeah I mean, I've worked on a multi-million-line Python 2
| codebase. It wasn't easy, but it certainly wasn't
| impossible.
| mmkos wrote:
| 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.
| jack_riminton wrote:
| Uh oh, you've summoned the typesetters
| ko27 wrote:
| 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.
| CharlieDigital wrote:
| 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
| unchar1 wrote:
| 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.
| CharlieDigital wrote:
| 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
| facade) > 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...
| tossandthrow wrote:
| 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.
| CharlieDigital wrote:
| > 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/
| gcau wrote:
| >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.
| tossandthrow wrote:
| > 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
| CharlieDigital wrote:
| > 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++.
| tossandthrow wrote:
| 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.
| Nijikokun wrote:
| Type definitions are definitely compiled with CPP. Type
| erasure only happens with polymorphism types. You can
| actually view the types with ghidra.
| unchar1 wrote:
| > 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)
| unchar1 wrote:
| > 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
| tshaddox wrote:
| 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?
| empw wrote:
| 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.
| MrJohz wrote:
| > 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/80557bbc1c8a
| 94c43a95...
| mplanchard wrote:
| 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.
| recursive wrote:
| 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.
| mplanchard wrote:
| 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.
| recursive wrote:
| Is there such a thing as a statically typed language? CPU
| opcodes don't type-check their parameters.
| throwaway894345 wrote:
| 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).
| oynqr wrote:
| > The types only matter during compilation.
|
| That's pretty much the definition of static typing.
| throwaway894345 wrote:
| 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.
| IshKebab wrote:
| JS with JSDoc is basically just awkward Typescript.
| tshaddox wrote:
| 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.
| CharlieDigital wrote:
| It's not an "aesthetic preference"; it's a functional
| preference for debugging and iteration speed as cited by
| the team.
| tshaddox wrote:
| 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.
| sureIy wrote:
| Which is quite hypocritical coming from a compiling
| framework and thus such a ridiculous stance.
|
| _We hate build steps in our build step._
| chamomeal wrote:
| 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
| tipiirai wrote:
| 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.
| tossandthrow wrote:
| 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.
| anentropic wrote:
| 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.
| davedx wrote:
| 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).
| turnsout wrote:
| 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.
| herrherrmann wrote:
| 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.
| arewethereyeta wrote:
| 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
| mexicocitinluez wrote:
| > 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.
| ellinoora wrote:
| Making zero sense of your own take of the argument makes
| absolutely zero sense
| mexicocitinluez wrote:
| what?
| leptons wrote:
| >"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.
| vile_wretch wrote:
| I mean it's quite literally "we don't use typescript
| because some developers over-use it" which is essentially
| the same thing
| littlecranky67 wrote:
| 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.
| madeofpalk wrote:
| > 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_.
| troupo wrote:
| 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`"
| spiffytech wrote:
| 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.
| barrell wrote:
| 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 :)
| Etheryte wrote:
| 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.
| jeffhuys wrote:
| 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.
| tipiirai wrote:
| 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.
| jeffhuys wrote:
| 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.
| tshaddox wrote:
| 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.
| epolanski wrote:
| > 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.
| IshKebab wrote:
| Only since Vue 3 though, and the types are still not as good
| as React.
| epolanski wrote:
| 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?
| IshKebab wrote:
| 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_r
| eal...
| Timon3 wrote:
| > 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.
| IshKebab wrote:
| > 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.
| Timon3 wrote:
| > 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.
| dlisboa wrote:
| > 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.
| cruffle_duffle wrote:
| 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.
| WuxiFingerHold wrote:
| > 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.
| imiric wrote:
| I really like how Nue is shaping up! Having a clear MVC
| separation, leveraging modern web standards, semantic markup--all
| great things. Kudos!
|
| Seeing the .dhtml extension certainly brings back memories... One
| thing I dislike is that the HTML is still parsed and converted
| into JS, which is then evaluated at runtime, correct? I realize
| that this is required to support templating and a nicer syntax
| for binding and such, but my ideal "framework" would support
| plain HTML files that are not converted to JS, but used very
| lightweight syntax (essentially custom data attributes, and
| `<template>` elements) to make the page dynamic. In fact, I'm
| experimenting with such a library right now[1]. This approach is
| likely more difficult to manage when building large web apps, but
| for simple UIs as used in browser extensions, it's fairly
| sufficient.
|
| Frontend web development has been stuck in a pit of complexity
| for well over a decade now, and it's about time we go back to
| basics. There are new generations of frontend developers who only
| know this way of working, which is a shame. They're not really
| _web_ developers, but React, Vue, or whatever the popular
| framework is, developers. Web standards are far along now that
| there is very little additional glue and sugar needed to build
| modern web applications. React ushered in a new way of building
| UIs, but it also spawned dozens of copycats and frameworks that
| are downright developer-hostile beyond their shiny exterior. Not
| to mention the security nightmare of an incomprehensibly large
| dependency tree. Let's actively reject this madness.
|
| [1]: https://github.com/hackfixme/miu
| bricss wrote:
| Replace N in Nue with V for Vue, and it will be perfection.
| midzer wrote:
| Just do VanillaJS...the W3C is your framework.
| progx wrote:
| Nue still continues to advertise with clickbait?
| vanderZwan wrote:
| > _Using Rust and Event Sourcing for instant UX over 150,000
| records -- far past where JavaScript crashes with a stack
| overflow error._
|
| Nit: while I fully support making the web more efficient and hope
| that Nue is successful in promoting that, I'm skeptical of the
| "crashing" JS claim here. You can do amazingly efficient things
| with TypedArrays, the forgotten middle child between JavaScript
| and WASM.
|
| Having said that, this requires building a few clever data
| structures on top (I've gotten a lot of mileage out of "typed"
| dequeues, and (sparse) bitmaps myself), often emulating structs
| in a language unable to express them properly. So the resulting
| code is not exactly _idiomatic_ JavaScript -- which I presume is
| what they implied here. Plus in this case it probably still
| wouldn 't be as fast as a well-written WASM implementation, since
| almost all of the work is likely spent searching with only a
| little bit of DOM manipulation at the end.
|
| So I'm both agreeing and feeling like it slightly
| overgeneralizes. I guess my point is: yes, let's be critical of
| bloated web frameworks, but let's not equate React with
| JavaScript either.
| tipiirai wrote:
| Author here. You're spot on. I took away the React association
| and added a direct link to the JS code [1] that hit the
| 'Maximum call stack size exceeded' wall. TypedArrays can do
| wild stuff, no doubt, but yeah, it's not exactly vanilla JS--
| and still lags a tight WASM setup. Appreciating the nuance
| here!
|
| [1]:
| https://github.com/nuejs/nue/blob/master/packages/examples/s...
| vanderZwan wrote:
| The new wording is much more nuanced, appreciated! Also the
| fact that you link to the actual code that broke down, making
| it possible to verify the claim. Less ammunition for the
| people who actually are skeptical of the project instead of
| just nitpicky like me ;)
|
| Speaking of the code in question, it looks pretty sensible -
| there's a bit of low-hanging fruit where one could avoid
| creating redundant arrays by turning chained calls to map and
| filter into one for-loop and such, but that's about it.
|
| What confuses me is that there's no point in the code where I
| see any recursion, here or in the other JS files that seem
| relevant, so how does one end up with a call stack overflow?
|
| (not questioning that it crashed for you, it's just that I
| don't see any obvious flaws in the implementation, so I'm
| curious to lean what the "gotcha" is in case I ever bump into
| something like it myself)
| akx wrote:
| The stack overflow is caused by an `arr=[...];
| events.push(...arr)` in `add_events`. Replacing that with
| `for(const x of [...]) events.push(x)` gets rid of that
| issue, and the JS-backed build is then snappier to search &
| filter than the WASM/Rust version.
| vanderZwan wrote:
| Oh duh, yeah using spread syntax for function calls is
| definitely limited to fewer than 150,000 arguments in any
| browser that I know of. Don't expect everyone to know
| that, but I sure did, stupid that I didn't spot that.
| Thanks for pointing it out!
|
| (funny enough I tend to use _for(let i = 0; i <
| arr.length; i++)_ loops most of the time anyway because
| the iterator protocol adds too much overhead for my
| tastes, so I wasn't likely to ever bump into this in the
| first place)
| mexicocitinluez wrote:
| What does event sourcing have to do with searching or
| "instant keypresses"? It's a storage pattern for recording
| events, not a way to search.
|
| Like, you're searching a single table for text messages, not
| a stream of events.
| andrewstuart wrote:
| That post didn't explain what it actually is. Is it a JavaScript
| framework? A WASM library? Something else?
|
| Comparing a JavaScript app to anything wasm is false equivalence
| because wasm can't do the DOM.
| supermatt wrote:
| If you just use an html button with simple styling the size is
| around 58kB (not the quoted 73kB, which is from other libs that
| they built with like ShadCN than just react), so its still
| impressively smaller than react.
|
| That said, using Preact instead (a smaller and more modular
| react-style library) the file size is less than 5kB. Its almost a
| drop-in replacement for React too:
| https://preactjs.com/guide/v10/differences-to-react
|
| If i make a similarly minimal app with Nue (the lib the article
| is about), export as production, and remove the favicon it seems
| to want to add automatically, the filesize is 28kB. I couldn't
| see a way to meaningfully reduce that in their docs, as its
| clearly exporting things that arent being used.
|
| Its pretty disingenuous for them to compare an app to a single
| button, given their own single button implementation is massively
| overinflated too. It does appear to be a full app framework
| rather than just a view library though. So I'll definitely give
| it a whirl.
|
| To the OP: From a lot of the comments here, including my own,
| comparing yourself in this way is only going to result in people
| calling you out on it. Its clear the lib has merit in its own
| right, but you aren't comparing like to like, and if the focus is
| on "button" apps, then you are still WAY behind some other libs
| in terms of export size.
| dzonga wrote:
| this is why inertia.js is a positive path forward.
|
| it relegates React, Vue etc to be view layers - purely view
| layers. all models / state etc handled by your monolith Rails,
| Laravel server. this simplifies a lot of things.
|
| frameworks like Vue & Svelte have scoped styles which preserve
| knowledge of CSS. While Tailwind is convenient - a lot of people
| won't know the capability of CSS
|
| and why it was named cascading & the customability of CSS for the
| user.
| mirzap wrote:
| Honestly, after playing around with your example and tweaking a
| JavaScript example, I feel that my plain JS example is faster
| than the one with WASM/Rust on Nue (possibly due to the
| animations). Please disable animations; I think they make your
| WASM example feel slower than it probably is.
|
| Here is a 1 million rows table in JS with filtering, sorting, and
| pagination:
| https://htmlpreview.github.io/?https://gist.githubuserconten...
| bilekas wrote:
| The tagline says a lot more about React than it does Nue, but I'm
| always interested in less bloat when it comes to front-end. I'll
| try this out, one small thing I don't like is in the demo there
| is a weird pulsating effect that actually modifies the layout
| when clicking, throwing me off a little.
| chvid wrote:
| But what if it is not the frameworks that are bloated but the
| application developers that make bloated applications? Then how
| would this fix anything ...
| misiek08 wrote:
| Couldn't switch to docs from the page linked here, Chrome on
| macOS. Refresh and it works. Big hopes killed in an instant.
| blatantly wrote:
| How does it involve Rust? Server side or wasm?
| Aldipower wrote:
| Very catchy landing page, like it. And I've read the
| documentation. Unfortunately not convincing me. I mean, writing
| larger web apps means nothing else then dealing with a lot of
| _state_, really a lot of asynchronous _state_. Clicks,
| notifications, mouse movement events, push messages, navigation
| changes and so on and on. Larger web apps are state monsters.
| That's why I choose a framework that is good a state management
| in the first place. React is one of those proven. Nue does not
| look trustworthy in regard to good state management tbh. For
| smaller apps that might not be a problem, but there I tend to use
| vanillajs anyway.
| wg0 wrote:
| 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.
| brulard wrote:
| 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
| wg0 wrote:
| No, the support is quit limited not as many features are
| supported.
| iammrpayments wrote:
| I transitioned to svelte and I'm finding it around 3x to 2x
| times less complex than React
| pier25 wrote:
| 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...
| newswangerd wrote:
| 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?
| jfcisco wrote:
| 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
| wg0 wrote:
| 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.
| chkhd wrote:
| Interesting, on that page using Safari, clicking on the home/nue
| logo or most other links/buttons results in a null error :)
|
| I would hope React buttons work when people click on them though.
| codedokode wrote:
| I wish instead of this marketing article there were technical
| details, for example: what method of change tracking is used
| (proxies Vue-style or recomputing everything React-style).
|
| Also I didn't understand the phrase about JS "overflowing stack"
| with 150 000 objects. I created a list of 150 000 objects with
| the following code: var list = []; for
| (var i = 0; i < 150000; i++) { list.push({ id: i, name: `Name
| ${i}`, weight: i * 100 }); }
|
| According to profiler, this array (with objects) uses 14 Mb,
| where 2 Mb is array and the rest are objects and strings. Running
| list.find() without any indexes also doesn't overflow the stack.
| With indexes it would probably be lightning fast and won't need
| any WASM and complications.
|
| JS is not that slow. And if you do numeric computations (i.e.
| multiplication of numbers in large arrays) the code gets compiled
| and runs pretty fast.
| uasi wrote:
| The author uses something like `list.push(...objects)` in his
| demo code, and I believe this is the culprit. Passing many
| (~100,000) arguments to a method at once using the spread
| operator is known to cause a stack overflow, because, in
| JavaScript, each argument is placed on the call stack.
| oxidant wrote:
| Spreading arrays and objects is such a common performance
| hit. It works fine for small instances but falls over in
| large instances.
|
| Here's the JS CRM engine https://github.com/nuejs/nue/blob/ma
| ster/packages/examples/s...
|
| I see a number of issues, but don't have time to look into
| them.
|
| 1. Spreading when you probably don't need a copy:
| sortEntries. Sorting is probably where the overflow happens.
| Just sort in place or use Array.from or slice.
|
| 2. Excessive use of array functions. In my experience, a C
| style for loop performs better when you need performance.
| Create an empty array before, perform your business logic
| inside the block, and push to the array.
|
| 3. I don't know how filter is called, but it potentially
| loops through all of the events three times in the worst
| case.
|
| 4. paginate manually creates a JSON string from the returned
| entries. I don't know why, it seems inefficient.
| admiralrohan wrote:
| I like the philosophy so much, I myself am working on a
| minimalist theory to explain human psychology and strongly
| against specialized therapy and bloated productivity systems. We
| have specialized rules for everything which I feel repeatative
| and we are not using the full potential of human mind.
|
| Anyways, here are my initial observations on NueJS
|
| 1. In the age of AI we need to support it for broader adoption.
| One of the reasons people choose NextJs and Tailwind over other
| frameworks is that LLMs understand them well. We need some
| minified doc to pass onto LLM to make it understand the
| framework.
|
| 2. What do you think about the unstyled components like Radix UI?
| Accessibility issue are important for components like Model.
|
| 3. What do you think about server components? I like them
| personality as we don't need to pay for separate NodeJS server as
| a small team.
|
| 4. How much Rust is required to use it properly? It's not an easy
| language to learn as far I heard.
|
| 5. How do it compared to AlpineJS who also focuses on
| performance?
| bryanhogan wrote:
| Yes, React is huge, but I also see it used for everything and
| everyone when it's really not the right tech-stack in many
| situations.
|
| Just need a simple interaction free site? Use Astro.
|
| Need some interaction? Use Svelte. Larger project? SvelteKit.
|
| Need a more established solution? Use Vue.
|
| Working in a huge team and need a highly opinionated framework
| with strict conventions? Use Angular.
|
| More than 99% of websites would be sufficient with Astro though.
| And when just some interactivity is needed it is always possible
| to add Svelte / Vue / Solid / Alpine / HTMX on top of Astro.
| klysm wrote:
| React itself is not huge
| mplanchard wrote:
| Weird that the current state of things for a simple,
| noninteractive site is some kind of framework and not just
| "write the HTML with a little JS where needed," which works
| perfectly well and requires no additional baggage.
| fareesh wrote:
| imo the primary benefit of react is the nice component library.
| sesm wrote:
| Is it trying to sell Backbone.js-style MVC as a replacement for
| React?
| eitland wrote:
| Seems to be no support for TypeScript in the frontend? I mean, it
| is mentioned, but only together with Rust and Go for "computation
| engines".
|
| No TypeScript = No deal with me.
|
| I wrote my first Javascript application back in the spring of
| 2025, and I am not aware of anyone who is willing to pay me
| enough money to voluntarily write Javascript again in a project
| of meaningful size.
| ksec wrote:
| I like this. Cant wait to see it being released.
| canterburry wrote:
| Most new frameworks start as the "lightweight" option to whatever
| more mature options exist at the time. This is no argument for
| adoption.
|
| Please post again 10 years from now after you have added all the
| bloat your users request and handled all the edge cases you don't
| yet understand.
|
| If you are still lighter than a react button...that will be news
| worthy.
| is_true wrote:
| I feel the same. I started using svelte to build widgets with
| few requirements that were deployed as web components, it was
| great for that.
| iammrpayments wrote:
| I don't think React has ever been considered lightweight,
| judging from the mostly negative reactions from this website
| when it first came out.
| mplanchard wrote:
| So, nothing is worthy of discussion or can claim any benefits
| over the incumbents until it has become an incumbent itself?
| How is it supposed to attract the necessary users to get
| bloated if they can't talk about it in relation to the
| established players?
| canterburry wrote:
| All I am saying is that being _lightweight_ , when you have
| been around for less time than a mature solution, is a mute
| point.
|
| It's a cop out way to differentiate because you are clearly
| not comparing apples to apples.
|
| You have a fraction of the features and a fraction of the bug
| fixes. You are trying to make it sound like you are a 1:1
| replacement, when you are not.
| floydnoel wrote:
| FYI, you probably meant to say "a moot point."
|
| https://www.grammarly.com/blog/vocabulary/moot-point/
| canterburry wrote:
| Touche
| internetter wrote:
| Solid.js is doing amazing w/re to its bundle size. Its been in
| development for something between 6-9 years depending on how
| you count and it is still very very slim.
| unchar1 wrote:
| Nue seems to be in an odd space. It's an untyped framework, built
| on top of "web standards".
|
| But if you wanted web standards + web component, Lit already
| fills that space. If you want untyped JS or little/no JS at all,
| there's HTMX. Or if you're just tired of React, and want
| something faster + simpler, there's Svelte/Solid.
|
| I'm not sure what problem Nue is uniquely solving.
| jgalt212 wrote:
| Do the AI's generate slow and bloated React, or lean React that
| works well with the new compiler?
| k__ wrote:
| A React comparison is a straw man when there are already popular
| alternatives that are considerably smaller than React.
| maelito wrote:
| No thanks, JSX is fine.
| dividedcomet wrote:
| This doesn't square with most of my experience with React,
| especially if use it to generate static code hosted by nginx.
| I've found my personal site to always be wicked fast, even though
| it's not that complex.
| morteify wrote:
| I think there is an issue with the implementation of search and
| filtering.
|
| When I open https://mpa.nuejs.org/ and type "kind of rate limit"
| in the search box, I get 383 search results, and the URL updates
| to include the query: /app/search/?query=kind+of+rate+limit.
|
| However, when I paste that URL directly into a new tab, I only
| see one result instead of 383.
| account-5 wrote:
| I'm a novice, I chose to learn dart/flutter rather than deal
| with, and attempt to figure which, web framework to use.
|
| If forced I would likely go with htmx.
|
| Regards nue: do I need to know rust?
| Rockslide wrote:
| > What's next We're improving the developer experience in three
| distinct phases: Framework -> Design -> Cloud
|
| So the "cloud" part is where the enshittification will begin.
| Been there, done that, switched away from next.js :|
| desireco42 wrote:
| I really like the use of markdown and extending it. I think this
| is the way to go.
|
| Also how you are thinking about app theme and design is really
| good.
|
| This button demo... really ambivalent about it.
| nashashmi wrote:
| I feel like some of react's innovations should be built into
| browsers. Jquery got built in with document.queryselect.
| SJC_Hacker wrote:
| Google decides what goes in a browser these days. Since React
| came out of Facebook there is approximately _(checks notes)_
| -ZERO chance in hell- of that happening
| flufluflufluffy wrote:
| It sounds cool and all but the single button thing just irks me.
| The point of React is for making a system of components with
| potentially complex relationships between them/when they're
| displayed, etc... Nobody is using React to put a single button on
| their website. It'd be nice if there was a more useful, practical
| "benchmark" that your entire marketing of the library is centered
| on.
| phaedrus wrote:
| This framework is a good example of something I call, "there's
| plenty of room in the middle." (In analogy to Feynman's "plenty
| of room at the bottom" about nanotechnology.)
|
| Much like how Cosmic Inflation in the early universe left the
| imprint of microwave background radiation written exponentially
| large across the sky, I believe the exponential expansion of
| computing during the era of Moore's law left whole sections of
| scale in software not-fully-explored.
|
| Specifically, as "average app sizes" went from 1K - 10K - 100K -
| 1M - 10M - 100M+, you could imagine the 1K-10K got fully explored
| because the space wasn't that big to begin with, and the 1M - 10M
| range got, if not explored at least inhabited, but it could be
| that that middle range of "neat applications that weigh in ~100K+
| but less than 1M" didn't get completely explored because we
| didn't spend enough time in that era of computing.
|
| A similar thing may be playing out in AI scaling, where we went
| from tiny to medium to huge model sizes, but now some new
| participants are going back and doing neat things with medium
| sized models.
| h14h wrote:
| IMO talking about the "heaviness" of popular web frameworks is
| way too simplistic to be actually meaningful.
|
| How light or heavy an app feels, in my experience, has very
| little to do with initial bundle size, and far more to do with
| how adeptly the developers have solved the distributed systems
| problems of their app.
|
| Are images compressed and cached on a CDN? Is linked content pre-
| fetched? Does the app avoid unnecessary roundtrips to the server?
|
| These are the questions that truly matter, IMHO. They're also
| things that junior devs are likely to get wrong.
|
| All that said, I agree that you tend to see far more sluggish
| websites written in React than in any other framework. But
| personally, I think that's a consequence of React being popular,
| and attracting a larger proportion of devs who miss important
| details.
|
| I share this opinion of Electron, BTW.
| zozbot234 wrote:
| > Does the app avoid unnecessary roundtrips to the server?
|
| Guess what, using server-rendered pages avoids _all_
| unnecessary roundtrips by definition, because the entire page
| is loaded in one go. You can _augment_ a server-rendered site
| with client-side SPA features for seamless interaction within
| the page, but that 's not a key requirement either.
| robertoandred wrote:
| Rendering and loading an entire new page just to open a
| dialog seems pretty unnecessary to me.
| crabmusket wrote:
| And importantly, does the app have clear loading states when it
| has to block on something? Making sure _something_ happens
| immediately can make things feel fast even if you 're waiting
| on the network.
| 65 wrote:
| This is cool. Though I think what could be improved is using
| folder routing, it works surprisingly well.
| austin-cheney wrote:
| _Its not big frameworks making the web big /slow. Its..._
|
| Yes, its absolutely the big fucking frameworks. In most cases it
| is the actual literal use of the frameworks, but even that isn't
| the real problem. The real problem is deeper. You can call it
| second order consequences.
|
| Its developers that cannot optimize and cannot program without
| something like React. If you took React away would you suddenly
| not be able to do your job at all? That's horrible problem to
| have. The result is a bunch of toxic defensive posturing by
| people who suddenly appear not qualified to do the work.
|
| If you cannot dig deeper you certainly cannot optimize deeper.
| That makes the assumption you are actually measuring things and
| optimizing things in the first place, which many developers
| aren't. Again, if a given developer lacks the capabilities to
| dive deeper they may also lack the capabilities to measure
| things, as is quite common.
| mirkodrummer wrote:
| In the meanwhile on the App/Play store some native apps like
| YouTube weight around half a GB... but only the web is bloated
| dimgl wrote:
| I can't find a single example of what a Nue app looks like. All I
| can find is pretentious claims about how Tailwind sucks and other
| outlandish claims.
| WuxiFingerHold wrote:
| React is the most used frontend framework, but not a good
| reference as React is outdated, slow and big.
|
| Take Solid, Svelte or Vue (with or without Vapor mode) as
| reference and the picture looks different. Additionally when
| using custom components instead of large UI libs based on HTML
| elements like <dialog> or the recently announced stylable
| <select> element you have a very powerful, small and simple
| stack.
|
| Still, they catched my interest. A lot. I'll dive into the docs
| to learn more. Maybe I'll be convinced to change my go-to stack
| to Nue ... damn, I had so many happy weeks with Vue. Maybe till
| Vue Vapor is out.
| alloysmila wrote:
| Based on work done by svelte and solid, I think it is possible to
| shave base react down to half its current size, but it appears
| nobody (inside or outside of Meta) is willing to take on this
| challenge.
|
| Unfortunately, the tradeoffs are still in favor of react and will
| continue to be in favor of react for the foreseeable future.
|
| Most importantly it is next to impossible to get developers to
| give up DX (and muscle memory) for smaller JS bundles.
| exabrial wrote:
| https://dayssincelastjavascriptframework.com/
| ChuckMcM wrote:
| So is there a book that I could read that would allow me to write
| applications with just HTML/CSS some js and rust? I don't want
| Nue so much as I want "The art of writing lightweight, feature
| complete, responsive applications on the modern web."
|
| Would love a pointer to THAT.
| darepublic wrote:
| If I felt strongly about going lightweight I would (do) use plain
| js. I trust myself to know when I'm following basic principles of
| performance and when the line has been crossed warranting the use
| of a framework
| Maksadbek wrote:
| So many people are obsessed with Web application size. But there
| are other important factors as well. First of all, the UI must be
| functional even it's slow and heavy. If it does the job then it's
| already a win. I don't actually care how long I'll wait while I'm
| downloading the JS bundles. I've been waiting 5-10 mins GTA to
| load back in 2008, waiting seconds is totally ok.
| SJC_Hacker wrote:
| It would be nice if the standard JS library was more feature
| complete like Python. Then devs wouldn't have to bundle third
| party libraries.
|
| Or perhaps the caching could be better. e.g. if your'e using
| Tailwind CSS version XXX, why does the browser have to reload it
| every single time?
|
| Local persistent storage isn't exactly at premium these days even
| for "lightweight" mobile devices.
| crabmusket wrote:
| > if your'e using Tailwind CSS version XXX, why does the
| browser have to reload it every single time?
|
| Security: https://www.stefanjudis.com/notes/say-goodbye-to-
| resource-ca...
___________________________________________________________________
(page generated 2025-04-01 23:00 UTC)