4 ms·

The problem is that WordPress lost the plot with its block editor, Gutenberg. Automattic started to get more interested in money than they did in polishing the

The problem is that WordPress lost the plot with its block editor, Gutenberg. Automattic started to get more interested in money than they did in polishing their core product, WordPress. Instead of implementing a lot of these features into the core (which would then make room to actually make interesting plugins), they're acquiring companies left and right and delivering a new WordPress release every few months promising "100+ performance improvements", etc. How come those "performance improvements" never actually do anything? Not only that but WordPress ecosystem right now is extremely fractured because of this "block editor". It alienates more than 20,000+ themes because they're built on the "old" WordPress principles, and at the same time - nobody really wants to use block themes because it means starting from scratch. I have played around with block themes as recently as a few months ago, and they've definitely gotten better than they were ~1 year ago, but they are only good if you know what you are doing. And, if you even have the patience and the will to make a custom site for yourself. This is turning more into a rant of me than anything though, but maybe that's precisely the point, that's where WordPress is right now and the only thing I can see is that maybe Automattic is "afraid" to alienate plugin developers and cause a backlash.

XCSme 3y ago
For me, it's confusing because my theme provides like 3 different block editors to choose from, and all seem broken in a way or another, so I am not very afraid to even click on the "Edit with (insert name) block editor".
bruh2 3y ago
I'm not a webdev by trade, so when I wanted to write a quick cute portfolio for my sibling I opted for ClassicPress. It's a fork of the last WP version that still featured the normal editor. Creating themes for it turned out to be straightforward thanks to the abundance of templates, tutorials, and examples available for these old-school WP themes. And PHP isn't so bad, too. The only thing I found myself yearning for is more of an "as code" - i.e. having all of ClassicPress' config stored in a handful of version controlled files, rather than fragilely in a web UI. But for my humble needs, it sealed the deal perfectly. Boring is good!
creshal 3y ago
I can see the reasoning behind Gutenberg, but the implementation is absolutely insane. Everything is needlessly complicated, there's no way to debug it, documentation is either missing or outdated, and so on and so forth. A large customer (who's been using Wordpress for close to 10 years now with a heavily optimized custom theme) wanted to use it, because it looked so shiny and cool, but in the end we had to put half a dozen people into what turned out to be a two year long migration process that's still not finished. At this rate, Wordpress will drop Gutenberg for a new editor before all that effort paid off.
poisonborz 3y ago
"lost the plot with its block editor, Gutenberg" I don't get the flak, your comment also doesn't explain why Gutenberg is responsible for all this. WP is by far, faaar the most popular website platform, a huge driver of profits for a whole ecosystem of (mostly not so great) companies yet it's open source and Automattic is not anywhere as profitable as it should be compared to this. It must be a hell of a hard job steering this ship and still be not scummy/as good-willed as this company still manages to be.
tambourine_man 3y ago
I understand why Automattic needed something like Gutenberg. The external competition from Wix and the likes and internal from Elementor, etc, was existential. However, after all these years, it’s still a usability mess for the end user and a nightmare for the developer. Was it really necessary to shove React and that dreadful ecosystem down everyone’s throat? I mean, the hello world of a block downloads 50k files through npm, I shit you not. And you now have to deal with JSX and need a build step for the web, which is heartbreaking for me. We have PHP, which is superior as a templating language in every possible way, and it’s right there already. Anyway, whenever I start a Wordpress project I’m faced with using the block editor or falling back to ACF. And honestly, neither one feels like the right choice.
- eyelidlessness 3y ago
  > We have PHP, which is superior as a templating language in every possible way It’s been a very long time since I’ve written any PHP, but even when I did write PHP pretty much full time this wouldn’t have been my impression. Tooling aside, JSX is exactly what I would have wished for PHP templating to be (if I had had the foresight to wish it). In fact, if I’m not mistaken, I believe better templating in PHP is the JSX origin story? Don’t get me wrong, if you prefer PHP for templating, I have no quarrel with your preference. My gripe, insofar as I have one, is the preference stated in an objective framing.
  - tambourine_man 3y ago
    Sure, preference is subjective. What is objective is that JSX is very constrained. Both because it lives inside another language (JavaScript) and by design. It must only return a single element, you can’t add arbitrary attributes, its control flow syntax seems (subjectively) bolted on, etc. When you’re coming from a language where you can print anything, it's very frustrating.
    - eyelidlessness 3y ago
      Some of this isn’t right or deserves clarification. > It must only return a single element Assuming you mean “return” as in a JSX expression in a return statement (though the same applies to a JSX expression in any valid syntax position), it can be any of: - one Element (which may or may not correspond to any markup element, it can resolve to basically anything depending on implementation) - zero Elements (<></>) - a non-Element child-compatible expression (typically a primitive value in most implementations) - any arbitrary non-Element expression (behavior will vary depending on implementation support) - N Elements (<>…</>) > you can’t add arbitrary attributes This is entirely implementation dependent. Attributes aren’t even part of the syntax (they’re “props”), and many implementations differ on how or even if they correspond to attributes at all. The spec does not constrain arbitrary prop names. > its control flow syntax seems (subjectively) bolted on It’s actually the inverse: control flow is anything that can be used in a JS expression position; JSX is bolted on (extends) the expression syntax. Some implementations and/or libraries also implement control flow as JSX Element expressions (eg Solid’s For, Show, Switch/Match). > When you’re coming from a language where you can print anything, it's very frustrating. The only real limitation syntactically is that everything in a JSX expression must be an expression itself. This isn’t as limiting as it sounds, because functions can be expressions (with anything in their body, and can be invoked as an expression inline at their definition site). It might help to think of JSX as more like an S-expression (as in Lisp). It can express any value (that the language can produce), but it can’t express arbitrary statements.
