Show HN: Primo – a visual CMS with Svelte blocks, a code editor, and SSG | Hacker News Reader

Show HN: Primo – a visual CMS with Svelte blocks, a code editor, and SSG

primocms.org

356 pointsmmmateo117 comments

The drag-n-drop blocks/slices of content CMSes look cool in demos. As someone who has an in-house developed CMS editor just like this, it's a nightmare of constant updates. "Can we right align text and turn it blue?", "sure we'll add more and more props to each block". The actual content creators have a hard time using it effectively. So the results are almost always unsatisfactory. More training could possibly help but there's still a constant tradeoff between freedom and maintaining brand identity.

A headless CMS in our case would be a better approach. Simply provide the content and let a few professional folks code it up to match designs. Not everyone has that luxury I realize - so there's definitely a place for this type of CMS. I'm just pointing out how it can go horribly wrong.

Context: I'm the creator an open source page builder in Ruby on Rails named Maglev (https://www.maglev.dev), pretty much similar to Primo (congrats for their product, looks amazing!).

A couple of months, I used my own tool (Maglev) when revamping an e-commerce site of a client who didn't have a content management system to edit the marketing part of her site. So I sliced the site into editable "Maglev" sections/blocks. The result was great in terms of editing experience BUT a couple of months later after the launch, my client hired another marketing person with HTML/CSS "skills" (I'd say 101 HMTL/CSS level). And I had a hard time to convince her that it was a bad idea to write HTML/CSS code herself but instead to let me (or another developer) write the missing sections she wanted.

A solution would have been to add in Maglev some kind of dev editor like in Primo. However, based on my long experience, you really don't want your client to touch the HTML/CSS of your site. And I don't believe in the "you break it, you pay for it" mojo or at least this is not the kind of relationship I want with my clients.

On a higher level, any kind of CMS has the same issue. For instance, I helped a company with a broken Webflow site and it was the typical issue: a designer built their site and later the marketing person tried to "improve" the UI and broke everything.

> 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).

Thank you for Maglev - looks awesome

"A headless CMS in our case would be a better approach" doesn't the client just get mad they can't do what they want? You can only build so many components.

Ideal world is a CMS that allows clients to easily change the HTML without code. That way it loads fast, has great SEO and stops developers re-inventing the wheel.

That was the reason I built https://versoly.com/ (Website builder + CMS), why does the client have to contact you to change the background color or add a new section?

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?

> 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?

OP mentioned the ultimate solution in their comment, it's Headless CMS (provide content) + fully custom frontend.

I'm building a GraphQL based headless CMS currently, ~2 months away from an official launch. It's currently wholly lacking official documentation but feel free to give the index page a peek and see if it's something you'd be interested in trying out!

