Something I realized while doing more political campaign work is how inefficient most self hosted solutions are. Things like plausible or umami (analytics) require at least 2 gigs of ram, postiz (scheduled social media planner) requires 2 gigs of ram, etc.

It all slowly adds up where you think a simple $10 VPS with 2 gigs of ram is enough but it's not, especially if you want a team of 10-30ish to work sporadically within the same box.

There can be a lot of major wins by rewriting these programs in more efficient languages like Go or Rust. It would make self hosting more maintainable and break away from the consulting class that often has worse solutions at way higher prices (for an example, one consulting group sells software similar to postiz but for $2k/month).

I guess there's the distinction between capacity that could be taken up by other things, and free capacity that doesn't necessarily cost anything.

For a server built in the cloud those cycles could actually be taken up by other things, freeing the system and bringing costs down.

For a client computer running electron, as long as the user doesn't have so many electro apps open that their computer slows down noticeably, that inefficency might not matter that much.

Another aspect is that the devices get cheaper and faster so today's slow electron app might run fine on a system that is a few years away, and that capacity was never going to be taken up by anything else on the end user's device.

> Most production software is multiple orders of magnitude slower than it needs to be.

at least 100x slower than it needs to be?

Why are electron apps memory intensive compared to other cross platform frameworks. Is it language, UI system or legacy?

Imagine the amount of useful apps that would not have been made without Electron.

By then I understand that matrix multiplication will have cured cancer and invented unlimited free energy, so no hindsight of waste needed.

The economic incentives line up much better there. You charge for tokens -> cost is GPUs -> you work very hard to keep GPUs utilized 100% and get max tokens out of those cycles.

Compare this to essentially any modern business app, the product being sold has very little relationship with CPU cycles, or the CPU cycles are SO cheap relative to what you're getting paid, no one cares to optimize.

> I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decade ago). That took something like 10 minutes.

For anyone that doesn't know: With sqlite you can serialize the db to a buffer and create a "new" db from that buffer with just `new Datebase()`. Just run the migrations once on test initialization, serialize that migrated db and reuse it instantly for each test for amazing test isolation.

> Most integration tests are not thread safe and make assumptions about running against an empty database. Which if you think about it, is exactly how no user except your first user will ever use your system.

Yea, cypress has this in their anti-patterns:

https://docs.cypress.io/app/core-concepts/best-practices#Usi...

Dangling state is useful for debugging when the test fails, you don't want to clean that up.

This has been super useful practice in my experience. I really like to be able to run tests regardless of my application state. It's faster and over time it helps you hit and fixup various issues that you only encounter after you fill the database with enough data.

>With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax.

This is because the kotlin compiler is not written in the way people write fast compilers. It has almost no backend to speak of (if you are targeting the jvm), and yet it can be slower at compilation than gcc and clang when optimizing.

Modern fast compilers follow a sort of emerging pattern where AST nodes are identified by integers, and stored in a standard traversal order in a flat array. This makes extremely efficient use of cache when performing repeated operations on the AST. The Carbon, Zig, and Jai compiler frontends are all written this way. The kotlin compiler is written in a more object oriented and functional style that involves a lot more pointer chasing and far less data-dense structures.

Then, if run on a non-graal environment, you also have to pay for the interpreter and JIT warmup, which for short-lived tasks represents nontrivial overhead.

But unlike header inclusion or templates, which are language level features that have major effects on compilation time, I don't think kotlin the language is inherently slow to compile.

Kotlin compiles fast; I don't have any problems with ktor. Spring Boot and Rust do not.

JavaScript was not supposed to a lot of things.

If you're already passing over the sources to strip the types, why would you also not do tree-shaking and minifications?

> TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

Was it? Have you forgotten namespaces and enums?

> TypeScript also was specifically designed so engine could strip types and execute result code.

That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!

> It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me.

You're not actually suggesting that technology can't evolve are you? Especially one whose original design goals were to process basic forms and are now being used to build full-blown apps?

It's absolutely wild to me that with everything that has happened in the last 2 decades with regard to the web there are still people who refuse to accept that it's changed. We are building far bigger and more complex applications with JavaScript. What would you propose instead?

[dead]

most likely they are not running the prod build on latest mac. so it is slower.

Yeah, 4 mins is currently the avg. build time for our TanStack app dockerized. The turbo part takes 30 sec with Vite 7

It blows my mind that there is a 12m build for a JavaScript application. How may lines of code is this app?

Next took a very bad turn and double downed on it. Coupled with years of terrible bugs its beyond repair for me unless they rewind a bunch of core changes they did.

There are several much better options right now. My favourite is Tanstack Start. No magice, great DX

Any suggestions to replace NextJS when you only use static export (no SSR)?

I'm being rather snarky here, but the main point of front-end JS UI frameworks is to exist and to survive in their environment. For this purpose they have evolved to form a parasymbiotic relationship with others in their environment, for example with influencers. The frameworks with the best influencers win out over older ones that do not have the novelty value anymore and fail to attract the best influencers.

