3 ms·

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

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.

klysm 2y ago
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.
iamsaitam 2y ago
"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.
- deleted 2y ago
  [deleted]
- AmalgatedAmoeba 2y ago
  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.
  - iamsaitam 2y ago
    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.
  - skydhash 2y ago
    > 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.
klysm 2y ago
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?
emseetech 2y ago
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 2y ago
  IMO designers should read hypermedia systems by the htmx guy.
nonethewiser 2y ago
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.
only-one1701 2y ago
I get what you’re saying but people still write SPAs

klysm 2y ago

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.

iamsaitam 2y ago

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

deleted 2y ago
[deleted]
AmalgatedAmoeba 2y ago
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.
- iamsaitam 2y ago
  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.
- skydhash 2y ago
  > 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.

klysm 2y ago

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?

emseetech 2y ago

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 2y ago
IMO designers should read hypermedia systems by the htmx guy.

nonethewiser 2y ago

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.

only-one1701 2y ago

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