This should be Drupal Starshot's Destination

This article originally appeared on Symfony Station.

I won't beat a dead rocket launcher. Many people have written good reviews about the Starshot announcement. If you read our communiqués you have seen plenty of them in recent weeks and there will be more to come. In fact, the leadership team was announced today.

Instead after a quick introduction to Starshot this article shares my vision of what it should become.

The stated aim of Starshot is to make using Drupal easier. Which is great, because any and everything about Drupal needs to be simplified. Especially its poor user experience. I have written about this before.

This initiative should have happened years ago. And I don't have much confidence it will meet its timetable.

But, better late than never. And I do think they will get there eventually.

Background for Drupal Starshot

Before I start with my vision, here are some background resources:

• The official Starshot page
• Dries's announcment at DrupalCon
• Mike Herchel has the best review

Starshot's official raison d'etre is:

''Starshot will be a fast-moving Open Source product that enables site builders without Drupal experience to easily create a new Drupal site and extend it with pre-packaged recipes, all using their browser. It will guide site builders to install recipes for common use cases and innovative capabilities that are immediately useful for production. It will focus on getting people from install to launch really fast and will bring new people and contributors into Drupal and the Open Web."

And it aims to achieve this with:

"A package built on Drupal core, including refined common features from the contributed project ecosystem to create a great user experience out of the box. Starshot is built on top of results from recent initiatives like Recipes, Project Browser, and Automatic Updates to take Drupal to new heights."

This is the most important thing Drupal has ever done

If you are a follower of Symfony Station, you know a large part of our mission is to protect democracy. And we do that by fighting big proprietary tech. We do it with open-source software, protocols, websites, and social media.

But, this freedom tech has to be easy for everyone to use. We need the average user to be able to fight big tech tyranny and counter its surveillance, misinformation, and censorship. We can't rely on developers only if we want to protect our freedom. The success of Starshot is important so democracy's protectors don't just have to rely on WordPress for their CMS. Niche Fediverse blogging is not ready yet. But it's improving.

So, it's vital that Drupal can also be an ally to the Fediverse and other defederated technologies in the fight against authoritarianism. Of which big tech is a natural ally. C^nt billionaires and today's monopolistic capitalism hate democracy and are actively working to destroy it. All they care about is more control and money. And many developers are happy to be their foot soldiers.

A quick rant. Speaking of said foot soldiers, if you can't keep from working with the enemies of freedom, at least unionize and try to reign them in. You might even be able to keep your shit job. Rant over.

And of course, Drupal has an Open Web Manifesto and Starshot can strengthen it.

Starshot's Goals

As you would expect Drupal core will be included with Starshot.

Drupal's goal with Automatic Updates "is to implement a secure system for automatically installing updates in Drupal, lowering the total cost of ownership of maintaining a Drupal site, improving the security of Drupal sites in the wild, and lowering the barrier to entry to using Drupal."

They have been working on Automatic Updates for eight god-dammed years, so who knows if it will be ready by Starshot's end of year deadline.

The goal for Project Browser is to make it easier to find and install modules for people that are (1) new to Drupal and (2) site builders.

I have more faith in the Project Browser team.

Recipes' goal is a feature in Drupal called a “recipe” that can be installed at any point in the lifecycle of a Drupal application. This includes during installation through the Project Browser, which overlaps with the selection of distributions in a Drupal application. They are available now.

I wrote more about Recipes in Cooking Up Convenience - Symfony Flex's Recipes and the Drupal Recipes Initiative

Recipes options should include:

• Blogs
• Publications
• eCommerce
• PWAs
• Government
• Education
• Healthcare
• Non-profit
• Headless
• Portfolios
• and more

Here is a current list of recipes. Which are mostly generic. If you want to try one now, here are the docs.

Maybe current distributions could be converted to Recipes or build off Starshot itself depending on how all this goes. Currently, you can add a recipe to a distribution.

A Recipe I would like to see

For a recipe example, let's use what I would be most interested in. A publication.

It could include contributed modules for:

• publishing workflows for teams
• team-editing
• social media publishing and interaction, specifically the Fediverse
• customized media modules like video, image, eBook, and PDF hosting
• GDPR, other compliance checkers, and alt tag generation (And AI would be fine here)
• grammar, style guideline, and accessibility checkers (AI would be fine here)
• subscriptions
• newsletter integrations
• payments and micro-payments
• and no generative AI, because journalists should be able to write and use real images
• and no comments because of spammers

