mmmateo

Ahh okay that makes sense. Just updated it, thanks.

Thanks for making it! And that's great to know - I've always wondered

Is your concern with the fact that clients can lay out their sites with blocks? Note that they can't edit any of the visual aspects unless you create a field for those specifically (e.g. making an image a circle or square).

If it's with not being able to use a local IDE - that is something that's currently possible by bundling your Svelte components into vanilla JS and importing them into your Primo blocks & passing along data as fields - but I'd give it a couple weeks before using it in production until we smooth it out.

But what you've described is essentially how I do my client projects - I build it all with code (usually reusing blocks from other projects) and hand off a site that literally any of my clients can edit on day one with minimal training.

haha good point, but no it wasn't intentional. Wanted to replace the hot red & black design I had before with something besides blue.

That's true, but it does communicate something important to companies and individuals looking to use, contribute, or build on the project to say what kind of open source it is, rather than just saying its open-source IMO. Would be interested to hear if you think it could be clarified though.

thanks so much swyx!

Could you elaborate? Tailwind CSS is MIT but it's still under a for-profit company.

> However, based on my long experience, you really don't want your client to touch the HTML/CSS of your site.

Certainly, and in the same vein you don't want your client touching the design of the site. Clients can barely write good copy, much less make good design decisions. My freelance projects go a lot more smoothly now that I can hand off the site to the client knowing that they're restricted to adding/removing blocks and updating content (and that they can't see the 'open code' button).

It's hard to think of something I wish I knew earlier tbh. Svelte (and SvelteKit) are just so simple and approachable that I feel like whenever I need to do something new I can just try what feels most intuitive and it just works. I've heard the same thing from a lot of other people too. If anything I would just keep an eye on reactive statements; I wouldn't trade them for the world but they can be dangerous if you don't keep an eye on them.

That's awesome! So glad you like it

I definitely understand with the struggle to balance design freedom and brand identity (or good design). But wouldn't you still have the issue of content editors wanting to right align text and turn it blue regardless of the CMS you're using?

Primo itself is a SvelteKit application, so I don't know how possible it would be to run it on a LAMP server, but you could certainly deploy the static sites it generates on one.

I agree! That's why Primo generates static HTML & CSS & only includes [vanilla] JS when its necessary to hydrate any interactive components. All using the Svelte compiler under the hood.

good point, shame I can't edit the title

Possibly for the database but authentication and file storage would still need to be taken care of

Ah yeah I forgot Dreamweaver does give you access to the code, in that regard it's similar. But, speaking as a user of Primo (and echoing what I've heard from a lot of other users), I haven't found anything that rides the line between no-code and code quite like this (especially open-source).

Yes Primo offers visual content editing and page building, because that's the only way to make a page flexibly editable by a non-technical user. Abstraction is only a negative thing when it stands in the way of what you want to do. Page building abstracts copy-pasting code. Visual content editing abstracts writing editorial content in HTML. Styling & building is the one thing that's left up to code because it has so many more possibilities than laying out blocks or writing content. So in the sense of building, Primo is the opposite to visual site builders like Webflow, Squarespace, Wix, etc.

I think that's why a new site builder pops up every other day - because they're all attacking the problem from different ends of the spectrum. Some give you more control, but are more complex/professional (like Webflow), while others are easier to use but offer less control (like Squarespace), and others are tailored to particular industries.

I just tried it out with web components using Lit and it seems to work pretty well (https://i.imgur.com/PFvMgFp.png), allowing you to pass in on-page editable fields. But I'd be interested to hear where web components would work better than static/hydrated components.

This looks perfect! Just signed up

Totally understand the interpretation, but if you take a closer look I think you'll find Primo is actually the opposite. Site builders like Dreamweaver, Squarespace, Wix, Webflow, Weebly, etc. (and even WordPress now) replace code with visual controls - bridging the gap between users and their websites, but also putting up a wall that keeps them from modifying the code directly (or at best, applying some custom CSS on top of it). Primo, on the other hand, bridges the gap directly to the code, which means the interface doesn't get bogged down by toggles, sliders, and color pickers and users are never limited to just the subset of the underlying platform pre-ordained by whoever built the tool. That's the beauty of code, and it's what excites me most about Primo - that people who would otherwise think code was outside of their reach would realize it's actually something they'd be good at and enjoy.

Thanks so much! Would love to hear how it works for you & help where I can. Lots still to come :)

The biggest difference from any existing CMS is the integration of a code-editor and Svelte components, but also the on-page editing is more user-friendly than most CMSs or site builders.

Specifically: It’s a monolithic CMS, unlike Strapi, so you don’t need to include an SSG to turn your content into code. And Ghost is more of a full-featured service for online publications where Primo would be better suited for smaller bags, landing pages, and brochure sites.

No, you’d use an external service for stuff like that (I use Getform for emails).

Thanks! I could definitely see the value in that. Once we make it possible to fetch content dynamically it should be easy to fetch Markdown from a repo and render it anywhere on the page. Or it might be simpler to keep SvelteKit/Astro for that since it does it so well and just use Primo for the non-blog pages, which is currently possible.

I’ve always appreciated how Svelte keeps things as simple as possible without sacrificing capability, and how that results in more productivity and enjoyment in building. Really this is a visual layer over that to make it even more approachable.

Definitely possible in the future, although to keep the project focused I'd imagine using a plugin or fetching that content from a separate CMS tailor-made for that kind of content would be ideal.

Thanks! And yeah I agree it's a bit mislabeled; the goal was to enable people to put up their own server as easily as possible, which meant plugging into those services. We are working on decoupling the backend so you could self-self-host it though.

Yup! Makes it super easy to spin up a server. We're working on making it backend-agnostic to open it up to more people, but Supabase has always been my go-to.

Sure thing! Just changed it from AGPL actually. It would be ideal if anyone forking it would contribute changes, but I was worried that would keep them from using it to build internal tools or separate products, and all the underlying tech is MIT anyway.

Sweet! Let me know if you need any help