Swalden123 3y ago
I personally really like the block editor. Much better then the shortcode hell we had before.
CM30 3y ago
The issue is that the block editor and classic editor have very different audiences. In theory, the former is for the folks who'd use SquareSpace, Wix, etc. Non technical folks who want to customise everything in a 'user friendly' way and have absolute control over their site and its content. Meanwhile the latter appeals more to agencies and large businesses, who have a bunch of users they want to only allow to post specific content/make specific changes, and a vision for what the site should be that they don't really want changed via random blocks and settings. Gutenberg was meant to win over the former group and stop them going to SaaS based solutions, but ended up being a headache for the latter, which were arguably a bigger percentage of the folks using WordPress on a professional basis. Hence the ecosystem getting fractured like this.
sofixa 3y ago
> Automattic started to get more interested in money than they did in polishing their core product, WordPress Company cares about revenues more about "polish" (which is highly subjective - for some polish might be rewriting everything to Rust, for others it might be fancier looking UI components), more news at 11.

XCSme 3y ago

For me, it's confusing because my theme provides like 3 different block editors to choose from, and all seem broken in a way or another, so I am not very afraid to even click on the "Edit with (insert name) block editor".

bruh2 3y ago

I'm not a webdev by trade, so when I wanted to write a quick cute portfolio for my sibling I opted for ClassicPress. It's a fork of the last WP version that still featured the normal editor. Creating themes for it turned out to be straightforward thanks to the abundance of templates, tutorials, and examples available for these old-school WP themes. And PHP isn't so bad, too. The only thing I found myself yearning for is more of an "as code" - i.e. having all of ClassicPress' config stored in a handful of version controlled files, rather than fragilely in a web UI. But for my humble needs, it sealed the deal perfectly. Boring is good!

creshal 3y ago

I can see the reasoning behind Gutenberg, but the implementation is absolutely insane. Everything is needlessly complicated, there's no way to debug it, documentation is either missing or outdated, and so on and so forth. A large customer (who's been using Wordpress for close to 10 years now with a heavily optimized custom theme) wanted to use it, because it looked so shiny and cool, but in the end we had to put half a dozen people into what turned out to be a two year long migration process that's still not finished. At this rate, Wordpress will drop Gutenberg for a new editor before all that effort paid off.

poisonborz 3y ago

"lost the plot with its block editor, Gutenberg" I don't get the flak, your comment also doesn't explain why Gutenberg is responsible for all this. WP is by far, faaar the most popular website platform, a huge driver of profits for a whole ecosystem of (mostly not so great) companies yet it's open source and Automattic is not anywhere as profitable as it should be compared to this. It must be a hell of a hard job steering this ship and still be not scummy/as good-willed as this company still manages to be.

