Michael Aufreiter

This is actually such a relief! :)

Thank you!!! <3

Hello! And thank you. Curious to find out all the ways you succeed or fail to break Editable Website! Please sign up for the TP!

PPS: Still think SQLite should be the source of truth for content (no external dependencies and no network between server and db) but the idea of connecting websites via @atproto.com to take part in a network/neighborhood feels exciting.

Got an @atproto.com crash course by @flo-bit.dev this evening. Learned a lot!

PS: We might experiment with wiring up editable.website with a PDS as a backend for storing pages, as well as figuring out how editable websites could best integrate standard.site for discovery.

You can also hook up your own multi-user auth system by overriding getCurrentUser

github.com/michael/edit...

There's an ADMIN_PASSWORD set for each site. You enter it at /login to create a session.

See:

github.com/michael/edit...

And:
github.com/michael/edit...

(v2 doesn't have the backend ready yet, but will basically work the same)

Thank you!

Would like to invite anyone who's building websites/apps in Svelte to join the technical preview of editable.website.

There's a link to a Google Form at the bottom of the page.

See you! 🙌

SQLite. You'd deploy a small Node.js application on a VPS where your site.sqlite3 file sits in a volume connected to that machine. Currently using Fly.io for deploying my own project, but could be any VPS or your own hardware on a Hetzer machine or something.

That's intentional. ;) All "editable websites" have that Cmd / Ctrl+E easteregg, though changes are not persisted. :)

That should work! :)

Nono, you'd change the markup directly.

I mean generally I believe you can have a standard set of content types, and then just adjust a few to give the site some personality. Fonts+colors and good images are in many cases enough to give the site a unqiue feel. No need for fancy-carousel No 1023. ;)

I have one real success story for Editable Website v1. A small shop for trail running equipment is weekly updating a "news area" on their website. They just press Cmd+E and put in new image + text. Wouldn't happen if they need to login to a Wordpress backend I believe. ;)

trails-shop.at

editable.website hopefully ticking the secure+cheap+ comfortable boxes. Full-of-features definitely not. :)

It's made for devs that want to have a single codebase for a website (no 3rd parties) and non-technical clients that "just edit content".

Does that make sense?

content

...content, and forget about formatting/spacing/colors etc. You can't break antything™.

So my target group are Svelte developers/agencies who build sites for non-technical clients.

Will not be the right fit for big sites with complex editorial workflows, etc. But for SMBs this could be a good fit.

Good points. In an earlier attempt we tried to give users also means to change the visuals (parametric design) but my takeaway was that this part just gets too advanced for editors.

Now in editable.website the programmer defines all content structure and design/layouts. Editors can only enter...

Thank you! It's been thousands of hours I invested so far, and it's reassuring I'm not alone with that idea. 😅

If you have ideas/questions based on the current tech preview, please kick off the first thread here:

github.com/michael/edit...

Would be glad to have you help shape the next versions.

I'll be looking into that. I'm hesitant to break self-containment and rely on a PDS for storage for classic websites, but I do believe that a Svedit-based editing experience for a standard.site compatible page would be very interesting to explore.

Thank you @fubits.dev!

JSDoc types are still very basic (will get some focus at the right time). But I think for this project JS+JSDoc is the right approach. Enables people who know HTML+CSS to build sites. And not worry about types. :)

I'm very careful that editing infra stays super slim, as it's included on every page. Currently ~3500 LOC.

Foundational bits are there, now dev ergonomics need to get better.

If you'd like to give it a try, I'd be happy to spend some time helping and answering questions.

(thx for your response!)

Idea is that you don't have a separate "content managmenet UI"

You define your content model: github.com/michael/edit...

And components:
github.com/michael/edit...

Editing infra is on the page:

import { Node, NodeArrayProperty } from 'svedit';

*your mind ^^

If you tried out the demo, and have fresh thoughts on their mind.

Please post them here: github.com/michael/edit...

Almost 3 years since editable.website won 2nd place at @sveltesociety.dev SvelteHack.

Since then, I’ve been busy turning this from a prototype into something solid.

A way to build CMS-free, in-place editable websites using only Svelte.

This is v2. 🥳

Kudos to @JohannesMutter for pioneering this technique of specifying "color surfaces".

Sneak peek: In Editable Website v2 you’ll be able to define a couple of colorsets (background, foreground, accent) in code. And then apply them with a keyboard combo as you edit your site.

Remember: for every thousand people speed-shipping an idea from last week, there’s an indie dev introducing their baby to the world after five years of obsessing over it.

For those (like myself) who need to hear it: Slow craft is great, too.

Yeah particularly the framework-inside-a-framework aspect is annoying. E.g. you write Svelte components, along with ProseMirror NodeViews, and it just never feels consistent and it's hard to bridge the data from one end to the other, especially with keeping reactivity intact.

I hear you! I also couldn't live with classic rich text editor "widgets". It needs to be a single consistent data structure, a unified undo history etc. That's why I had to build Svedit! :)

Would be curious to see what you're working on, once you're ready share.