Comment by danielvaughn | Hacker News Reader

Comment by danielvaughn | Hacker News Reader

So I’m working on this side project. I don’t have a name for it yet but I’ve been describing it as “vim for web designers”. The idea is that you can build a website (or components) in the browser, similar to Webflow, but it’s entirely driven by a command language.

When I began the project, I told myself I wasn’t going to use a framework. After all, I’ve been doing this since 2009, I was working with JS for a long time before I ever touched a framework. And besides, the native DOM APIs have long been good enough. Right?

My god, it was an absolute slog. Marshalling data into and out of the DOM is so tedious and error prone that I began writing my own mini framework to save my own sanity. And then I remembered why I began using frameworks to begin with - because ultimately you’re going to be using a framework of some kind regardless, it’s just whether you want your own custom one or a community-built industry standard.

I do still think native DOM is great, if you’re working with small amounts of interactivity. Most sites that use React probably don’t need it. But if your product has even a little bit of nuance or complexity, I’d go with a framework and avoid the hassle.

In the end I migrated to Svelte, and I’m much happier as a result.

Hyper minimalist projects always end up re-implementing half of jquery or lodash. Much easier to just find a good library that does treeshaking like ramda and use it sparingly.

I will gladly reimplement half of those projects if it means I can avoid the JS build systems that break when I come back and try to build in a year.

And to be fair I’m sure the build systems have gotten better - they just all left a bad taste in my mouth. I spent more than enough time working with them, writing plug-ins, etc.

This was one of the reasons I really tried to go native. Once you introduce a build system, it has to be maintained.

I eventually did choose Svelte, but I’m dockerizing it so I can still use the thing a year from now, unlike virtually all of my other projects.

Take a look at nix-shell scripts. Much simpler, lightweight and fast. Start of a build script from a C project of mine:

  #!/usr/bin/env nix-shell
  #! nix-shell -i fish --pure
  #! nix-shell -I https://github.com/NixOS/nixpkgs/archive/4ecab3273592f27479a583fb6d975d4aba3486fe.tar.gz
  #! nix-shell --packages fish gcc gnumake gmp git cacert
  ...build script goes here...

-i fish: I am using fish shell.

--pure: Environment is as pure as it can reasonably get.

--packages: Packages from nixpkgs to be made available in the environment.

-I <github_commit_hash>: pinned to a specific git commit of nixpkgs. This script will give you the exact same environment with the exact same packages with exact same dependencies forever.

You can drop into a shell with the exact same configuration by using the cli command nix-shell with the same options.

Admittedly this is not as declarative as using flakes, since it's a script, but hey, I'm lazy, still didn't sit down to learn them once and for all.

Reference: https://nixos.org/manual/nix/stable/command-ref/nix-shell

This is interesting! I’ll take a look, thanks.

How’s that saying go? Choose a framework or you’ll invent one?

Yep, and it’s exactly right. It had been so many years since I’d worked directly at the DOM layer that I’d forgotten why I stopped.

That being said, it was equally difficult picking a framework that had the least likelihood to handicap me down the road. And I am still using plenty native methods, especially for the CSSOM. That has yet to be sufficiently abstracted into any kind of framework.

You are building application - I could estimate from your description alone that you're better off wrapping the DOM interactions.

For websites that need interaction, DOM manipulation is IMO a better move due to it using a more fundamental/universal skill, light or no build process, faster execution, and explicitness.

This is a categorization, with lots of room for grey areas! I bring it up because your use case falls squarely in the category that benefits from a framework.

Yeah, agreed. I was hoping I could lean into a quasi-HATEOAS approach, where the state of the editor is reflected in the state of the html output. My thinking was that if it's only in the html, then in theory it would handle very large numbers of nodes better, since you don't have to correspondingly increase the size of JS object in memory.

I'm still attracted to that idea, but it's not worth it in the short term.

sveltekit is all about SSR these days, svelte itself does not have a default client side router, I was trying svelte for csr spa and gave up

I’m using Astro for SSR and only using Svelte for the client-side state. It’s working out well so far.

With the view transition API[1], directory/index.html is/will be the client-side router.

1. https://chipcullen.com/adding-view-transitions-api/

Reply on news.ycombinator.com