Clean front end architecture with SvelteKit (nikoheikkila.fi)

   "I don't recommend having components responsible for querying data because their responsibility is already in presenting the data. More accurately, components need only receive data from view models, format it, and output it to the screen. Instead, I advise you to follow either of the three following ways:

  Render the data on the server and pass it to components as a view model, as shown in this guide.
  Use a state management library that supports dispatching actions (e.g. Redux or MobX), deriving view models from the state, and passing them to components as properties."

This is opposite to what Next.js new React Server Components stuff is advocating for in the new app/ dir structure. It expects every component to fetch the required data, and just cache any duplicate calls. It's probably good for a Serverless / Edge deployment but I much rather use a MobX store that takes care of state, fetching and mutations.

  async function getData() {
    const res = await fetch('https://api.example.com/...');
  
    if (!res.ok) {
      throw new Error('Failed to fetch data');
    }
  
    return res.json();
  }
  
  export default async function Page() {
    const data = await getData();
  
    return <main></main>;
  }

  const character = await characters().load(id);

Objectively your application has already been designed by the framework you choose. It tells you how to do and where to put most things and it also does all of the heavy lifting, a.k.a. actually doing something useful. The design the application developer needs to be concerned with is how to split functionality into reusable components where it's needed. I mostly see big fails here: a lot of kind of best practice theater, but what you end up with are very complex components doused with concrete.

I also see some straw man arguments, e.g.

> Developers dislike design because it's time-consuming.

I've never met a developer who doesn't like to design. I'd say the vast majority of developers even if tasked with something as simple as creating a button first try to craft a universal solution that can somehow be reused. Instead the correct design methodology most of the time is called KISS. You can always make it more complex later, but making it simpler is usually a lot more difficult.

I view premature abstraction as a type of premature optimization mistake, this is how senior dev bad code is written a lot of the time either because of faulty generalizations and anticipation or a strict adherance to some principle they don't really understand.

Because frameworks are sets of premature abstractions it really depends on how they do it and how much of benefit they provide compared to other existing solutions. I think we came a long way and SvelteKit really does provide minmal bloat and redundant complexity.

There's nothing stopping you to use Redux Toolkit and RTK Query in Svelte. It may not be "clean" from an OOP perspective, but it is trivial to test, mostly without mocking, it is easy to reason with, and even less code and complexity than what this blog tries to push.

When developers talk about a "clean way" to do things, I immediately think of overconfidence. Can't help it.

[flagged]

> Long gone in the past1 are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites.

Most of the websites I visit are static and when they are not their dynamic content is annoying. Look at new vs old reddit for a good example.

Most websites would be better off being statically rendered.

SvelteKit's routing pattern is anything but clean. It uses filesystem based routes where every file is called "+page.svelte" (or +page.server.js/ts for API only routes).

For anything but a demo app with just a couple of routes it's a headache to navigate.

Edit: Another smell of the routing system to me is that you need to resort to complexity like this [1] to have anything but top down inheritance. I love Svelte btw and have used it in many projects.

[1] https://kit.svelte.dev/docs/advanced-routing#advanced-layout...

> Long gone in the past are websites that purely displayed static, seldom changing content to visitors. Today, almost all user interfaces are web applications instead of websites.

Erm, how much of the web is still powered by Wordpress, again?

> Developers dislike contributing to a legacy codebase with high technical debt.

It's more than an aesthetic & workflow preferences. It's also a client management risk. Clients who have no development experience are often used to the same level of productivity to create the initial feature set. As development slows due to maintenance & performance issues, the client does not understand why. Clients also will use analogies, such as a mechanic overcharging for work & using words the client does not understand to justify high fees & billable hours...without understanding that changing a complex system with many undocumented & haphazardly implemented parts can create bugs.

Enter a maintenance project at your own risk. Due diligence of the business, codebase, and client's temperment, understanding of software development, decision making, & payment schedule can save you from headaches over the next few months.