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.
So to be clear, if I used something like Getform for someone to subscribe with email, how could I maintain a list of those subscribers and their emails in the context of Primo? Or could I not?
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.
It would indeed, you clearly worked long, and hard on this as such I'd like to ask (since you've used Svelte). What is something you wish you knew earlier (a feature or an approach) with Svelte that you've found invaluable?
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.
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.
Yep, that is actually a big problem (benefit?) with Wordpress, were all the code is redistributable because of the GPL license. So paid plugin developers are in this weird limbo were they are charging people for their plugins without telling them that the code is freely redistributable.
A plugin is a separate code module that wordpress loads, surely those are not bound to the wordpress core license. Extending wordpress with non-wordpress owned code does not grant them the right to push their license onto somebody else's completely unrelated code. If that were true, nobody would ever be able to sell a proprietary app on any linux distro. GitLab is open core yet extends the functionality with enterprise under a different, proprietary license.
Hey HN, it’s been about three years since you sent my open source CMS, Primo, to the front page (https://news.ycombinator.com/item?id=23820201), inspiring me to quit my cushy remote job at the height of the pandemic to work on it full-time (naive and impulsive, I agree). Life has been pretty interesting since then. I’ve burned through my savings, lost my primo.af domain name to the Taliban, and convinced my wife to become a dev/designer to help me.
But I’m proud of what we’ve built over that time, and seeing the incredible effect it’s had on people learning web development, putting up personal websites, and managing client sites has further solidified our belief in the power and simplicity of this approach. Today we’re excited to announce the public beta for Primo version 2, which introduces full on-page content editing, page building, and more.
I initially created Primo because I was fed up with building websites, and the nontechnical people I was building them for struggled to manage them. My freelance projects involved brittle WordPress themes and poking around dashboards and juggling plugins; accessing the site’s code was so complex that it wasn’t even in the question. As an agency dev, I experienced the complexity of building custom sites in monolithic CMSs and the heavy-handedness of using meta-frameworks and headless CMSs for landing pages and brochure sites. And as a coding instructor, I saw my students face the daunting landscape that people learning to leverage the web face today - CLIs and APIs, package managers and bundlers, frameworks and meta-frameworks . No approach existed that provided a streamlined and approachable path to building, managing, developing, and hosting websites - particularly for common websites (i.e. 90% of the internet) like blogs, landing pages, and brochure sites.
Primo is our attempt to build that tool. At a basic level, Primo is a CMS - it gives you the ability to easily manage website content - but its functionality includes the other concerns that also go into running a website, like page building, code editing, static site generation, and deploying to Github/hosting. Blocks are written in Svelte (i.e. HTML, CSS, and JS), so they’re reactive and style-encapsulated. By combining all these elements into a single interface, you can create, manage, modify, and deploy new websites in a fraction of the time. And since they’re static sites, you get all the cost, security, scaling, and speed benefits of serverless too.
Primo isn’t intended for people that prefer the WYSIWYG design controls of SquareWixFlow but instead for anybody who wants to leverage HTML, CSS, and JavaScript to fully control and customize their websites while providing a dead-simple content editing experience to themselves and their nontechnical friends/clients/collaborators. It’s for people who feel frustrated by no-code tools and proprietary platforms, and those who want something simpler that still offers the power of code.
Beyond that, Primo is an effort to keep the web in the hands of individuals. Our hope is that providing a more approachable tool for web publishing will move the needle on technical literacy and put free expression on the web in the grasp of anyone who wants it so they can’t be as readily corralled into black boxes and walled gardens.
If you’d like to be a part of that mission, or just want an easier way to build websites, I hope you'll consider Primo.
Hi Mateo, nice to see the project is still alive and evolving. I personally tried it about a year ago, and I found it really good for designing simple web pages with reusable and customisable components. But the content management system was the issue for me, I was hoping there would be a way to just drop markdown files in a folder for it to generate articles or blog posts following a template like a regular SSG.
We even talked about it briefly, and I then forked the primo repo and started implementing a custom method to convert the database entries into a files / folder structure, which was going alright but the reverse operation seemed tricky to implement and I ended up going down another road, building my own custom markdown SSG inspired by this guide : https://joshcollinsworth.com/blog/build-static-sveltekit-mar...
Anyway, my use case is probably not the one you are targeting, but I still think it would be a dope product if everything worked the same but instead of writing the project into a database it would be a dynamic files / folder structure that could be edited and versioned like a regular sveltekit project. Basically it would be a svelte-based SSG framework with a components library and a dedicated UI to complement the regular text editor.
Just dropping this in case someone reads it and wants to build it, keep up the good work.
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.
so, so excited to see you on the front page again Mateo! you're succeeding in an incredibly tough market which takes the full set of founder skills to execute. congrats!
Great work! I also come from an agency background, and it's refreshing to see content management systems that support flexible page layouts becoming more popular.
it's working for me :) i've been using primo for the last week to make my blog, and i feel more productive, and i've learned a lot. the forum is cool too. answers to a couple questions i had were already there. thank you for making primo.
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.
Looks like that's using lit-html templates inside Svelte, but not any custom elements.
Web components would be good because they're an interface that Primo could work with without relying on specific implementation details. They're also encapsulated with shadow DOM, and support interoperable composition (components can have child elements made from any other frameworks or library).
So you could still build blocks with Svelte, but also Lit, Preact, Stencil, Vue, etc.
In a similar situation, I was advising the https://blockprotocol.org/ folk on how to define some interfaces on top of HTMLElement to allow standardized passing down of data to blocks, instead of requiring React in their case. I don't know how far they've gotten with that.
This is really cool and how probably most people would prefer to message, hope you keep at it. But I’m worried about connecting my private messages to any service, let alone one this young. Would be nice to see something on the landing page to alleviate my fears.
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.