(or if you just have general feedback or learnings from your own experience, I'd love to hear that too!)

https://brick-cms.com/

Yup! That's the avenue we took. A React app as an editor, content blocks are represented as a large JSON structure. That structure is stored in a DB via Drupal. (The editor is actually jacked into the Drupal page editor). We use GraphQL as our integration service. There's a shared "blocks" library so the editor can do the layout, store the JSON and the front-end website can interpret that JSON and use the same library to rebuild the component structure. I will say that it's a neat system. Some folks are VERY attached to it. I don't feel it fits the business needs so I'm investigating other options.

Best of luck on your CMS! I'm always intrigued by what others build - so please don't take my experience as any sort of criticism - I'd love to see your project succeed!

How do you feel about a Shopify approach where you use a pre crafted template, and have developers make tweaks to it if you need further features?

I love the idea. Telling our content folks, "you can choose 1 of 8 different templates" would be great. In actual practice it's more like, "Ok, we want to use part of that template and we need to modify part of that other one - marketing wants this live in 30 minutes'. So, giving them the "blocks" approach has worked for delivery. Frankly I'm embarrassed at the results it yields.

Github: https://github.com/primocms/primo

Previous discussions: https://news.ycombinator.com/item?id=23820201 https://news.ycombinator.com/item?id=25301040

Show HN with some text attached from what seems to be OPs alt account: https://news.ycombinator.com/item?id=36801101

Sigh.

I presume SSG = Static Site Generator

(Does anyone actually try to write clearly for people who even slightly not keeping up with their specific domain? I do webdev and even I had to think for a moment to decode the acronym)

I think most people who know they need an SSG know what SSG means. But yes, it might be more helpful for users who don't know that yet.

I know what a static sure generator is and I've used one (briefly).

But the acronym is unfamiliar to me and it took me a moment or two. It's bad form and we should do it less often.

good point, shame I can't edit the title

I wish there was something like this, but for serial dynamic content, like blog posts, reviews, etc. People are really attached to WP, but customization and themes are a nightmare.

Take your pick https://jamstack.org/headless-cms/

Not sure if this is what you’re after but give https://getkirby.com/ a try

That’s a bit more expensive than I’m open to for some random personal website.

Try https://craftcms.com

I think people are attached to Wordpress for the same reason we are attached to Javascript. At the time, it was one of the only ways of easily creating a blog.

The problem with Wordpress is that once you need to do something outside of the norm then all of the sudden you need deep knowledge of Wordpress's inner workings.

There was never a time when WordPress was the only easy way for even a non-technical person to create a blog, they just did a great job marketing that that was the case.

I spent a very brief time as a contributor to WP internals (not core by any means but a handful of contributions) and not only do you need a lot of internal knowledge to do anything outside of point-and-click, like you said, a lot of the core folks had never worked on any other large software projects, didn't do anything outside of WordPress, and had very little desire to make sure what they were doing was sound from a software engineering / code quality standpoint. It's a pretty great example of the big ball of mud / spaghetti code cliche.

From a social standpoint, it was though. You could ask a lot of non-expert people for help on Wordpress and get it.

That's exactly what I mean. They did a great job making people think that if you wanted a blog and weren't a programmer, WP was your only choice.

Ok I will bite. What was an alternative to WordPress especially back then that actually was as easy to use as WP AND had the ecosystem of plugins that WP has. Focus on non technical users only who have no idea how to write code.

You're correct. Alternatives were slim. But in retrospect, perhaps that was part of the problem? WP had zero incentive for clean code, QA, industry standards, etc. The more it grew, ironically the less it cared. The embedded base of site and dev as well as the plugin and theme ecosystem maintain the momentum forward, somehow.

The main competitor was Movable Type.

I recall there being several other also-rans, but am having trouble recalling names.

Movable Type was pretty great, but it also cost money. The open-source era of MT was brief and after its primary period of relevance.

I don't think it was even the marketing but the product placement. I remember in the 2000s if you wanted hosting that wasn't a dedicated server, the scene was dominated almost entirely by CPanel with a one click installer for Wordpress.

Once the plugin ecosystem sprung up around it, WP was off to the races.

wp can be the choice for an e-commerce site.. woocommerce is pretty good and hard to match

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.

That sounds like static content to me, what's wrong with just HTML?

It's not really static. It grabs data from a database, or an API, and renders using entity-specific templates, both from a single entity perspective (post.php theme) and listing (search.php, index.php).

What I mean is: having something like Primo that allows visual management of such dynamic blocks and themes would be nice, so Editors can just play around with the result of their content calls (which the CMS handles transparently, doesn't matter if a SQL query or an API call).

That is static - none of it is based on user input so it can be compiled into a static HTML page every time you publish a new post or edit a page theme or anything. There's no reason the system needs to pull that 5 year old blog post from the database every time.

That depends on the desired features. E.g. if you have a tag cloud displayed in the sidebar on each page, author list, etc., any change to any post could potentially mean all pages have to be rebuilt. Or if you have different ways to display items (full, thumbnail), different ways of sorting them, and maybe even variable pagination (i.e. "show me page 7 with 15 items per page"), and it can very easily become unfeasible to statically generate all possible permutations. In the context of "systems that allow newbies to get results" this may not be as important, even there you might want to have little neat things like displaying relative dates. Dynamic doesn't have to mean user input, it just means dynamic. And then there's search, in case you want/need to handle that yourself.

A probably very naive solution to that I came up with and experimented with is keeping track of all things that go into a page, and tag the cache of it with them, so I could invalidate all cached items that refer to a thing that was just changed (where that thing can be anything, a tag, the site title, whatever), but I ended up scrapping in favor of caching everything for 1 hour no questions asked, because it was just total overkill for my use case.

How is it not user input? Editor can opt to show whatever in his list, playing with the external source filters: most visited, or last published, or less visited.

Once the editor is done with his work, if you want to compile a bunch of HTML/CSS and push to Netlify, that's fine. But his interaction with the CMS is not static at all.

Hmm, well if you consider that to be dynamic then editing html files in notepad is dynamic as well I suppose.

Did you https://github.com/TryGhost/Ghost ?

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.

Mateo

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.

> lost my primo.af domain name to the Taliban

I had no idea it used to be possible to register Afghan domain names from outside of Afghanistan.

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!

thanks so much swyx!

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.

That's awesome! So glad you like it

Would love to see this where blocks are standard web components and use native encapsulation!

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 incredible! I've worked with WordPress for a long time and have been tinkering with Svelte recently.

This is what I was looking for! Mad props to you for putting the effort into building this.

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

Nice project! I was a bit disappointed that you need a supabase account for "self hosting it".. And this is supposed to work only on some hosting service that can connect to Supa base, and also it encourages to fetch your pages content from github.. So it's more a CMS to run with specific service providers rather than something you can actually self host.

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.

sqlite or flat html files would enable the ease of self hosting without any third party external service dependencies

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

True but still, you can self host supabase as well. The only service really required is GitHub but I guess other providers (e.g. gitlab) can be added down the line.

Gotta agree, i'd prefer to use planetscale or turso, i mean supabase is cool too, but i'd rather have the option, or even just loading stuff to a local db on a webhost of my own.

Great project. But honestly, I reached to the point of “less JS” or even no js is better for developers and also users. I’m currently migrating my old blog to a new one that gets generated by Zola [1], and even my main portfolio site, which funnily enough I newly made it with React/Gatsby, but I’m redoing it again with Zola because of the performance gap is just unmatched, not to mention I personally sometimes browse the web with js disabled so if a website is completely non-functional or doesn’t even load because of that is a deal breaker. My old site years ago used to use jquery and I was annoyed by it to some degree, trying react and the likes was a nightmare!

[1] https://www.getzola.org

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.

Awesome, thanks, love the project I already signed up! Might give it a try on my company site if I found some templates for commercial sites.

It's almost unbelievable that more than a decade has passed since I created Stiqr, a site creator back in 2010. Although the site is no longer active, you can catch a glimpse of its remnants in a YouTube video here:

https://www.youtube.com/watch?v=B-ff53t8TuU&t=224s

Responsive designs got hot during that time (2010) and it made me shut down the project. But I still believe this is the way to go to build websites in the near future.

While I think the combination of drag-and-drop / blocks and Svelte is really awesome, this unfortunately sits at the wrong end of the spectrum for me.

What is is: a visual website builder where I can customise blocks using an online editor.

What I'd like: an online interface that clients can use to add / change text, or make other small adjustments, for Svelte websites that I build offline using my own tools. The idea would be that, as long as I build the website according to certain interface standards, it is readable by Primo and the client can modify using the visual interface. For any bigger modifications the client would come back to me and I have all the speed and freedom of my offline workflow.

Some might suggest that what I need is a headless CMS, but I have tried those and they are all over-engineered and giving me a big headache just for setup and maintenance.

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.

> Is your concern with the fact that clients can lay out their sites with blocks?

Not so much.

> 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.

Yes. As a developer I don't want to deal with WYSIWYG drag-n-drop interfaces. I want the freedom to develop using my already established workflows. What you suggest sounds like development for the Primo interface, i.e. Primo dictates the high-level structure and I can develop components for it. What I'd like is at the other end of the spectrum: I develop the entire website in Svelte and make it compatible with Primo by adhering to some constraints.

> 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.

Sounds like we're on the same page then :)

You might like https://github.com/michael/editable-website

What you say you’d like is what I’m looking for, too, but what you say Primo is doesn’t sound far enough off that I understand your complaint. When you say “customize blocks” I guess that doesn’t include changing the text? Or perhaps it doesn’t constrict the possible actions enough for you to feel safe handing it over to a client?

You might like Builder.io (https://www.builder.io/m/developers) - they let you embed drag-n-drop powered sections within your regular page markup, and it looks like they support most frameworks like svelte.

Surreal CMS solves that problem exactly. Setup is done by FTP.

Thank you. At last some glimpse of sanity among the freaking complex world of web dev. More power to the Rule of Least Power. [0]

[0] https://en.wikipedia.org/wiki/Rule_of_least_power

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.

> Is Primo open-core? VC-funded open source? Side project?

> Primo is under full-time development and is in the process of becoming a nonprofit organization. Any funds generated from White Glove and Cloud will go towards funding further development, in the same vein as Ghost CMS.

The above is a stupid answer, it’s open source and MIT licensed: https://github.com/primocms/primo/blob/master/LICENSE

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

Orthogonal. Many open source projects have companies behind them, that doesn’t restrict what you can do with the license.

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.

Your answer completely sidesteps the question though and doesn't mention that it's open source, which makes it sound like it's not

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

Y'all remember Macromedia Dreamweaver?

Nothing against this particular project, but how many times are we going to recreate a wysiwyg cms. There must be hundreds at this point.

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.

Primo is not the opposite. From the primo site, the 3 main bullet points

- Drag-n-drop page building

> Build your site's pages by dragging and dropping your directly blocks onto the page, unencumbered by overwhelming design options.

- Visual content editing

> Update your text, images, and links directly on the page or open up the Fields view to manage your content from a structured view.

- Integrated development

> Access each block's code with a click - right from your browser. And since each block is a Svelte component, there's no limit to what you can make.

That is functionality that existed in Dreamweaver since ~2000[1]

- Quick Tag Editor

> Bring the HTML source directly into the visual design environment. Use a keyboard shortcut to quickly access and modify HTML tags around the selected object on the page.

- HTML styles and cascading style sheets

> Dreamweaver styles give you desktop-publishing-level control over the text in your Web site. Quickly apply combinations of character and paragraph styles to text with the new HTML Style palette. Easily configure character and paragraph level styles for a site and share them with the entire development team with cascading style sheets. The choice between HTML styles or CSS styles gives you unparalled flexibility and control.

- HTML Inspector

> Roundtrip HTML lets you visually design your Web site without sacrificing control over HTML source. The HTML inspector gives you total visibility and access to HTML source. Edit, drag and drop, or copy and paste directly in the HTML inspector (which now displays line numbers).

1.https://web.archive.org/web/20001012150931/http://macromedia...

Regardless of the dreamweaver comparison, please explain how this is different, or as you said, the opposite, from any other site builder out there?

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.

From what I see they all offer drag and drop UI elements with the ability to dig into the underlying code if you want to. I'm not seeing a difference between all of them other than what the flavor of the week is in terms of lanugage powering the CMS. I remember when ghost was all the rage, and many others. Again, not crapping on your project, props to you for the dedication, and if you're happy working on it that's all that matters

I do, and about 20 other projects since. In my experience far from a solved problem. I mean, I remember IE3 too, how many times are we going to recreate the web browser?

Except we don’t keep making ie3, we’ve actually iterated and it’s now capable of much more. It’s not comparable to the 20 different drag and drop site builders that more or less are providing the same functionality and spitting out similar html

One of your themes shows an “email subscribe” field like one might expect for a blog with a newsletter. Does this have a concept of email subscribers and management related to such? Does this support transactional/batch emailing?

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

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?

Ghost has this functionality and is used by many https://ghost.org/

Thanks for chiming in! I actually already use ghost which is why I’m asking about this functionality here. =P

Looks like an interesting project and compelling alternative to Gutenberg.

Remember to check the project website content for grammar mistakes, e.g. using Grammarly, since small mistakes can tarnish the project image of professionalism.

Just what I was looking for, a happy medium between Wix and Hugo. Plus, nice intro to Supabase, which is also supa cool. Perfect for another project I am just starting.

Thanks for sharing. Nice work!

Great project though it reminds me of my desire to see a node based flat file CMS like Kirby, preferably with Vue as the flavor of templating.

Huh nice. Looks like it uses Supabase as a backend.

And as a frontend! I mean, I don’t mean this as a dunk, maybe it’s all cool with Supabase, but aesthetically it looks extremely similar, not just a little bit. Is that intentional? Do they encourage sharing their styles or something?

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

Don’t worry, we don’t mind. Thanks for using supabase! Let us know if you need anything to help with Primo - it looks amazing

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

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.

Thank you for using an MIT license :)

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.

There's no legal precedent yet, but WordPress plugins/themes are widely considered as being GPL because they're a "derivative" work.

Or, at least the PHP code in those plugins/themes are - possibly not the CSS + assets.

https://kinsta.com/learn/wordpress-gpl/

Looks interesting, will give it a try for a personal landing page.

Sweet! Let me know if you need any help

I wish the self-hosted option was more self-hosted

Great product!

How is this different from Strapi or Ghost?

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.

Ohh thanks!

Appreciate it.

Looks great, very snappy

As someone who has been working with WP since the beginning... Seems fun. Can you deploy it on a classic LAMP server? If not, it's not really a WP replacement for me. And I'm really looking for one.

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.

Reply on news.ycombinator.com