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