It really is - writing a svelte component feels like writing something in vanilla html/js/css, but you get all the advantages that come with a framework.
This is the primary reason I love working with it. Coming from the times of jQuery, I can think in those terms like I used to and don't have to constantly translate it into React patterns.
Compared to all the weird rigamarole in other frameworks, the `$:` syntax is one of the least offensive compromises I've come across. Virtually nobody uses label syntax, the `$` is unlikely to clash with existing labels, and it means it can be easily parsed with non-specific JS AST parsers.
You're not the only one. I don't hate Typescript, but I don't think it's necessarily worth using everywhere. I like using it for libraries that I might share or reuse, that contain some complex logic, in which case it helps my code keep guarantees. But for view-layer code, I really don't get why a lot of people are dying to use Typescript that way.
Beyond that, pretty much every Typescript project I've been introduced to suffers from just as many bugs as codebases that use plain JavaScript. Strict typing at compile time doesn't replace conscientious development practices and rigorous testing.
> But for view-layer code, I really don't get why a lot of people are dying to use Typescript that way.
"view-layer code" is underselling how complex many modern webapps can get. When you've got 10+ engineers across 2+ teams running around in your 30,000+ line codebase, TypeScript offers a lot of benefits and makes overall iteration speed much much faster.
You don't need TypeScript for small/personal projects though. As long as everything fits in your memory, you're fine.
Typing only eliminates a certain class of bugs. And user-defined type systems scare me. I loved ReasonML precisely because you got typing (and confident enforcement) for free through the HM type system, but TypeScript always struck me as the embodiment of "now you have two problems"
Agreed. If I'm dealing with strong static types, good inference (and TS / Rust / Whatever ain't it) is a must.
'
If I'm going to invoke a bunch of ceremony every time I blink might as well write Java.
Haha, yeah. I justify this decision by assuming that designer-folks wouldn't be afraid to touch the code if it were JavaScript but would it were TypeScript. :)
To me JavaScript does a great job (if you know what you are doing) and if you're working on a reasonably small project.
Cool idea, and I really like how the site still functions for readers with JS disabled, which is (as far as I'm aware) uncommon for this sort of thing.
One thing that isn't clear from reading the GitHub page — do all visitors end up downloading the editor payload or do only admins who are logged in get that?
Excellent question. They do end up downloading the extra payload at the moment. It's something that could be optimized with `await import` in the future.
My general approach to this is considering website development as "minimal web app development". Think of it as developing your very own little Facebook thingie, where people could log in and post and edit stuff, without thinking about the technicalities.
My feeling is that, thanks to abstractions like Svelte, this is not super difficult anymore and my hope is that in many cases this approach could replace integrating a CMS. At least for me it feels much more natural like this, and really all I have to know is some HTML+CSS, the SvelteKit API and SQL to model my content. Just like in the old days, where you didn't have to depend on 100 things to make a website. :)
Postgres + S3 is a great choice but is there any limitation on changing it to SQLite + on disk? Thinking that this could be easily deployed to serverless+disk like fly.io without additional components.
This is the same flow as Frontpage had in 1998. You edited a live-edited your site, and when you clicked publish, a static site was deployed to the world.
Sure, and Concrete5 in 2003[1]. Hard to beat editing directly (as long as you also have authentication handled) though it might be slower, if you have to tiptoe around formatting.
I think this pitch overstates the problem with CMSes. It seems for many organizations, their CMS is working well for them. Not saying this doesn't have benefit, but, as for me, I rather like my CMS and don't feel like this is a big win.
> It seems for many organizations, their CMS is working well for them.
I hope to work in one of such orgs some day because the most common experience I've witnessed was pain.
And things don't improve when you throw more money at a CMS. There's an entire industry of enterprise CMSs (yearly license in five figures) and their users aren't any happier with their CMS than WordPress users.
I'm coming from a minimalist perspective. Of course a hand-crafted site like this template doesn't cover all the enterprise CMS use cases, such as image manipulation, video transcoding etc. It's not a one-size-fits-it-all solution but for for me personally, it speeds up things and gives me 100% control. I'm the person who'd rather invest in developing a FFMPEG API endpoint tailored for my application than pulling in the complexity of a CMS.
This is a huge step down from the experience of many CMSes. Controls are limited and don't really work for building a page. Maybe convenient for very small text edits like spelling fixes but not at all a replacement for a more in depth editing experience.
A full-featured CMS includes editing workflow I think: so an intern writing a press release has to have the article checked by an editor and maybe the legal department before publication, with corrections or comments included. At a pinch you could use Google Docs but that comes with more friction - hard to preview the content on the site etc and it's not so easily enforced as a locked-down CMS workflow.
I'm currently looking for something even more limited and lightweight, where I, as a developer, can just deploy a static site regulary (e.g. built by hugo), but with a few small sections editable on the front page, like a vacation notice, job openings etc.
Moving everything to a CMS or something like this, seems a lot of work. I'm looking at just using server-side includes for those sections, but haven't found a good editing frontend for that. Just exposing a single file in a git repository and deploying that via some build infrastructure (e.g. build.sr.ht) would be another method. Some live content preview would be nice in either case...
A surprising number of sites don't even need new pages dynamically, like blog articles, but just rather minor edits to a small subset of the content. Small businesses, medical practices etc.
This is awesome!
Admin panels are fine to me, but honestly this is a much more beautiful and productive approach. Very cool project.
Is an Astro template/integration a possibility? I'd love an editable static site that triggers Netlify builds. I actually have an Astro project on Netlify CMS that I wouldn't mind moving to this.
Yes, the challenge is taming contenteditable. I'm using ProseMirror under the hood with custom models for <Plaintext> and <Richtext> editing, which you can adapt to your needs. One limitation (of ProseMiror) is that you don't have shared undo/redo across multiple editable areas. That's something we've solved with our own library Substance.js a while ago, but the API would be too verbose for this type of use-case, and we didn't reach that level of stability that ProseMirror has today. Web-based rich text editing is a very interesting space to watch, that imo affects web development in general.
As far as I understand it, the dynamic website you use is the same as served to the client minus the editing parts?
Would it also support a scenario where the dynamic part runs on one host, say inside an intranet and users can "publish" to pre-configured static hosts or s3 buckets with a click?
Static hosting could be enough for many sites and one could combine the technical and UX advantages of your dynamic interface with the advantages of static sites for security and distribution.
I found that useful when i worked with https://www.getlektor.com/ years ago. In lektor the dynamic part runs on a users desktop machine, but it of course wouldn't need to.
Incremental Static Regeneration could help here, but it introduces a whole category of implementation challenges. It may be worth it for high traffic websites but one beauty of the purely dynamic design is that you can mostly forget about all "build" and "caching" problems.
Anyways, at this point I'm just happy that my 0.2 vCPU / 512 MB Node.js instance on Northflank survived a HackerNews spike at 60% CPU max.
Thinking about it some more, I agree that a having "static mirror" of the editable site might be a nice thing. But that's for another day to implement. If someone else does I'd be curious to see it in action!
At this point, that's like being proud you write in assembly while all the hipsters use C++. Or it's like being proud you don't use any libraries in Go.
Build steps aren't evil. For most projects, you never even touch them. You use a project template and then you're done.
What you get in return is an amount of work no human can do by hand: type-checking, tree-shaking, cross-browser shims, image optimization... it's a huge list.
At this point, I wouldn't hire someone who thinks build steps are a waste of time. Programmers should know the value of automating complex manual tasks.
What sticks with me in a way that I don't love is that this and many other modern, simple-ish solutions to having a lightweight CMS still relies on some Postgres config. I'm being picky, but I want a DB without having to think about the DB at all. Just templates plz.
I really enjoy and appreciate the demo on the landing page.
My only problem with this as an alternative to Wordpress are the claim "Put your cursor anywhere and make changes" or "Your website will do exactly what you need it to do". I see that I can clearly change text anywhere, but how do I change the template or the layout? How do I add a three columns section?
Making changes in a visual editor like Elementor is extremely easy even for non-technical people, which is why it's so mainstream.
These two claims you mentioned are directed towards the end-user, need to make that more clear maybe. The template is aiming at frontend developers, who want to control the layout in code, but allow end-users to make content changes (without having to learn anything).
It's not a page builder for non-technical people. But as a developer or agency you can offer your clients, that you build a website for them, that they can then self-maintain without any friction.
CMSs really are painful. I've spent more time making Ghost work on domain.com/blog (despite content marketing being one of the main reasons to drive people to your website, Ghost doesn't support this) than I have to write a CMS before.
Yeah it's essentially bare-metal web development. Thanks to Svelte and ProseMirror, it's just much easier to enable functionality, which would otherwise only be possible through a CMS. It uses Postgres, but you could use any other database as well.
From a cursory look, the type of content it supports seems limited. Like something you would use for a minimalist journal. If it could replicate something like https://framer.com I'd be all ears. A gallery with code would help potential users better understand its potential.
yah, this is like the todo app of content management, being able to change the text (and perhaps add bold and some links), and has probably been built thousands of times by now in the short history of the web. building in-place editing for fixed text nodes isn't that hard, whatever the underlying toolkit. a CMS should be able to do that in its sleep. it's when you get beyond text into other media and into layout, spacing, color systems, and dragging-and-dropping arbitrarily interleaved blocks of those things where it actually gets useful (and impressive).
To clarify: It's a different concept. And it's more of a starting point, rather than a solution. Its goal is not to build full-fledged a page builder or prototyping tools (such as Framer or Webflow). The layout is entirely up to the developer (and expressed in code), the content (as in structured data) is made editable. It's how Facebook/LinkedIn/Twitter/Medium etc. work, with the benefit that in many cases, you can edit within the layout. Image upload, drag and drop is all possible. The limit is what you can do with Svelte.
I think you should emphasize that it is based on svelte. You can't fairly call CMS and No-Code solutions complicated when you expect users to know Svelte. That limits your audience to the kind of people (front-end developers) that aren't desperate for such tools. I am using Framer on a project and I'm pretty happy with it.
If you want to go commercial, you could develop a platform for others to contribute building blocks and templates. Something that will pave the way for a no-code tool.
Exactly. This is for frontend developers, who want to control the layout in code, but allow end-users to make content changes (without destroying the layout :P).
If you or your end-users prefer to also define layout and style in a visual interface, that's what CMS and No-Code tools are made for.
As for earning money: I was thinking of creating specific templates (e.g. an editable artist portfolio website) and sell those at a one off price (in a similar way that Tailwind offers paid website templates). But I'm also really happy to do custom work. Like someone comes with a design and I execute it using this approach. I think there's much value for people who want a website but have not technical experience and still want to keep the content of their website up to date themselves. I could offer training for frontend developers to build editable websites with Svelte.
You can always develop sites yourself, but tools are more profitable. "Framer/Webflow for front-end developers". Occupy the niche between framer/webflow and pure Svelte; make developers' work easier?
Yeah I'm a bit undecided. I'm more obsessed with pushing quality than with operating a SaaS business (which can easily turn you from creator to manager). Let's see where this leads. For now I'd be glad to help people with their websites/apps. It's fun and rewarding!
I edit the website and then refresh and changes don’t persist. Obviously they don’t want people editing their production website, but is it otherwise supposed to persist? If not, what’s the point?
"CMS-free" as in "does not depend on additional software to manage content". Postgres and S3 through MinIO are my preferred choices, but you can change that to anything you'd like to use instead.
Glad you like the in-place editing. I'm also for the first time happy with the experience. You can press CMD+E for editing and CMD+S saving, and there's no layout shift, so it's really convenient for quick edits. :)
> "CMS-free" as in "does not depend on additional software to manage content". Postgres and S3 through MinIO are my preferred choices, but you can change that to anything you'd like to use instead.
Cool! Postgres and an S3-compatible object store area are both listed as requirements, so you may want to update that.
So by "does not depend on additional software", does that means I can just use the filesystem?
My favorite part of SvelteKit is the interactive tutorial (learn.svelte.dev). I suspect that sometime in the past few years, I lost the ability to stay focused with traditional documentation.
When we enter the space of non-open source interactive website builders, I believe this list could be extended to a never-ending stream of products. Maybe this isn't exactly true, but at least in this market segment there is more than enough competition.
Intentionally there isn't. I wanted to demonstrate that a website with "editing" capabilities is no magic, and to encourage people to hack on every piece.
My experience after 25 years of web development is that often examples > libraries. Not always true, but I think particularly for websites it works well and gives you full control over every pixel to be rendered.
Yeah, that's a known issue. Mobile browser's shift the viewport (including fixed elements) when the soft keyboard gets activated. There are workarounds, but I haven't found a satisfying one that doesn't introduce other problems.
For now just click "Done" to bring back the toolbar (the selection will be preserved).
