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.
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.
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).
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?
OP mentioned the ultimate solution in their comment, it's Headless CMS (provide content) + fully custom frontend.
(or if you just have general feedback or learnings from your own experience, I'd love to hear that too!)
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!
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
I had no idea it used to be possible to register Afghan domain names from outside of Afghanistan.
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.
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.
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).
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.
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.
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 :)
Nothing against this particular project, but how many times are we going to recreate a wysiwyg cms. There must be hundreds at this point.
- 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?
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)
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.
> 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
How is this different from Strapi or Ghost?
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.
Appreciate it.
This is what I was looking for! Mad props to you for putting the effort into building this.
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
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.
Remember to check the project website content for grammar mistakes, e.g. using Grammarly, since small mistakes can tarnish the project image of professionalism.
Thanks for sharing. Nice work!
