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