Experience Builder

Starshot will improve, replace, etc. Layout Builder (which currently is a clusterfuck.) The replacement Experience Builder, is envisioned as some combination of Layout Builder (or a replacement hopefully), Paragraphs (not so great), Single Directory Components (SDCs)(great stuff), an in-browser styling tool, and other modules/configuration to provide a page-building solution that is easy to use.

This is good because Layout Builder as it stands now is not worth much to site builders. Basically, it's a way to add core or custom blocks to your individual content types in order to standardize their layouts. It's damn sure not an easy-to-use page builder.

It should have included Gutenberg

Drupal considered Gutenberg for Experience Builder. And they should have gone with it. But at least they have not ruled it out in the long run. And really it should be an alternative editor in Core eventually. Then users could build whatever the fuck they want to. And have better UX, UI, and frontend designs without going headless.

According to Frontkom (the firm leading Gutenberg Drupal) if Starshot had integrated it, there would have been these immediate benefits:

• Drupal is built for larger websites, and the open-source space can compete with the larger proprietary systems by simply being easier to use. And the same would be true for smaller websites and platforms like Wix, Squarespace, etc.
• Gutenberg offers a more user-friendly and visually appealing editing experience. Content creators can leverage drag-and-drop functionality and a block-based approach to easily structure their content. This empowers them to create rich layouts without needing extensive coding knowledge.
• It can be used in combination with both Paragraphs and Layout Builder. And it will support single-field editing features.
• It can be super minimalistic at first, where you start with a blank canvas. But under the hood, you have hundreds of features out of the box that you can activate or not.
• If you turn off Gutenberg, you still have content visible on your site and ready for any migration in the future.
• RSS feeds and other Drupal View listings are handled with field mapping within Drupal Gutenberg. Thus, data from Gutenberg is populated into other fields of the content type, ready for all kinds of field data cherry-picking.
• Combined with the feature of being entity agnostic, you can use Gutenberg easily on taxonomies, in webforms, on blocks, and also within Layout Builder.

Fortunately, you can still use Gutenberg as an editor for your content type's bodies via a module. Thus it will be compatible with with whatever Starshot evolves into.

And you can always create custom Gutenberg blocks with React (which sucks) if you really have to.

Eventually you might even be able to theme with it, like you can in WordPress. That would really help Drupal grow and Starshot reach high orbit.

The Holy Grail - Hosting

Any hosting company with any sense will be developing a scaled-down and optimized installation and hosting option for Starshot. And they should price it accordingly. More A2 Hosting and less Acquia should be the goal.

And wouldn't it be awesome if it was WebAssembly based?

Gábor Hojtsy writes in his blog post about Starshot:

"Discussions around making simple hosting available for simpler sites was reignited and a WebAssembly-based browser-executed demo solution's feasibility is also explored again."

He also mentioned the potential for a WebAssembly-based option in his DrupalCon Portland 2024 session about Drupal 11, as well as options for ephemeral (temporary) hosting solutions (think SimplyTest.me.)

One exciting project is Wasmer WebAssembly. Currently it has starter templates for WordPress, Laravel, Symfony, and generic PHP. So hopefully something could be done with Starshot down the road.

WordPress Playground already shows what's possiblewith WebAssembly.

Want to start with Starshot now?

If you answered yes, here is a very early prototype you can experiment with. Have fun! And please contribute to Starshot. Lot's of the large Drupal agencies are.

Wrapping it up

It's too early to know how Starshot will shake out. But it's a fantastic idea and I truly hope it succeeds in its goals despite my inherent curmudgeoness on its development pace.

I think:

• Recipes integration is the feature to focus on initially.
• Gutenberg or another user-friendly block solution needs to eventually be an option in the Experience Builder, which should be the second most important focus itself. Maybe SDCs would be adequate.
• Customized Starshot installation and hosting should be available and eventually based on WebAssembly.
• Starshot should be extremely easy to use for a person of average intelligence.
• Smart site builders should be able to knock it out of the park with Startshot.
• It should integrate open protocols like Activity Pub, etc.
• And they should call it Sympal. 😈

I hope you enjoyed this opinionated article and be sure to visit the official Starshot links at the top. Drupal knows where it needs to go. It just needs to move faster getting there. Starshot is their latest shot at achieving speed and ease of use. Let's hope they land it.

Happy coding and noncoding, Drupalers!

Author

Reuben Walker

Founder
Symfony Station