Hacker News Reader

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.

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

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.

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.

> Assuming you mean “return” as in a JSX expression in a return statement

I do. Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three.

-----------

>Attributes aren’t even part of the syntax (they’re “props”)

What I meant was that this is valid syntax:

  function hey ({ props }) {
   return (
    <div data-foo={ bar }></div>
   );
  }

While this isn't:

  function hi ({ props }) {
   return (
    <div { bar }></div>
   );
  }

There are many situations in HTML where you want a plain string inside the tag, like <input checked>

-----------

> control flow is anything that can be used in a JS expression position

I explained myself poorly. We can use if/else outside the return statement, of course. It's JS after all. But inside it, which is where the JSX magic happens, you have to resort to things like:

  { isItTrue ? (
    <i>yep</i>
  ) : (
    <b>nope</b>
  )}

-----------

>It might help to think of JSX as more like an S-expression (as in Lisp)

That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses.

> Right, but the <></> syntax still feels like a hack around a need to have just one node at the top of the three.

It’s roughly analogous to an array (and in some implementations it literally produces an array). The “hack” isn’t around returning multiple nodes, you can’t produce (and therefore return) an expression of multiple anything without some container.

> There are many situations in HTML where you want a plain string inside the tag, like <input checked>

Some implementations do accept that (checked prop without any curly braces or prop value assignment), with roughly the same semantics (the prop is assigned a boolean true). React doesn’t accept it IIRC, but React has quite a few rules beyond JSX (as specified, and as used in other implementations).

> But inside it, which is where the JSX magic happens, you have to resort to things like:

You don’t! You only have to use an expression. This is perfectly valid JSX (assuming whatever is outside the outer curly braces is also valid):

  {(() => {
    if (isItTrue) {
      return <i>yep</i>;
    } else {
      return <b>nope</b>;
    }
  })()}

> That's probably the biggest complement to JSX possible :) I admire Lisp from afar, but could never stand the parentheses.

It really is a pretty close analogy, not just a compliment. And in most uses, JSX is almost exactly akin to a Lisp macro (the biggest difference besides delimiters and host language semantics is that the “macro” definition is supplied by some arbitrary tooling external to the host language).

> You don’t!

You’re right, but I’m not sure wrapping it in a self calling function is any better to me. It feels like a lot of contortionism to just echo strings.

Sure, that’s reasonable if your only concern is echoing strings. Part of what’s appealing to me about JSX is that it’s capable of far more than string output (even in that’s ultimately all you’re producing from it). The thing (usually) produced in a JSX expression is a value, which can be any arbitrary data structure, and can be composed in any arbitrary way you like. Echoing strings—which is to say producing output as a side effect, out of band of a component’s return value—undermines that. It’s totally a valid approach (and makes perfect sense in the context of PHP’s rendering model), it just has a different set of capabilities.

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.

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.

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!

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

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

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

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