Live data from Hacker News

EmDash – A spiritual successor to WordPress that solves plugin security

blog.cloudflare.com

401–410 of 558 posts

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#401

> Our name for this new CMS is EmDash. We think of it as the spiritual successor to WordPress. It’s written entirely in TypeScript. It is serverless, but you can run it on your own hardware or any platform you choose. Plugins are securely sandboxed and can run in their own isolate, via Dynamic Workers, solving the fundamental security problem with the WordPress plugin architecture. And under the hood, EmDash is power…

Distribution of the content as static html or in any other format is a very tiny aspect of managing content and mostly a solved problem for any CMS nowadays. Focusing on that minimal aspect seems grotesque as there are much bigger challenges in making potentially large amounts of content actually manageable by a potentially very heterogeneous group of content creators with varying skills, responsibilities and relationships.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#403

Earlier quoted context omitted.

There's always https://textpattern.com/ which is also as old as Wordpress (older?) and better coded. (See also t https://textpattern.org/ ).

It stores plugins as strings in the database, then pulls those strings back and evals them as PHP on requests. "Better coded" is very much a subjective assessment.

Thank you very much for sharing your research results!

I really appreciate your work and even more that you took time and risk exposing your findings, I wish more people did this.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#404

Earlier quoted context omitted.

The issue with static sites is they can't do comments.

Astro would call that an island: https://docs.astro.build/en/concepts/islands/ I guess this is our answer to the question of why Cloudflare acquired it in the first place.

Isn’t that just the way old school Perl/ruby/php web apps from 20 years ago did things but with a fancy name?

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#405
This is naive thinking you can just rewrite WordPress and think it's going to solve any problems that exist with WordPress. The entire community of WordPress has been built over decades including its successes and failures, but people are not going to just stop using WordPress as I have seen people attempt this over and over in the last 20 years with little success.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#406

Earlier quoted context omitted.

I started calling it LLM assisted coding. If you know what you’re doing but use LLMs to do tedious stuff and educate yourself on the unfamiliar bits you can move quite fast. The term vibe coding does not do that process justice imho.

> The term vibe coding does not do that process justice imho. Well that's because actual vibe coding is a completely separate thing from "LLM assisted coding, know what you’re doing but use LLMs to do tedious stuff". I'm not entirely sure what you mean by "started calling it", but vibe coding doesn't need a new name, it needs people to be clear about what they mean.

I think the jury is still out on this one, meaning people have different meanings when using the term "vibe coding".

OP says "vibe-coded months long project", imho that is not vibe coding? I'd say it's vibe coding if op does not know the programming language and just let the LLM write everything. This does not sound like it.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#407
post #261

Earlier quoted context omitted.

I started calling it LLM assisted coding. If you know what you’re doing but use LLMs to do tedious stuff and educate yourself on the unfamiliar bits you can move quite fast. The term vibe coding does not do that process justice imho.

Vybrid coding :)

Well, it's a spectrum indeed, as everything is. As soon as we drawn lines the discussion start on where to draw them exactly. So it's, left to right:

One shotting --- vibe coding --- vybrid coding --- stack overflow assisted programming --- programming

Do we need any extra dimensions perhaps?

;)

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#408

It looks like I'm in the minority after reading this comments, but I'm quite happy to see this announcement. A "good" standard, free CMS with theming and plugin support without the issues of Wordpress is _welcome_. (And the issues are many: Licensing, trust, drama, security, and cost). I'm guessing that a lot of cynicism here is coming from this crowd not being the target market of Wordpress in the first place? What…

Surreal CMS. Nothing is more simple and robust for non-technical people to use. Not open source, but that's never a requirement in these cases.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#409

I don't like that they see the main selling point that the license, is not GPL, and that plugins don't have to license it that way either. I understand that not all developers are comfortable with the GPL license, but it allows to the code continue to be open source and that most plugins are open source also

A big issue with WordPress is the GPL. There hasn't been much clarity about it and the interpretations I've heard from Automattic in regard to which code is and is not covered by the GPL come from Automattic, not from the GPL. https://redsweater.com/blog/825/getting-pretty-lonely

For what it's worth: they live up to their own standards. Here, for example, is the source code that powers their VIP platform product:

https://github.com/Automattic/vip-go-mu-plugins

It must be open sourced because it's based on WordPress. I still love that.

Re: EmDash – A spiritual successor to WordPress that solves plugin security

#410
post #299

Earlier quoted context omitted.

Isn't it normal for the initial commit to be large?

A little larger, a lot of the time, though I like a small initial commit better. Though just a little larger. Not so large that it is too large to show on a GitHub page. That means not using version control properly.

Usually when someone decides to share code with the world, they don't want to publish the actual development history. They publish the first version that is ready to go public as the first commit. With enough functionality etc.
Post reply on HN