Vercel has slowly taken over Facebook's position as being the employer of the main developers of React. There's a debate to be had over how much they 'control' it or not, but the fact create-next-app is the first recommended option on the official installation page now does show it's had an impact.

5 or so years ago, Next was a pretty solid option to quickly build up a non SPA, when combined with the static export function. It wasn't ideal, but it worked and came batteries included. Over time it's become more bloated, more complicated, and focused on features that benefit from Vercel's hosting – and static builds can't take advantage of them.

These newer features seem of limited benefit, to me, for even SPAs. Why is there still not a first class way of referencing API routes in the client code that provides typing? Once you reach even medium scale, it becomes a mess of inteprolated string paths and manually added shared response types.

After Tanstack Start, Next.js seems even less intuitive. While it remains a viable option due to its established momentum, it feels quite alien to backend devs, esp with its unconventional defaults.

Not me, but I can imagine it happening.

JSX is a nice server side templating language. There a lot of people who aren't dependency conscious, and a lot of people who love react, and there is quite a bit of overlap in those two groups. I've used bun + preact_render_to_string for server side JSX templates before and it was nice. When I did it seemed that bun somewhat embraced react, and I could imagine react being the path of least resistance to server-side JSX there for some of the folks in the aforementioned groups.

Instead of going:

Fetch index.html -> Fetch JS bundle -> Evaluate -> Fetch /users/me

You do:

Fetch index.html (your page is rendered at this point) -> rehydrate with client side JS for interactivity in the background

It's a pretty smart solution I think, and many people are still sleeping on the whole SSR topic.

> Are people using react for non-SPA’s?

Imagine a page that loads html during the first load, and then performs client-side routing during subsequent navigations. Is it an SPA? Is it not an SPA?

The point is JavaScript developers rediscovering PHP, Spring MVC, ASP.NET MVC, Rails,.....

And to sell Vercel on top.

Really the enterprise partner supports next, but not vanilla js sounds stupid? Honestly I expect them to prioritize nextjs and react given the popularity, but still be open to vanilla js.

I checked sitecore cloud to have special integration for nextjs and reactjs. But it also support vanilla js as well.

Are there really anyone who is exclusive to nextjs?

It's not a good piece of software. Breaks in many places

No no no, the script on the link was BEFORE llms. That was how it used to be done before. That was the recommended facebook way.

The LLM generated vite config is 20 lines

Doesn't seem like it — see VoidZero investors [0].

> Unfortunately for Bun, if they are forced to help Anthropic more than they can focus on OSS

Curious: is that speculation, or based on observation?

[0]: https://voidzero.dev/about

TC39 decorators emit just landed in tsgo about 24 hours ago. Hopefully they're available in Vite 8 soon. I'm using them in GodotJS https://github.com/godotjs/GodotJS/commit/a4bafef9f14c103b09...

Awesome. Standard decorators support is not a dealbreaker for me, but enums and other types of non-erasable syntax would be.

Do you know what the status is on using Rolldown as a crate for rust usage? At the moment most rust projects use SWC but afaik its bundler is depreciated. I usually just call into Deno for builds but would be nice to have it all purely in Rust.

It doesn't support const enum, unlike esbuild which supports them well enough to be credible.

https://github.com/oxc-project/oxc/issues/6073

I keep trying the "native" solutions every so often, but every time I quickly hit some snag that makes me question why I'm not just using the solution that actually works. As an example, I just generated a new project using create-vite & added two subpath imports:

    {
        // ...
        "imports": {
            "#assets/*": "./src/assets/*",
            "#/*": "./src/*"
        },
        // ...
    }

    import router from "#/router/index"

Now, imports from e.g. "#assets/main.css" work, so I could work around this issue - but this is what I keep experiencing: the native variant usually kinda works except for the most common use case, which is made unnecessarily awkward. For a long time this is what ESM used to feel like, and IMO it still does in places (e.g. directory imports not working is a shame).

Thanks, I will consider this workaround later on.

Another instance is the use of rollupOptions.output.manualChunks that now has to be rewritten, maybe that would be less frustrating to fathom.

Probably. It's just that I've always used .js for my projects (decades). Such a rename would likely result in configuration changes to the other tools I use, but indeed they are better documented. When faced with a multiplicity of conventions I pick one and stick to it; the tools are flexible enough to work with it I'm sure, the real issue is of discoverability.

but it has plugin support? what kind of plugins you mean?

[flagged]

It has worked perfectly fine with compiled languages until someone had the idea to use V8 outside of the browser.

In fact it still does, I only use node when forced to do so by project delivery where "backend" implies something like Next.js full stack, or React apps running on iframes from SaaS products.

> ... it's a much bigger ask for server-side app logic where teams lean on JS and its libraries.

Well that's where they went wrong.

Why go halfway, embrace compiled languages in the backend.

Fast all the way down, especially when coupled with REPL tooling.

Anything backend related.