tambourine_man 3y ago

I understand why Automattic needed something like Gutenberg. The external competition from Wix and the likes and internal from Elementor, etc, was existential. However, after all these years, it’s still a usability mess for the end user and a nightmare for the developer. Was it really necessary to shove React and that dreadful ecosystem down everyone’s throat? I mean, the hello world of a block downloads 50k files through npm, I shit you not. And you now have to deal with JSX and need a build step for the web, which is heartbreaking for me. We have PHP, which is superior as a templating language in every possible way, and it’s right there already. Anyway, whenever I start a Wordpress project I’m faced with using the block editor or falling back to ACF. And honestly, neither one feels like the right choice.

eyelidlessness 3y ago
> We have PHP, which is superior as a templating language in every possible way It’s been a very long time since I’ve written any PHP, but even when I did write PHP pretty much full time this wouldn’t have been my impression. Tooling aside, JSX is exactly what I would have wished for PHP templating to be (if I had had the foresight to wish it). In fact, if I’m not mistaken, I believe better templating in PHP is the JSX origin story? Don’t get me wrong, if you prefer PHP for templating, I have no quarrel with your preference. My gripe, insofar as I have one, is the preference stated in an objective framing.
- tambourine_man 3y ago
  Sure, preference is subjective. What is objective is that JSX is very constrained. Both because it lives inside another language (JavaScript) and by design. It must only return a single element, you can’t add arbitrary attributes, its control flow syntax seems (subjectively) bolted on, etc. When you’re coming from a language where you can print anything, it's very frustrating.
  - eyelidlessness 3y ago
    Some of this isn’t right or deserves clarification. > It must only return a single element Assuming you mean “return” as in a JSX expression in a return statement (though the same applies to a JSX expression in any valid syntax position), it can be any of: - one Element (which may or may not correspond to any markup element, it can resolve to basically anything depending on implementation) - zero Elements (<></>) - a non-Element child-compatible expression (typically a primitive value in most implementations) - any arbitrary non-Element expression (behavior will vary depending on implementation support) - N Elements (<>…</>) > you can’t add arbitrary attributes This is entirely implementation dependent. Attributes aren’t even part of the syntax (they’re “props”), and many implementations differ on how or even if they correspond to attributes at all. The spec does not constrain arbitrary prop names. > its control flow syntax seems (subjectively) bolted on It’s actually the inverse: control flow is anything that can be used in a JS expression position; JSX is bolted on (extends) the expression syntax. Some implementations and/or libraries also implement control flow as JSX Element expressions (eg Solid’s For, Show, Switch/Match). > When you’re coming from a language where you can print anything, it's very frustrating. The only real limitation syntactically is that everything in a JSX expression must be an expression itself. This isn’t as limiting as it sounds, because functions can be expressions (with anything in their body, and can be invoked as an expression inline at their definition site). It might help to think of JSX as more like an S-expression (as in Lisp). It can express any value (that the language can produce), but it can’t express arbitrary statements.

Swalden123 3y ago

I personally really like the block editor. Much better then the shortcode hell we had before.

CM30 3y ago

The issue is that the block editor and classic editor have very different audiences. In theory, the former is for the folks who'd use SquareSpace, Wix, etc. Non technical folks who want to customise everything in a 'user friendly' way and have absolute control over their site and its content. Meanwhile the latter appeals more to agencies and large businesses, who have a bunch of users they want to only allow to post specific content/make specific changes, and a vision for what the site should be that they don't really want changed via random blocks and settings. Gutenberg was meant to win over the former group and stop them going to SaaS based solutions, but ended up being a headache for the latter, which were arguably a bigger percentage of the folks using WordPress on a professional basis. Hence the ecosystem getting fractured like this.

sofixa 3y ago

> Automattic started to get more interested in money than they did in polishing their core product, WordPress Company cares about revenues more about "polish" (which is highly subjective - for some polish might be rewriting everything to Rust, for others it might be fancier looking UI components), more news at 11.