[epolanski]

I have been writing recently an application in plain "vanilla" TypeScript with vite, no rendering libraries, just old-style DOM manipulation and I have to say I more and more question front end "best" practices.

I can't conclude it scales, whatever it means, but I can conclude that there are huge benefits performance-wise, it's fun, teaches you a lot, debugging is simple, understanding the architecture is trivial, you don't need a PhD into "insert this rendering/memoization/etc" technique.

Templating is the thing I miss most, I'm writing a small vite plugin to handle it.

[emseetech]

I take it a step further and go no-build js with jsdoc.

The hardest part about scaling this approach is finding UX designers who understand the web. Just as frontend devs have trained themselves to "think in react" over the past decade, so have designers. The understanding of the underlying capabilities and philosophies of the web have been lost to the idea that the web and mobile can be effectively the same thing.

This approach can go far if the team using it knows and respect web technology.

[designerarvid]

IMO designers should read hypermedia systems by the htmx guy.

[klysm]

If you look at it as a tradeoff space it makes more sense why the majority of folks are on some kind of react. What kind of problems do you want to experience and have to solve in a production setting?

[klysm]

The problems with this approach are exacerbated in a team setting. The architecture might be trivial from your perspective but good luck getting a bunch of other folks on board with different mental models and levels of experience.

[only-one1701]

I get what you’re saying but people still write SPAs

[nonethewiser]

Can you elaborate on website functionality, team size, and production readiness?

I mean I totally agree on small personal projects. Thats just never the limiting factor though.

[iamsaitam]

"I can also ditch a database and just dump everything into a text file." <- This is what you're saying. It isn't hard to see the problem with this kind of thing.

[AmalgatedAmoeba]

ngl, a lot of the times, an in-memory “database” that gets backed up to a file is perfectly reasonable. Even consumer devices have dozens of gigabytes of RAM. What percentile of applications needs more?

Just because a technology works well for a few cases shouldn’t mean it’s the default. What’s the 80% solution is much more interesting IMO.

[skydhash]

> an in-memory “database” that gets backed up to a file is perfectly reasonable.

We have org-mode, application configs, and music playlists as three widely used examples for this.

You switch to a database when you need to query and update specific subsets of the data, and there's the whole concurrency things when you have multiple applications.

[iamsaitam]

There's absolutely no problem with this. But it probably shouldn't be a best practice or default for the industry? That's what op was saying. I'd argue you're still better off using SQLite than doing it manually, but to each its own.