Hacker News new | comments | show | ask | jobs | submit login
Is Gutenberg the End or a New Beginning for WordPress? (deliciousbrains.com)
237 points by smacktoward 24 days ago | hide | past | web | favorite | 171 comments



Personally, as someone who makes a living building stuff on WordPress, I am extremely concerned about this transition.

First off, I don't think Automattic has handled communicating it very well. Gutenberg is going to be a big, seismic change in what WordPress is. It seems reasonable to expect lots of themes and plugins will break when it goes live, especially older ones that haven't been as actively maintained.

And yet, if you surveyed the global WordPress userbase, I'd be amazed if you found even 10% of them were aware that such a change is even on the horizon. The communication to developers around Gutenberg has been hit or miss, but at least they've been making an effort on that front. In terms of communicating to the general WP-using public, other than a notice in the dashboard in the most recent version, I'm not aware of there having actually been any. So there are going to be a lot of "WTF" moments when people update to 5.0 and things start breaking or behaving contrary to expectations.

Secondly, I fear that Gutenberg is going to split the WordPress developer community. WP has always been a PHP project; if you wanted to contribute, whether to WP core itself or by writing themes or plugins, PHP was the language you needed to know to do that. Gutenberg, however, is all React-based, which means now there will be two classes of WP developers: people working on things that don't touch Gutenberg, who will be writing PHP, and people working on things that do, who will be writing JavaScript/React.

(My suspicion, even though Automattic has denied it strenuously, is that the master plan is to slowly phase out PHP and turn WordPress into a React-only project. So after Gutenberg, we will see more and more components of WP getting rewritten in React, until one day there just won't be any PHP left anymore.)

Thing is, I don't know a lot of PHP developers who are also React whizzes, or vice versa. So I fear that Automattic is taking one of the core reasons for WordPress' success, its absolutely huge developer community, and throwing it overboard. If the plan really is for WP to become a React project, a whole lot of PHP developers are going to need to become React developers in relatively short order. Some will be able to make that transition, but I worry that many will not. Maybe it will pick up enough new React fans to make up for them, I dunno. But that seems like an optimistic read to me.

The more I learn about Gutenberg, the more I wish Automattic had just started a second, React-based project and used that as a clean sheet of paper, rather than taking all these ideas and trying to jam them into WordPress to make some sort of software turducken.


I think the oddest part of Automattic's handling of this is that they are ramming this through, skirting a lot of quality controls such as accessibility (something they recently canned to meet deadline) but yet have the minimum requirement for Wordpress on very much dead PHP versions, 5.2-5.4. They also claim to be community driven, yet...they aren't even listening to the community on this. It's wild. I guess maybe their overall goal is to make Wordpress.com a highly successful SaaS and the open source portion is a secondary thought because it isn't profit driven. In any case, this could turn out to be a massive disaster for Wordpress. As a long time Wordpress developer, I am highly concerned. I think it has tons of potential if one right...but the handling of it has been shady, at best.


People don't like change. If you think you have a good idea, and you want to incorporate it into a product, you'll often find push back. Especially in the case that it has widespread affects. If you nail it you will hear all sorts of praise, if you fail - ridicule and insults.

They are trying to push forward with what they think is a good idea, and best for the products future. Doesn't mean they're right, however there is the argument that the customer doesn't know their experience could be improved.

Time will tell in the WordPress case.


None of which has anything to do with having a double standard. If you ran your project with backwards compatibility as a core value and promise to your users then don't be surprised if they get upset when you break that promise.

It can be good to recognize that back-compat has become detrimental. When that happens, you need to communicate the reasons why you have decided to break it and communicate that the projects values have changed going forward. It doesn't sound like either of those things have happened here.


Please check out my "State of the Word" presentation from 2016 and 2017, I tried to make the best case I could for why, perhaps once a decade, it is worthwhile to trade backwards compatibility for future relevancy. The reason I have personally not advocated for that trade-off before was that the reward on the other side was not worth it, but with Gutenberg we have a huge opportunity, and incredible user demand demonstrated by the adoption of the beta plugin, that I think makes it #worthit.


Accessibility has been worked on since the beginning of Gutenberg. If "Automattic" just wanted to be more competitive or operate for its own commercial benefit, it would have been 10x easier and faster to just do Gutenberg on WordPress.com and not do it core-first. Gutenberg being in core means every WordPress host in the world (that all compete with Automattic) will get access to it. It's not proprietary, it's open source. It works with all the plugins and themes out there. It works with the hundreds of billions of posts that have been written in the past 15 years of WordPress. It's community-first.


You know what Gutenberg doesn’t work with? People. It’s filled with mystery meat navigation and animations. And it’s a resource hog. It’s typical of almost all modern JS heavy interfaces I’ve come across. I’m loathing the thought of moving clients and coworkers over to it.

I say this as someone who loves WordPress and has been developing on it since 2006. I’ve also been working in UX and UI for ten years. I’m hoping for the best, but bracing for the worst.


We're definitely working on making it more efficient, and will continue to. We tested with WaitButWhy posts that are 50k+ words. In the old WYSIWYG it wouldn't even load, Gutenberg can parse and load it in a few seconds.


That's just false. Just because it's open source doesn't mean Automattic doesn't want to turn into a SqaureSpace model. There is no doubt in my mind that the pivot and ramming through of Gutenberg is because they are scared of things like SquareSpace and feel they need to evolve fast. They do need to evolve, but they also need to stop cutting corners and listen to the community...It won't be long (it might already be true) that the "Classic Editor" plugin will have more active installs than any other plugin in the repo. That's a LOUD message from the community that "this is not ready!" I have sites that are Gutenberg compatible but I still have the classic editor on, because it's a giant mess.

Gutenberg from my experience is a server hog compared to the classical Wordpress. It's harder on database servers and on memory. Yet they won't even change their PHP practices to make it 7+ requirement.


There's also facts: Gutenberg plugin adoption is growing faster than Classic Editor adoption, so it's not likely it will have more active installs than any other plugin. But even if it did, that's okay, we're supporting it. It's not a failing of Gutenberg, just showing that people for whatever reason don't want change.

AFAIK there is no change to database or memory usage post-Gutenberg, especially since pretty much all of the new code executes on the client side when you edit a post. It may use more memory in your browser, but not anything that should cause issues.


The conclusion that sites installing the Classic Editor won't adopt to Gutenberg has a logical flaw. The Classic Editor is also used for sites, that are not "ready" for Gutenberg because it uses plugins that haven't gone through a full compatibility tests or where the site owner decided not to jump on the first version of WordPress 5.0 and waits until the kinks are out, say until 5.0.2 or 5.0.3. So there might be a lot more installs of the Classic Editor plugin coming, just because of this normal hesitance to jump on a new software feature out of the gate.


I like to think that one of the reasons for WordPress's resounding and continuous success among developers has been its open source, libre GPL license.

That being the case, I can see a well-prepared, well-publicized and well-maintained fork easily taking the cake from WP.org in the near future, as WP.com becomes more like the SquareSpace they admire so much.


> resounding and continuous success among developers

Purely anecdotal, but from a hiring stand point, it's extremely difficult to find good software engineers that are willing to work on or maintain a Wordpress-based project even as part of their duties. No one seems to want to touch it. I have yet to come across any engineer that would classify Wordpress as a resounding success in their eyes.


WordPress developers are keenly aware of all of the parts that aren't ideal in the code, and if you look at things where we're able to work in a more de novo fashion (like Gutenberg) you'll see best-in-class approaches and code.

However as you see in some other comments on this thread, backwards compatibility has been key to WP's adoption which can make it challenging to fully iterate the user and developer experience. With Gutenberg we're doing this, and it has generated a huge amount of pushback and even conspiracy theories. Hopefully in a year or two we'll look back at this as something we're not sure why there was even an issue.

The last time people threatened or actually forked WordPress like this was when we first adopted WYSIWYG in version 2.0, in 2005. Part of why WordPress today has 10x the market share of the runner-up is because we think a lot about these decisions, listen to tons of feedback, but are willing to occasionally choose controversial-at-the-time decisions that turn out right in the grand arc of things.



This won't happened without a community and communities take resources to run.

What's going to happen with the entire plugin ecosystem? Say I'm a plugin developer - am I going to jump ship to an untested fork with no company backing it, or am I going to go with a safe bet?

I'm happy to see a fork of Wordpress if that's the itch that people want to scratch (more power to them!) but the value of the app isn't in the code itself, is it?


Some of the larger dev shops that use wordpress as a core should work together to start a non-profit foundation, then fork it.

This model has proven successful before in other projects faced with similar issues


If the reason to fork is just Gutenberg, there's an official plugin available (Classic Editor), created and supported by core, that disables Gutenberg and gives you pre-5.0 experience for as long as you'd like to run it. And then you don't lose the infrastructure, updates, security, events, the benefits of the thousands of people who work on making some part of WordPress better every day.


The Joomla fork of Mambo is a good example.


Hello smacktoward! I'm thrilled you currently make your living on top of WordPress, and hope you can continue to for many decades to come.

"Automattic Automattic Automattic Automattic Automattic" Throughout your comment you attribute a lot to Automattic that is really core, or contributors, or me. There are hundreds of contributors to WordPress (and Gutenberg) that don't have any association with Automattic, and it's not fair to them to attribute anything good or bad about WordPress to a single company.

"I don't think [...] has handled communicating it very well" That's totally fair, and I believe we can always do a better job communicating. We've done a lot, such as with wordpress.org/gutenberg, the messaging in 4.9.8, at pretty much every WordCamp this year, and my big annual addresses the past two years, but we're not reaching everyone. Web hosts and agencies are helping a ton here to educate their customers and clients, and it's very much appreciated.

"It seems reasonable to expect lots of themes and plugins will break when it goes live, especially older ones that haven't been as actively maintained." This is why we have done a wide public release of the beta plugin and it's active on over 600,000 sites now — this is the most widely tested feature ever to come into core. People are running it with every possible combination of other plugins, themes, and hosting environments, and we've been learning a ton and fixing as much as possible beforehand. I don't claim any software is perfect, but this code has had more testers than we ever get for a beta version of WordPress, which is usually just a few thousand.

"My suspicion, even though [...] has denied it strenuously, is that the master plan is to slowly phase out PHP and turn WordPress into a React-only project." There are no secrets, on stage in 2015 I asked all WordPress developers to "Learn Javascript Deeply" because Javascript interfaces talking to REST APIs was the future of the platform. This is how the Customizer has worked for years, but you're correct that Gutenberg is the first major, full feature to be built on our own REST API and does use React. (In fact we were part of getting Facebook to remove the patent clause from React, which paved its adoption in the WP community and with many others.) So you're correct it's part of the master plan, but not that it has been denied at all. There will always be some PHP for the server side of things, but Javascript is the way forward for the interface and wp-admin.

"If the plan really is for WP to become a React project, a whole lot of PHP developers are going to need to become React developers in relatively short order. Some will be able to make that transition, but I worry that many will not." I'm concerned about this too, which is why I've been advocating for PHP-only developers to learn Javascript for 3 years now.

"The more I learn about Gutenberg, the more I wish [...] had just started a second, React-based project and used that as a clean sheet of paper, rather than taking all these ideas and trying to jam them into WordPress to make some sort of software turducken." First, I love turducken. :) But also, the WYSIWYG was in Javascript before, so it's not like editor-modifying requires a new language you didn't know before. The PHP metabox API still works just like before, and we and others are creating tools that allow PHP developers to interact with Gutenberg. But I'll repeat again that if someone wants to be a relevant web developer in a decade I don't think you can be PHP-only, and you should begin learning and mastering Javascript as soon as possible.


As someone who has always loathed Wordpress and everything connected to it and its ecosystem, I've switched over a Wordpress install I—reluctantly—voluntarily maintain in my spare time, and been extremely pleasantly surprised.

I've worked with Wordpress a lot over the years, so I'm very familiar with its inner workings: this is what's largely motivated me to avoid it when possible, and unfortunately prevented me from contributing to the project.

Given my initial reaction to Gutenberg, I'm imagining the community at large will hate it. The Wordpress community is one that champions amateur, dangerous, big-ball-of-mud software development, under the guise of being "beginner friendly" (where "beginner" = "not experienced enough to be leading clients to believe they can provide professional-grade solutions"). This is a mindset that favours hacks and tech debt. over refactoring, and Gutenberg is definitely going to force both plugin and theme developers to rethink, and rewrite their approach (in a positive way, imo).

If it successfully brings Wordpress out of the dark-ages, that's great obviously. If it makes Drupal more pleasant and easy-to-use for editors: also nice. If it kills Wordpress due to its community migrating away, then at least it could leave room for some more modern competitor.

I just hope the core devs don't do a U-turn on Gutenberg.


In a word: ClassicPress.. The community is already migrating


I was personally surprised to see my face as a "contributor" to ClassicPress, with a link to the Github contributors page that indeed shows my 1,900+ commits... to WordPress.

https://camo.githubusercontent.com/5c2b13dae2a33eafd5eab9039...

https://github.com/ClassicPress/ClassicPress/graphs/contribu...

I think it's confusing to screenshot the faces of all the WP developers, put it on your project homepage, and say "This project exists thanks to all the people who contribute." WordPress itself started as a fork so I fully support the importance of forking, but there's a way to acknowledge WP contributors without making it look like we're endorsing your project. Thank you!


I keep hearing folks say this, but it feels very astroturfed to me... I totally can be wrong about that feeling, but it's my feeling and I own it.


Ironic you mention the astroturfing, as the person you replied to is the creator of ClassicPress ;)

The creator likes to namedrop ClassicPress everywhere on the WP.org forums and WPTavern. He's had his posts removed from the wp.org forums due to spam too.


I'm an active core-contributor to WordPress, and I maintain a core component (Privacy) currently.

Even within the core-contributor community, there is a lot of friction, particularly with the "less popular" components. Accessibility was the first to snap, with the lead resigning, but not after other big contributors took long breaks when needed most. BDFL Matt hasn't helped heal the fractures and has hurt even more components since. The Privacy component, for example, was the butt of a joke during his WordCamp Europe keynote, boiling down our efforts over the past year as asking users to take cookies, which hurt Privacy team morale (the Privacy team primarily worked on creating a standardized way in the core to identify and export personal data, and help people create Privacy Policies by standardizing how plugins can identify what data they collect).

The largest issue is React -- it's so different than the rest of the WordPress core, that 90% of the core developers can't work on Gutenberg issues. WordPress is primarily PHP, and if JS is used, most places jQuery is the framework of choice. It's dated, but it works quite well still. React is quite the departure from all of those technologies, and will cause gigantic rifts in the community. I do believe WordPress will survive, but with thousands of plugins lost forever due to lack of updating.


Component approach is good, but why force everyone to use React or any particular framework? Wouldn't it be better to implement this as vanilla js component? Either via web component or just plain custom element.

Nowdays there are some really good solutions like quillJS or prosemirror that are not tied to particular solutions.


It's the WYSIWYG in the admin and you can still opt out to use TinyMCE. AFAIK, the front-end of Wordpress isn't using React.


Yet.


Even if they were to make the default theme based on React, nobody is using it. Everyone switch to something else right after install.

Should they change the entire stack to use React, they would lose a lot of their community. A lot of their users are code novices that make do with simple HTML and some PHP snippets.


"Wouldn't it be better to implement this as vanilla js component?"

I have not yet done this, but as I understand it... it's possible to use whatever JS you want as long as it works with the GB api.

Basically, I did the hello world react Gutenberg thing, then took a look at a11y and saw that none of the 8K or so institutional user I support could probably legally use it, and then got back to whatever Vue map searching for CPTs or whatever BS I was building based on ACF and plain old CPTs.

So I dunno for sure, but as I understand it you can build your Gutenberg components in any JS-based system without a lot of overhead. But of course, probably best to just use React as that is what all the core components will be written with.


React is a library and can be used as a thin layer over plain JS. It's just often not used that way.

As with all libraries, you still have to be good at organizing your code for it to help you in the long-run. That's a lot of the appeal (and problem) of full frameworks: it decides how to organize your code for you.


You'd be very to join as at ClassicPress..


I think Gutenberg solves the wrong problem for Wordpress. I don't think that many people were crying out for a fancier way to store giant messy blobs in MySQL.

Why does someone select Wordpress in 2018? Why even host a website at all? Because they want to build something custom. But because Wordpress core continues to be basically a simple blog engine, anything fancy has to get implemented as custom code and/or super powerful themes and plugins that are almost like mini CMSs unto themselves. This is where a lot of the security problems in Wordpress sites often come from, BTW.

IMO Wordpress could do a lot more for itself long term by improving the flexibility and power of its core, rather than its WYSIWYG.


> I don't think that many people were crying out for a fancier way to store giant messy blobs in MySQL.

This is clearly not the problem that Gutenberg aimed to solve.

The problem it solves is more what your second paragraph mentions: “how do I insert custom content that isn't just text in a way that looks consistent on the front and back end”?

Adding complex content in a visual way is a real problem in pre-Gutenberg WordPress, to the extent that a thriving cottage industry of page builders now exists, each with their own take on how to add and edit content.

Gutenberg hopes to remove the need for such page builders in many cases, (and eventually) unify the WordPress (and Drupal) community so they can offer custom content types as native blocks under a common API.

For relational content, there are still custom post types and taxonomies.

> IMO Wordpress could do a lot more for itself long term by improving the flexibility and power of its core, rather than its WYSIWYG.

It's doing that too, with the REST API, with WP-CLI becoming a “blessed” project, and with future plans for Gutenberg as a means to control widgets and other site areas, rather than just post content.


I think it is a mistake to view Gutenberg as something designed to solve problems for users.

> Adding complex content in a visual way is a real problem in pre-Gutenberg WordPress

It's not an actual problem though, is it? That cottage industry already fulfills the needs of those the subset of users that need more than what the tinymce implementation WordPress offers out of the box.

It's better to understand Gutenberg not as a problem solving project but as a reaction to two things that the project leader has trained his focus on.

First, there's this premise that everything is moving to javascript and php is legacy, so WordPress should evolve to run on javascript while casting aside PHP somehow. Fail that and the project could go under is an anxiety that exists.

Second, there's the itch for WordPress.com to compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences. This is where wp.com wants to compete and win new users choosing between other hosted providers. Mullenweg wants to have WP be an even bigger monopoly. These are two anxieties driving Gutenberg.

Gutenberg channels energy toward accomplishing a conversion from a PHP-centric project to a Javascript one, while making a play for new users who are choosing between the hosted version of WP and other hosted solutions.

On a technical level, Gutenberg doesn't really convincingly solve technical problems. It makes it easier for developers to tack on GUI driven content elements, which was possible before, but something that many developers didn't get right or didn't know how to do.

It doesn't provide a better WYSIWYG experience. The editor screen and the front-end are going to look and feel very different. The biggest new obstacle to arriving at a better WYSIWYG is the fact that in Gutenberg the interface markup is a first class citizen, with the content merely existing deeply nested inside its components in editing mode.

While editing, every paragraph, every image, every element is surrounded by endless amounts of divs and scaffolding. When designing a document's CSS you style according to the markup that is shown to users, now with Gutenberg you have to take into account the fact that while editing elements are nested deep inside a convoluted set of divs. So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode.


> It's not an actual problem though, is it?

Sure it is.

If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem — it's a sign that the existing editor does not meet their expectations for how a modern CMS/blog platform should let them work, which makes it a good candidate to be solved in the platform itself.

And if completely new users struggle to format content without frustration (I have watched many people trip with the “Classic” editor in new user orientations on simple things like adding and positioning an image or video), that is also a problem, because it affects their first impressions and gets in the way of whatever their personal or business goals are.

Gutenberg is aimed at solving both of those real problems; I think on the whole it does it well, and it's enlightening to see how positively some people react to it:

https://twitter.com/antpb/status/1052996833264455680

> The editor screen and the front-end are going to look and feel very different.

You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass. This is how the upcoming new default WordPress theme (Twenty Nineteen) already works: https://github.com/WordPress/twentynineteen

> So we're still storing messy blobs, but now we're going to split up those blobs and add more mess while in editing mode.

The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls.

There are some big and entirely valid criticisms around Gutenberg (accessibility support, general PR issues, release delays), but “not being designed to address a real user problem” isn't one of them.

It will take a lot of time to address all issues and turn the community around to it, and this is just the start.


> If the first thing thousands of users do after installing WordPress is to pay for a page builder plugin to be able to work with their content in the way they want, that's a problem

Or, it's an opportunity. Look at Shopify - is it a problem that the first thing a new Shopify user does is to head to the Shopify app store to buy and install a handful of plugins?


Completely agree that access to plugins is a huge plus. Except if a very large number of Shopify users start to install the same plugin or plugin type, and you start to see articles titled "60 of the best [page builder|digital download] plugins for [WordPress|Shopify]", and you field daily support requests asking, "which page builder plugin should I use?", and users actively avoid an existing feature in your service to use a third-party add-on that does the same thing your feature was doing only better. At that point it's a great candidate for a core product feature or enhancement, as has been the case with Gutenberg.

Also worth noting there is no official WordPress.org paid plugin store and paid plugins are typically not hosted services as with Shopify.

The average experience WordPress users get when shopping for, maintaining, and getting support for plugins is much less smooth than a hosted platform like Shopify. (There are great WP plugin developers and terrible Shopify ones too, but fewer of the former than the latter.)


I think you've missed the point a bit. I'm trying to make a distinction between what is driving Gutenberg and what it's trying to solve and why. Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already. It's primarily vehicle for accomplishing other goals, i.e. improving .com's competitive offering and managing the transition to a JS centric code base. Those things are more important.

Understanding the priorities in play explains in part why Gutenberg is causing friction better than saying it exists because it is trying to solve technical problems for users. That would lead you to think that the technical problems were thought about really hard and that is some primary goal. It's not. It's just WordPress trying to modernise an interface.

> You can style the editor with CSS, and re-use much of your front-end theme styles in the editor stylesheet via Sass.

The reason I bring up the editor and WYSIWYG is that it shows the disconnect between some lauded goal of providing a more seamless experience and the thought that went into the technical solution. My feeling is that we ended up where we are not because we were trying to solve a problem in the best way, but because we were just trying to cram in a new JS way of doing things. It explains better how we arrive at the following mess. Let me show you it through the lens of styling a post:

https://imgur.com/a/AThzNns

> The “mess” in editing mode is needed to help people style their content more intuitively; you can't have a WYSYIWYG web UI without adapting the page content with scaffolding to enable styling controls.

Look at the gallery I posted and tell me honestly, are you really saying this is the only way to provide 'intuitive editing'? Of course that is not true, it's simply how Gutenberg decided to implement it. Of course, you can compose your CSS workflow to fit around how Gutenberg's editor functions and you'll get fairly good results if you do. But this is a workaround, it's made the UI a first class citizen at the expense of the rest. So theme developers have to think in terms of the UI, not just what the markup looks like on the front-end. And content creators are forced to think in terms of blocks. It's an UI that is altering how people interact with it, for its own sake.


Thanks for taking the time to make those screenshots.

To me they reveal a couple of misconceptions:

1. That a WYSIWYG should provide a pixel perfect like-for-like view of the front end on the back end.

As you mention, the theme you chose doesn't have full Gutenberg styling, so front and back end differences are more pronounced. But even themes that have good integration will display differences, because the back-end cannot perfectly model the front if users are going to do more than manipulate data inside it (i.e. change styling).

I do agree that there are other ways to provide more intuitive editing (like in-place editing), but they are not without downsides too. In-browser editing is a compromise and balancing act.

2. That the structural blocks around visual elements on the back end designed to enable UI elements and controls interfere with styling by theme developers in some way.

That was definitely my experience at first (I've just spent three months updating several themes for use with Gutenberg), but it isn't now that Gutenberg has evolved and I better understand how editor styling works. In short:

- You enqueue your editor styles after calling add_theme_support( 'editor-styles' ); with add_editor_style( 'style-editor.css' );

- You can then copy the bulk of your styles from the front end to that stylesheet (with a few exceptions, such as the post title, which do need editor-specific wraps at present).

- Gutenberg/WP 5.0 prepends those styles with a block-specific selector when you view the Gutenberg editor so that you don't need to worry about the “soup of UI markup”, as you put it.

- You can automate much of the CSS re-use using Sass, like the Twenty Nineteen theme is doing.

Theme developers need not think about the extra wraps unless they are developing custom blocks, and even then it's largely abstracted away for them by the JS API.

I would much rather have editor styling handled automatically by Gutenberg, and I think it will get there, but for the moment this is a small stepping stone on that path.


The UI does interfere, you, as a theme developer, have to adjust to it, as do content creators. This is getting to the point I'm trying to make, that the project wasn't invoked to solve technical problems. It's not answering to technical problems but to the motivations of the project leader.

You bring up how Gutenberg solves some of the issues it creates, i.e. how theme developers supply editor styles to match what is seen in the front-end. Until recently Gutenberg didn't even prepend block specific selectors, it was even more broken than now. Why did it even start out that way? How is that even possible to have Gutenberg develop that far without properly thinking about how to style for it? Why is it this solution patched on? (same can be said for meta fields, accessibility and so forth). Because the project didn't start with a clear idea of the technical problems it wasn't going to have to solve, it wasn't a priority.

So, for theme developers Gutenberg is more labour intensive (though it can be rewarding). It wouldn't need to be more labour intensive had it started with the full breadth of priorities in mind at the very start. You say 'you don't need to worry about the soup of UI markup, but you do. You have to work around the quirks of the editor or constrain yourself. Say you want to target every 2nd heading, or the paragraph after a blockquote, you can't do that elegantly, because the markup is different in the editor as it is in the front-end and it's not solved by prepending block selectors. Gutenbergs editor styles solution isn't elegant either. It is not a complete disaster, but it's indicative of the fact that the project is imposing its own paradigm over the problems its trying to solve. It's literally creating new problems to solve.

> they are not without downsides too. In-browser editing is a compromise and balancing act.

I'm not convinced at all that a different approach to how the UI manifests itself in the DOM would have entailed any meaningful trade offs at all. I've been working with this prosemirror implementation recently and the basic example pretty much matches my demo posted earlier: https://tiptap.scrumpy.io/


+1 I can concede that there are likely better technical implementations than where Gutenberg is at now. (Ghost's Koenig editor with the open block/card model is great, if much simpler and cutting corners by lacking Edge browser support and the ability to add custom cards.)

WordPress has always been a project where user happiness outweighs developer happiness, though, as much as I'd love for it to at least bring developer happiness inline. It will be interesting to see what the overall reaction is when 5.0 lands and the editor starts to become more widely used and accepted.


Yes and I'll concede that Gutenberg has a lot of room to grow and will even make plenty of people happy straight away. But I wouldn't call this about user happiness outweighing developer happiness, I'd say it's the other way around. It's based on asserting that we know what the future user wants, not the actual users. Right now user happiness is skewing negative.

And Gutenberg's development is precisely characterised by developers/designers prioritising their own happiness. It's a small group of people working mostly at agencies and companies doing enterprise level work who took Matt's idea around blocks and feverishly adopted the tools they personally wanted to use while developing and making decisions at a pace more rapid than other contributors could cope with. That is in part why we lost the accessibility lead.


Just wanted to clarify one thing, that “we lost the accessibility lead.” There were no accessibility leads until one was designated for the 5.0 release. There were three self-appointed accessibility team reps, one of which decided to step back from the group and blog about it. “Team rep” is largely an administrative role, and as I said before it’s self-appointed. Some teams have 5+ reps, and historically they have not been approved by anyone in WordPress leadership, nor do they connote authority or skill.


> Improving the editing experience is a valid justification - of course - but it's not happening because users are demanding it or because their problems are not being met already.

What's the difference between "compete on more level terms with the state of hosted solutions like WIX, Weebly, Squarespace who offer increasingly simple visual building experiences" and "solve problems for users". If there is something that is making people choose WIX/Weebly/Squarespace, isn't that something precisely: a problem that those things solve and default wordpress (currently) doesn't?


Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition, they run the self-hosted version and they are already well served by 3rd party solutions for their more complex needs. So now the community project is trying to prioritise the goals of the for-profit company at the expense of carefully developing solutions to meet its own users in a proportionate way. That's how we've ended up thinking of accessibility/custom fields/theme development/backward compatibility as things that are secondary priorities, if that.


The vast majority of revenue in the WordPress ecosystem is made by hosts other than WP.com. Everyone in the WP ecosystem benefits from increased usage, as it drives more plugins, more themes, more demand for agencies and developers, more books and tutorials about WordPress, et al. It’s all part of the virtuous cycle that has led to WP’s success so far. I’d be far more worried about the WP ecosystem if it started getting smaller and the various constituents were fighting over a shrinking pie.


For clarity, I'm not trying to make the suggestion this is about the pursuit of revenue, because I don't think that at all. My impression is that this is about survival and growth.

I've long emphasised the symbiotic relationship .org has with Automattic in positive terms. Up until fairly recently I would say this relationship was almost wholly to the benefit of the overall project. My impression is that WP.com under your leadership is now behaving more like other conventional tech companies - it's preoccupied with growth. That preoccupation with growth by implication operates in the context of wp.com competing with other commercial companies who compete for the same customers.

When I look at the success of WordPress through the years, I'm seeing growth arriving as a side effect, not as a specific end unto itself. Decisions were made because wrong or right, they seemed like a better, more powerful way to do things. When it becomes about growth, other things become a little less important. Through the lens of the need for growth, options are judged to the degree to which they are vehicles for further growth. Unfortunately this also leads to relaxing other principles that should be central to WordPress.

Before React changed its license, it had already heavily adopted for Gutenberg and Calypso and you had been poised to bless it had there not been so much turbulence. It was adopted because it had been the fastest way to move forward. The same militant zeal that was applied to 3rd party developers using non-GPL licenses was not applied to the adoption of React, because React was a useful tool in the pursuit of growth. Of course, you can say, but it's now a success story because I've no doubt that FB's change of license was influenced by WP. Community consensus was however a second order issue, as was the original licensing, what matters was what would make the people working for you happiest and most productive in the short term. (Credit to you, you were willing to abandon React at one point, that must be noted)

WordPress will soon be adopting AMP in core, given your support. Again, immediate growth will be the primary reason this happens, because AMP is the fastest way to cut down on bloat that is holding back performance for mobile users and users on slow connections. It's a shortcut, it's a shiny looking vehicle to continued growth, delivered on a plate by some of the worlds best engineers. This decision won't be made based on community consensus or a discerning look at whether it's good for the open web, or what other options there are. It will be stressed that AMP is developing web standards and is an open source initiative with many other players that have bought in, saving the web and helping poor users.

Because growth is the imperative, things that hinder growth are treated with the same baseline hostility as red tape is to businesses. Accessibility and privacy are inconvenient obstacles that ultimately need to take a backseat to building forward momentum, rather then the very means with which to democratise publishing and development.

Because growth is front and center, artificial time pressure needs to be created with which to force the issues. And like a conventional tech company that has grown into a monopoly, it starts to take advantage of its privileged position. It becomes aware of its own latitude, like now the ability to introduce a degree of breakage and concentrate all core development on the delivery of a flagship feature.

I'm seeing this and I'm thinking, many of the decisions that are being made are at best following the letter of stated principles, but not the spirit. Each decision can be somewhat rationalised and the pretense can be offered that it's in the interest of increasing the pie for everyone, or to reaching more users, general survival and for spreading OSS practices even further.

What I'm seeing is a web of monopolies that are interacting in such a way that their influence continues to grow. To have the web shaped by a few select players is not good at all, and I certainly haven't worked with WordPress all these years because I care about market share. I was motivated by the degree to which WordPress empowers people, how it brings people together and champions freedoms as well as its role in keeping the web open and independent. Now it's a slave to growth, nakedly pursuing monopoly status, boosting the role of problematic monopolies elsewhere while selectively applying its stated principles.

I have enormous, genuine respect for people working on WordPress, including you and the many people that work at Automattic and elsewhere. I believe strongly that every single person involved is working with the best intentions in mind. But the prioritisation of growth has corrupted the character of the project, and I can't express in words just how sad that makes me.


I completely agree that growth is a result, not a goal in and of itself. Fundamentally it represents what people, given the open market of all possible solutions to their problems, choose. We want to create the best software experience because that will help people choose Open Source vs proprietary solutions, which even if they don't appreciate it at the time will be better for them and the web overall in the long term.

Thank you for recognizing we were willing to walk away from React because of the license. It was chosen because of technical merit originally, but was a day or two away from delaying the entire project 6+ months to refactor.

AMP is interesting but no decision has been made there yet.

Thank you for sharing your thoughts and a generally excellent comment.


> Because it's a case of a for-profit company competing for paying customers of other hosted platforms. Most WordPress sites don't have that competition

So free users don't want the features that paying users want? Whyever not? Surely the fact that some people are willing to pay for a particular feature indicates just how important that feature is to a lot of users.


If that were true, why are so many existing users apprehensive about Gutenberg? Self-hosted users of WordPress have different priorities even if most would like a nicer editor, it matters how it comes about and it matters what other sacrifices are made in pursuit of the project.


Many users have legitimate concerns about Gutenberg (compatibility with existing plugins, suitability for ongoing plugin development, migration of existing instances). That's a very different statement from saying that it doesn't solve a real problem that many users have.


I'm sort-of leaving tech, but I've worked in web dev for 8 years, and this is the first I hear of Gutenberg.

From what I understand, it's better WYSIWYG. Great, but we have entire essays demonstrating how WYSIWYG is garbage. Alright but people want WYSIWYG!

To me, this seems like a manifestation of the limits inherent to the simplification of UI. The frontend needs complex information to be able to correctly produce a beautiful design. Ultimately, the user needs to be aware of the concepts (too complex, apparently), or the design needs to be automated and therefore simplistic. WYSIWYG is the unhappy compromise demonstrating that consistency begets complexity.

If this dilemma really is unsolvable, then Wordpress is but one of iteration in a grand cycle of its victims. I worked mainly with Drupal, and the situation there isn't much better, they've simply opted for sophistication over usability.


> we have entire essays demonstrating how WYSIWYG is garbage.

I would dispute all of those essays.

Explain to me what we do instead of WYSIWIG and if your answer is anything like Markdown then you've never observed real users.

Hell - I hate markdown and I'm a developer. I do not understand the desire to trash WYSIWIG other than reverse Ludditism.


The Markdown vs. WYSIWYG discussion goes along the same lines as the vim vs. Word discussion. You can discuss it, but real users in the target audiences of the products simply don't care about the alternative. To each his own.


good point. I've never met any client that would like to write in markdown though, but I love it, tbh. My most desirable feature of markdown editor is drag&drop images that turns automatically into `![img](xyz)` tags - I wish more editors offer such feature.


>From what I understand, it's better WYSIWYG. Great, but we have entire essays demonstrating how WYSIWYG is garbage.

You can find an essay demonstrating everything you care for is bad.

Engineering requires measurement and proof, not essays.


This is a much underappreciated point, one I first came to realize when trying to train reasonably intelligent lay users working with some of the 1st and 2nd generation WYSIWYG web tools (Fusion, Dreamweaver, and heaven help us all Frontpage). Point-and-click interfaces really only provide some degree of friction-reduction. A user who can be effective still has to think in terms of layout tools and behavior and different properties of block and inline elements that can be set, even if they don't have the language to describe these things and don't map it to syntax. That last part is the effort saved -- they don't have to map it linguistically/formally and for some people or some limited design/display problem set, that's big savings. I suspect, however, that's a significantly smaller set of people and problems than the common wisdom might indicate (and definitely smaller than "universal") and one of the reasons many web publishing tools end up providing templates + limited display options inside content and still end up being more popular than Dreamweaver.


> Great, but we have entire essays demonstrating how WYSIWYG is garbage

Markdown is great and all, I personally use it mostly for README docs and git tracking. But WYSIWYG is what most blog sites are embracing

Examples (but not limited to)

- Medium

- Ghost → Ghost 2.0

- Webflow + Design tools

- Notion + Notetaking tools

- Premade website tools (WIX, squarespace, Shopify Page Builder, etc) are gaining ground over wordpress traditionally

WYSIWYG has a learning curve associated with it, but it doesn't have to be complicated. Personally, I prefer GUI tools over non GUI counterparts anyhow. These include tools in atom/visual studio code for doing git commits / branching etc.

People are more than willing to learn how to use a WYSIWYG interface if the value they get long term is worth it. Ideally, cost should be minimized (learning) and benefits maximized(building quick blog posts how they want). Blogs are exactly that though, you spend a little bit of time learning the framework, and spend a lot of time using it. The amount a user is willing to learn proportional depends how much they will use it long term.

For a one off task, a user is not willing to spend as much time learning a WYSIWYG GUI tool, and would rather pick something more familiar like markdown or .txt. Examples include learning how to use a new video editing tool, with advanced feature sets (Adobe Premiere, etc) if you don't make videos often. Rather you would prefer learning a simpler tool instead (Adobe spark, etc)

From research I've done the market is largely shifting towards WYISWYG and from a UX research standpoint, this makes sense. Getting exactly what you want lowers the barrier and confusion / expectations of what you receive.

You can quote buzzfeed essays all day, but I always take research with a grain of salt unless (1) the author is reputable (2) it validates research and data I've observed from a number of various reputable sources / my own research. UX is just common sense at the end of the day

------------------------------------------------------------------

> The frontend needs complex information to be able to correctly produce a beautiful design

Not necessarily true, just use a CSS framework and it simplifies a lot of the process. Take your pick with functional CSS like tailwinds, bootstrap, or just modify your own classes. WYISYWG just wraps things in classes as necessary

I've looked at Gutenburg, it looks promising. I've spoken to a number of core devs from gutenburg. I don't really like the tinyMCE editor that much honestly, or the Jetpack installed wordpress.com instance. They both have issues. TinyMCE editor doesn't reflect proper nominal width for a blog at ~800px, so sometimes the results are skewed when previewed live

Jetpack wordpress.com's editor is more closer to what optimal words per line / font-size / width to write should be. However, it has some serious flaws when using 3rd party plugins (such as adding prismJS code snippets) and its a pain to work with


"UX is just common sense at the end of the day."

Oh boy would you be surprised. The whole reason we do research is because users consistently break our expectations, in the most uncommon ways.


+1000


I am running a site on Ghost, and I think it is good - setup was a breeze, and the WYSIWYG is very good. But I'll tell you what makes me not hate it: Being able to use Markdown!


If you ever check out Gutenberg be sure to give the Markdown block a try. :)


> Why does someone select Wordpress in 2018?

I can tell you why I do it. I host a couple of WP instances on my server. One for a non-profit sports organisation I am involved in and one for my mom. In both cases I look after the WP install itself (config, updates etc) and they deal with all the content. WP provides a UI that is easy enough for them to use to do so. I am certainly not interested in building anything “custom” for them.


This. I run a hobby blog, and Wordpress is primarily...not work.


>> Wordpress core continues to be basically a simple blog engine

I think you need to think beyond personal and marketing blogs. WordPress is much much more...

Quartz (qz.com) is built on WP. So was Wired (wired.com) and The New Yorker (www.newyorker.com). I had a hand in both The New Yorker and Wired and may other large media companies are built on WP.

To characterize it as a "simple blog engine" is mis-leading.

Gutenberg, while having its teething problems, is a big change. Big changes will cause upheaval. It will cause both petty and important disputes to rise to the surface.

I think this is no different.


<rant-ish content>

agreeing with sibling, WordPress _is_ a blog engine that has been twisted and squeezed to support other things. BuddyPress is probably the ugliest manifestation of this, one of the slowest, sluggiest, buggiest things I've ever touched.

I praise the extreme simplicity of the WordPress database structure, but that is also a very serious limitation.

Examples if issues:

- WP is ridiculously rigid when you want to scale it - that is due to having it's file storage as and actual file storage, without any abstraction.

- The media library is an utter mess since the backbone.js mockery added in 3.5, with inconsistent use of filter and hooks on backend vs frontend.

- It's forcing compatibility with long dead PHP versions. (5.2. That is before namespaces.)

- I only supports MySQL but maintains MyISAM compatibility, so no foreign innodb keys, no cascade delete, no nothing.

It should never have wished to become other, than a blog/small website engine without first making long, long overdue backend fixes.

But instead, for many years now, I'm seeing the community being neglected; features that are questionable, pushed through (emojis, REST API, Gutenberg); WP.org without a clear focus, and without answering decades old threads, like a database abstraction layer.

All that said, WordPress is easy to use - but I'd welcome an extremely simple, WYSIWYG, small, static site builder instead, with proper support for media, portfolios, galleries, with a WordPress importer, which could easily take over the mess, that WordPress, my once loved CMS had become.

</rant-ish content>


Hi, I have huge respect for you and what you did at the NYer, it's a great site.

I guess my point is... how would you break down the functionality of those sites by Wordpress core, themes or plugins, and custom code? How much of what makes those sites great comes "out of the box" from Wordpress, vs being bolted on or written from scratch?


For The New Yorker, the main site (sections, articles, tag pages) was its own theme.

We used off-the-shelf plugins for for curation/features: ACF, EditFlow, Yoast (SEO).

We also used custom Plugins for building out curation and full content feeds for our iOS app, managing podcasts, and AB testing.

Quartz was different. We only relied on the WP editorial UI (with EditFlow plugin) and simplified the templates to just deliver JSON (this was before they had the JSON-API in core).We built an independent web app on top of that.

Hope that helps answer your questions.


No, it is a simple blog engine that has been stretched, shimmed, cranked, and jerry-rigged beyond all recognition and sanity.

The very idea that people try to host e-commerce on the platform is an embarrassment and a shame to security and safety.

It encourages the pattern of hiring non-technical staff to manage the blog-store-landing-page-franken-whatever site, who are in turn encouraged to install reams of untrusted code via plugins.

It is built on a frankly bizarre pattern of page and route management. It uses broken versions of a fairly broken language. It is enormously resource-hungry.

I could go on, but to sum up, my experience working with WordPress has been nothing but a repeated nightmare.


Definitely this. I've had a Wordpress site for years that I've let sit dormant. Recently I got the "I should build a personal site" bug, but rather than jump on Wordpress I set up a Github Pages site and just put a redirect on my Wordpress site to that one. Why?

1. Static is secure. Wordpress is a notorious target for hackers and I see constant attacks even against my empty, worthless Wordpress site. But you can't attack a site that doesn't take any input or perform any logic besides choosing which page to display.

2. Markdown is simple and does the job. I don't need anything fancy to write my thoughts and link to resources I find useful.

3. I find Jekyll to be more flexible than Wordpress. Technically both can be used to make any kind of static site, but I find the customization friction to be lower with Jekyll.

4. I like the built-in version control I get with git/Github.

5. I like editing my site with an IDE where all files from content to style are intuitively accessible rather than navigating Wordpress' interface.

6. Github pages includes HTTPS and DDOS protection that I don't need to think about (or even know about). It's just built in.

7. It's in keeping with the open source spirit to have my personal site open source. Anyone can go in and look at what I'm doing, how I'm doing it, and even the history of how the site evolves. They could even fork it if they really wanted to for some reason.


Wordpress was never really the competition for you if those are your needs. Here's what wordpress does that most CMS's either don't do well, or cost money to do:

- Have a user friendly administration section that anyone can use regardless of technical expertise (by user friendly, I mean have WYSIWYG editor for all posts and make it extremely simple to manage content via a UI -- not CLI)

- Have roles for users with restrictable access

- Have a plugin ecosystem that allow just about any customization to be easy enough to implement that paying a freelancer to do so is quite affordable

- Have an entire theming eco-system that is very alive, with plenty of free or paid options to make a site look professional


I've been playing with Drupal for a bit and another thing WordPress does better is that you can update WordPress from inside WordPress dashboard, no need to understand anything.

I doubt we will ever see backend changes, like allowing postgresql database though.


Self-updating means that WordPress needs to be allowed to write to more places than just the "uploads" directory. Which is frightening, and a security risk.


Yes, but non-self-updating means tons and tons of sites run by lazy people end up sitting out there on ancient, known-compromised versions of WordPress forever, which is also a security risk (and arguably a bigger one).


Jekyll does have the last two as well:

Plugins: https://github.com/planetjekyll/awesome-jekyll-plugins

Themes: http://jekyllthemes.org/

But I do see your point.


Most people that need a blog or a CMS aren't a self-one-man-ruby-sql-sysop-devop-shop though.

Not the same market.


1. My host handles a lot of security issues on the backend. I just backup a .tar file with the latest revisions on site

2. I personally prefer using WYISYWG, especially when I add images and code snippets. Having to view a markdown renderer means I have to look at two things, unless your using a partial markdown renderer instead on input side (stackedit.io, inkdrop are some examples).

3. Installing plugins in wordpress is easy. The way I do most things is fork entire repos, test it out, and see if its worth learning. This is how I approach wordpress as well, try X plugins disable them all see which works best. With jekyll you have to do install plugins / libraries yourself, I just want to get straight to writing though

4. Wordpress is just bandaid solutions everywhere for me, I only git track changes I make from a base theme (its all just CSS)

5. Wordpress's interface is awful to look at when using the editor in admin panel. But you get used to it. I'm debating in writing a quick javascript extension / userscript that I can toggle to disable all the clutter while writing

6. Had issues with wordpress HTTPS issues that sitegrounds had to fix the otherday, I still have no idea why I didn't have my SSL certificate installed

7. As much as I like opensource, I do a lot of things closedsource.

Wordpress is great for me b/c I can customize it very quickly, do bandaid solution plugins and backups everywhere, and just focus on writing. I don't like reinventing the wheel or building my own tooling if I can avoid it.

Jekyll has always given me build errors in a windows OS environment since its based on ruby. What I had previously is using github-pages and deploying it live to see changes. Still learning netlify. Commits were extraordinarily messy for me actually, I would have 1000+ commits and 990 of them were just minor changes to draft posts. I could probably use seperate branches but out of the box, everything went to master branch


From my experience you use WordPress because of it's massive amount of plugins and themes, and because it's simpler to configure those plugins then other options (like drupal).


Imho ProcessWire is the best alternative to Wordpress if you need to use PHP and are a developer.

It separates the CMS from the front-end and has a very good API to get the data from the CMS.


I’ve use PW before and it’s not too bad. The API is really great and so much nicer than working with WP custom fields (etc). The only downside was the back office... a bit dated (looks like something from 2009). The way the CMS works and the thinking behind it are great though.

Grav is cool, if you need PHP you’re good with flat file.

Off topic, but my most fav CMS of all time is definitely Umbraco. It’s built on .NET, but it’s insanely fun to work on.

Between all three if these CMSes, I cringe when I hear “Wordpress.”


"I don't think that many people were crying out for a fancier way to store giant messy blobs in MySQL."

If you've ever had to deal with out fo date, page builder generated shortcode messes, that is actually a problem that people would like to solve :D

Like, a standardized way of creating a mess is much better than 10 unstandardized ways to make a mess, right? But that's most of modern JS and PHP work anyhow :D


Why does someone select Wordpress in 2018?

Because for whatever reason, people are failing to realize that Blogger is vastly better.


I think their problem is they still think of WordPress as firstly, a blogging platform.

This is good for bloggers and wordpress.com but adds nothing for anyone that used WordPress as a base platform for something different.

It's the something different that differentiates it from SquareSpace.


Gutenberg makes blogging actually very difficult. You can’t just write because everything is a block or some other element …

https://www.manton.org/2018/10/23/wordpresss-gutenberg-vs.ht...


Then you have to wonder who it's for. It's seeming like an excuse to replatform like Magento 2 did but try to force everyone over.

There are as many sites still on Magento 1 as 2 which they would want to avoid.


Gutenberg was designed to attract new development talent. No one brags about being able to do OOP/OOD in WordPress. Unfortunately they choose React and that will turn out to be the biggest mistake Automattic ever made.


I think this probably cuts to the core of the reasoning behind Gutenberg more than many other thoughts on it do. It's not about making WordPress better, it's about seeming 'cooler' among other developers by embracing the new shiny thing (React) rather than going with a simpler, more battle tested solution written in PHP and Vanilla JavaScript.

And I suspect this is the case with quite a few recent WordPress changes to be honest. The people behind it don't want to be seen as the folks making the 'beginner' or 'amateur' CMS, they want to be up with the 'cool' kids working for Google/Facebook/Netflix/Airbnb/whatever with React and Vue and Angular and what not. For them, stuff like Gutenberg (and arguably even the REST API) feel like attempts to move WordPress away from the 'CRUD sites for small businesses and non programmers' market to the 'professional' one.

Yet that's exactly where the market is for WordPress, and that ease of use that attracted beginners and lower end agencies is why WordPress got so popular in the first place. You didn't need a lot of experience with frameworks and build processes and MVC structures and what not to get started, you could just copy or hack together some simple code to get things the way you wanted, and use third party themes/plugins to do the rest.

Trying to make things more complicated or move the core of the system over to a JavaScript framework basis (as some suspect Automattic may be trying to do) will just kill a large part of the WordPress community, and remove the ease of use aspect that makes it so popular at all.


> I think their problem is they still think of WordPress as firstly, a blogging platform.

That's not a problem, Wordpress is literally a blogging platform.

> This is good for bloggers and wordpress.com but adds nothing for anyone that used WordPress as a base platform for something different.

If your application's scope is outside of a blog, Wordpress is the wrong tool for the job. There exists multitudes of frameworks written in any given language that follow the MVC design pattern (some better than others of course) to choose from.


Having trialled the new offering thanks to a banner in my Wordpress dashboard, I went right back to the old editor. Trouble with the new one is the UX is hostile - everything needs an extra dozen clicks for the most simple things.

I want to publish a post about as fast as writing a text or word doc. The current wordpress editor is unexciting but has a fairly decent workflow. Faffing about with everything on a pulldown or modal is not progress.

A fair summary of my views of Gutenberg:

https://www.dedoimedo.com/computers/wordpress-gutenberg.html


It may need a few extra click for simple things. But it makes slightly more complex things much simpler


But most of the time one does simple things. Hurting the common case to improve a rare case is rarely a good tradeoff.


The common case for wordpress hasn't been just blogging for quite some time now. The common case is brochure sites for businesses. I wouldn't be surprised to find that writing a simple blog post is actually the rare use case these days.


This is the Achilles heel of Wordpress.

WP is now getting a a TON of competition from static site generators, and companies like Netlify. Headless CMS' and Jamstack are the future for these types of sites and people are coming off of Drupal and Wordpress in huge numbers.

As their numbers have shrunk, they've had to make drastic changes. I haven't been seriously involved in the WP community for about five years, but I've heard rumblings within the community about moving to a modern stack that includes ReactJS or VueJS for a while now.

At the very least they're trying to maintain their position and modernize WP to appease some of the critics and vocal members of their community.


Agreed on that. Bloggers have left for hosted solutions, Medium and the like. But still most small business content editing is predominantly basic text and images, so editing experience needs to be tailored for that.


I really like it. About 9 months ago I started working on a plugin for my workplace to turn the platform into a logbook for our researchers, and got to build from scratch for the new platform, so to be fair I am not experiencing any of my prior work breaking, but I do like what I see.

Adding extra behaviour to the classic editor is fragile, especially if the feature involves adding or changing something about an existing part of the UI. Gutenberg makes this relatively simple, and at least provides a blessed way of doing this (via plugins), whereas before you relied on the structure of the editor's HTML not changing and breaking your stuff.

Furthermore, everything is retrieved and sent via the REST API which seems like a great approach: it means you can reuse your plugin logic for other parts of the site, and in principle the new editor can be bolted on to some other non-Wordpress projects with only a few adaptions, and WordPress itself may one day be implemented in something other than PHP.

One other thing I like is the ease of use of Gutenberg. While it takes a few extra clicks for things, novices won't care about that, and having more visual clues will really help them. Plus, the blocks now give you a way to make things truly WYSIWYG, especially shortcodes which are otherwise just short strings that only generate their content when you preview the page. Now it's possible to make blocks instead of shortcodes that render whatever needs rendered in the editor.

I guess Automattic could have handled the development better, and given more time for the update to be tested and for the community to be informed and give their feedback. In 2017 they kept saying they'd release it in early 2018, which has come and gone, so I can't help but think they're pushing this out in a desperate bid to hit their original deadline at least in terms of the year. That part might bite them later, especially if there are any huge bugs yet to be discovered.


I used it for a recent WP site and found it quite intuitive to use. The generated code is clean, and it integrates well with shortcodes and third-party content. I generally prefer code view to WYSIWYG, but it's one of the nicer editors I've used.

I found some of the keyboard shortcuts to be unintuitive. Toggling between code and visual modes required four button presses. Edit>Redo is also weird as it uses Ctrl+Shift+Z, not Ctrl+Y.

Overall though I think it's a positive change. I hope that Gutenberg manages to kill all those awful page builder plugins like WPBakery and Visual Composer. That would make me happy.


> Edit>Redo is also weird as it uses Ctrl+Shift+Z, not Ctrl+Y.

I am always confused which shortcut to use for Redo on Windows. Microsoft software is Ctrl+Y but I must've grown up using software that chose Ctrl+Shift+Z as that's what I always try first.


Commented a couple times here, but we've been making a concerted effort to inform past clients of the coming of Gutenberg.

It seems that outside of the dev community and people actively involved in WordPress news, there's very little familiarity with the fact that Gutenberg is coming.

We've launched a productized service[1] that helps people take an audit of their site, get familiar with using Gutenberg and give them resources to make the transition.

We've mostly found that's it's been going smoothly, but there are plenty of cases where sites have different customizations that will need to be worked around or refactored.

The Gutenberg team is working hard on making sure legacy things are handled properly, but there's a lot out there and it definitely needs to be taken on a case by case basis.

[1]https://alphaparticle.com/gutenberg


I work at an agency building large websites for a variety of clients, and so far am in love with Gutenberg. The block based approach is huge, especially for many of our clients in the news and editorial space that write long pieces of content with a lot of different components (text and images of course, but also quotes, asides, interactive embeds, donations, related stories, etc).


I got into WP to build a site that tracks robot teams and competition events. I didn't want to write PHP but found a great plugin called PODS. It allowed me to do all the inter-page linkage (orgs->teams->robots) without any PHP. Another plugin does calendar stuff for the events.

It was quick and easy to set it up, and works pretty smoothly.

I've tried Gutenberg and wasn't that impressed. It wasn't adding to anything I was doing and it managed to break two small items.

I know that the WP people are trying to go against Wix, etc. I'd like to have also seen them split into the new React and kept the "classic". I'll most likely become one of the 1000's of sites that become frozen on a 4.9.x release. It will be interesting to see if there are updates in the 4.9 tree or if it will be 5.0 only.

I look at the Wix, Weebly, etc market place has being worth WP going after and I'm sure they will try to pull company/vendor sites from the Facebook and I'm good with that. But one of the powers of WP is the ability to make pretty complex sites using PHP/Plugins. Moving to React isn't going to make that easy.

I really think that this is a case of dumbing down a product may not be a good idea for lots of the current users.


This article is a year old. Does anyone know the current status of the Gutenberg release? Article says first half of 2018 and we are well past that.


The 1st beta of WordPress 5.0 was released today (which includes Gutenberg). Outside of discovering any major blockers, the current plan is to release 5.0 on November 19.


3.5 weeks feels awfully short to go from beta to production on a change so big. Isn't Gutenberg going to be the new default, no opt-out? Kind of makes me nervous.


You can still opt-out by installing the Classic Editor plugin[1]. That will disable Gutenberg and let you keep the current experience.

[1]https://wordpress.org/plugins/classic-editor/


There's also this plugin which removes all other references to Gutenberg so if you're building sites for clients they aren't able to accidentally switch the classic editor off, and don't get nag screens about trying Gutenberg. https://wordpress.org/plugins/classic-editor-addon/


Beautiful! Also, that makes perfect sense. Thank you for the link!


There's been a stand alone plugin activating the Gutenberg editor out for ages now. You can install it and test how things work right now in 4.9.8 or whatever version you're running.

So this 3.5 weeks thing is a bit of a distraction.

https://en-gb.wordpress.org/plugins/gutenberg/


I'm not sure about 5.0, but in 4.x, using the Gutenberg plugin, you can embed instances of the Classic Editor within Gutenberg blocks.


It's far enough along that they're actively pushing it at people who update their WP installations. There's a big banner on the front of the dashboard urging you to try the FUTURE OF WORDPRESS.

I did. I went back to the old ways.


As well as the first 5.0 beta, Gutenberg has also started to show up on the Dashboard as a prominently promoted optional recommended plugin upgrade for 4.x installs sometime recently (I noticed earlier this week and installed it to trial it immediately).

I'm guessing that Dashboard push may have motivated this being posted here.


I did not know that their motto is:

> ‘Clean, Lean, and Mean’

And even after double-checking, I can only assume it's somewhat outdated, or outright irony. Because while I consider WP among the software that has done the most good over the last few decades, those three words really don't come to mind when trying to describe it.

Of course at the time it came out it's immediate comparisons where these $7-digit behemoths being sold to Fortune 500 companies, and it probably did not rely on plugins as much as it does now. So I can see how clean & mean made sense at the time.


I think they mean the core is clean, lean and mean. The reality is that most people will use themes, customisations of themes and a stack of plugins so what you end up with on disk is none of the above.

Most of us never have to touch the core though.


The core is a mess too. And they refuse to modernize their code.


The way data is stored is very frustrating. Storing what should be json as html so it could try to be backwards compatible.

I made a library[1] to make blocks so I’ve been using Gutenberg a few months. Feels like it could be really really nice if a few changes were made. I commend the WP community for making it though.

Big issues are with trying to make more than just a few blocks, the editor really doesn’t enforce and code splitting. So unless you’re using a library like the one I created, having let’s say, 100 blocks is going to mean an insane amount of JS on page load. Also, good luck trying to debug the stack traces you’ll get in browser. I could go on but the point is: Gutenberg is a nice idea but real projects will find issues.

[1] https://github.com/Crossfield/gutenblock


Howdy — lead of WordPress here. When the article was written in January of 2018, I would agree Gutenberg wasn't ready for core. Ten months later, it's come a long way. There have been 41 public releases of Gutenberg, and close to 600,000 sites are using it already. It's the mostly widely tested (and adopted) new feature code we've had in any release of WordPress in my memory. It might not be for everyone, which is why we created the Classic Editor plugin which you can install today, and when 5.0 comes out in a few weeks your site will look and work pretty much exactly like it does today, and you can migrate to Gutenberg at your leisure, or perhaps not at all. (There are lots of ways to post and interact with WordPress, including the command line via wp-cli.)

A big advantage of blocks is they will allow us to simplify many of the different concepts and interfaces throughout WordPress, including our old WYSIWYG sorta-blocks, shortcodes, widgets, menus, and embeds of all types. It solves literally hundreds of interactions where people used to get stuck in our old WYSIWYG and either switch to code view to fix things, or just give up. Like all software, the 5.0 release of WordPress isn't a finish line, it's a starting one. We are already planning for 5.1 and beyond (including minimum PHP updates) and we look forward to bringing the fast, public iteration cycle that Gutenberg has demonstrated to more parts of core.


Hey Matt! I'm not denying the massive amount of testing and effort going into Gutenberg, as I do see it. I am however worried about the new block editor hurting the good reputation WordPress has, particularly in regards to accessibility.

Hacker News isn't the right place for this discussion, I know, but I want to get it out there. Accessibility is one of the best features of WordPress, even if most people don't know about it. Keeping the WordPress editor accessible not only helps people with disabilities, as it also aids people who may have a temporary ailment (holding their baby, and just having one hand available, for example), or even "invisible" disabilities such as dyslexia, ADHD, or an Autism Spectrum disorder.

The new block editor has made tremendous strides at improving individual component's accessibility recently, and I believe that's where the confusion and miscommunication comes in between all the core teams. Code-wise, the block editor is quite accessible; zoomed out, the editor as a whole isn't. It's a UX issue, more than a development one. It's what happens when the design isn't with accessibility in mind.

I don't think it's worth punting release, but I really would like to see more work on documentation and warnings in the core to people who rely on assistive technologies. If you don't know the layout of the block editor and had to navigate it with only a keyboard and no eyesight, it's incredibly confusing! If there was proper documentation, you might be able to explain the layout and mechanics, which would help, though still not solve all the problems.

If someone is blind and has a blog, in my experience, 90% of them use WordPress because it's very friendly to them when they want to write. It's not a fair comparison, as TinyMCE merely is a glorified text-field, but that's also one of the old selling points of WordPress -- super simple out of the box.

It's my understanding that a lot of the preliminary design for Gutenberg was behind closed doors inside of Automattic, before publicly being brought out to the public and collaboration ensued. I don't believe there is anything wrong with this, as it happens within many FLOSS projects by corporate interests that rely on the platform. I do though wish that in the initial design phase, accessibility was a goal, not an afterthought. It may have been a goal too, not denying that, but there might have been a lack of expertise in regards to how to make interfaces fully accessible.

I don't mean to attack the editor, Automattic, or you about this. I know you've heard a lot about it. I love the block editor; it's such a pleasant experience for me to use. I worry that people though who aren't as able-bodied as I won't feel the same though.

Finally, I have a hunch that Automattic itself has now found that it needs expertise on Accessibility, which is why there's this: https://automattic.com/work-with-us/product-designer-accessi...

I do believe in WordPress.org, and I love Automattic as a company and their stance in regards to the open web. I like that Automattic is a company built on my personal-favorite legal document, the GNU GPL. I'm looking forward to the day that the block editor is accessible, as it's not now. I do believe it will be. I only wish there was a stronger push before :)


The best read about Accessibility in Gutenberg is here:

https://make.wordpress.org/core/2018/10/18/regarding-accessi...

Accessibility has been thought about from the beginning, and no design happened behind closed doors (it was kicked off and announced at WCUS 2016), but we are doing a fundamentally more complex task with block manipulation.

I'm not sure what the best path forward is there. We'll continue to make the block editor friendlier to accommodate accessibility needs, and I also think it's important that WordPress has a variety of ways to post to it, from email, to other apps, to the command line... by supporting as we always have a ton of ways to get content in and out of WordPress it'll allow people to use the interface they enjoy the most.


I was thinking of another Gutenberg: https://github.com/Keats/gutenberg / https://getgutenberg.io

It's a static site generator.


I am going to change name for the next release because of the confusion though!


And miss out on the free discovery?


Not really free discovery when every search will be about the WordPress editor or Project Gutenberg and a static site generator will be on page 3-4 :/


Background: Had a walkthrough demo and code dive at our PHP group a few months ago. One of the guys in our coworking space runs a WP user group. I've used WP for some projects for years. I like it for small to medium content, but have hated doing large "dev" projects on it (ecommerce, etc)

Gutenberg thoughts: It's seemed to me that much of WP success in the last several years has been driven by the ecosystem of page/theme builders, which have been built around serving various verticals. They've solved a core problem of not having easy baked-in structured data management, and Gutenberg looks like it's a first step in standardizing that. It seems the tools community will need to adapt to that, which they might, but it also seems like it might be taking away some of their value-add, and there may not be enough room higher-up the chain to add value.

I don't know if there's a huge reason for some of the theme/page services to rush to support the upgraded 5.x series; if it makes it easier to switch to a competitor... will they have much incentive?

This is certainly a shift in the WP world, but it feels like it's at a point where they could lose a chunk of users to competitors. For a lot of other users, though... where would they go? As with many upgrades, if the pain is too much for not much value, that's a time when people would consider other options more seriously.


I did end up at the Boston wordcamp conference where one of the Gutenberg developers was speaking as the keynote.

Like the article says: They see for-profit site builders: squarespace, wix ... as eating Wordpress market share and feel a need to advance Wordpress to make it competitive. They know it’s risky but they see it as an important way to stay relevant.

Wordpress users seem on board with this. A lot of them aren’t developers and want easier solutions to hand their clients.

(Except the guy with the “Gutenberg not in core t short”


Gutenberg allows to write structured documents just like you should do with a word processor.

I can imagine many people having trouble to adapt because they are not familiar with using styles and templates.

I was not familiar with Gutenberg and was offered to activate it a few months ago. I did so and manage to make it work for me.

I consider that writing structured documents is part of personal advancement in IT and should be viewed as such.


I got scared from the title because I thought that project Gutenberg[1] had died or something

[1]https://www.gutenberg.org/


What an incredible shame that would be! I just hope that we can get some copyright reform someday, at least for non-Disney entities. It's absurd that it can be easier to find a bestseller from 1850 than one from 1950.


This article was published in Jan 10, 2018; what's the current state of Gutenberg?


Gutenberg has been progressing on GitHub. It just got merged into the beta version of WP 5.0 release today, which is slated for general release on November 19.


Will be the default in 5.0 of which Beta 1 has just been released (which probably prompted this submission)


I love the Gutenberg interface.

However, I also think Automattic has made life for themselves much, much harder by fragmenting the code base like this. WordPress was always monolithic in its approach, and trying to tack on a (newer, more modern, but still wholly different) core component is a major risk.

I'm working on a migration plan to some other platform as part of our business continuity plan. The stability of WordPress was its biggest selling feature. Now, that will no longer exist.


We build sites with complex data structures on WordPress using CMB2 for custom fields. I think Gutenberg has its place, but if you want to build anything of any real size you're going to need data structures (i.e. content types with defined relationships), and Gutenberg doesn't allow that. It's an odd kind of structured layout tool that I think will confuse a lot of people.

For all their faults (which are less and less as it develops), WYSIWYG fields using TinyMCE have the massive advantage that they look like the word processors that most people are familiar with. Beyond small personal blogs I just don't think Gutenberg adds any value, and if anything muddies the water for site editors if you're using structured data and Gutenberg.

We've taken the decision to disable Gutenberg entirely and just use custom fields so we can maintain stable data structures, rather than trying to crowbar that into Gutenberg somehow. All you need to do is only use custom post types without the "editor" capability, hide the Posts menu item, and define everything through CMB2 custom fields.


I build Django sites often based around TinyMCE and this is my experience. If you've got a blob of content then drop in an MCE field but the minute you're dealing with structured data - WYSIWYG often makes things more complex.

TinyMCE really is quite extensible and flexible if you keep to it's sweet spot. It can produce fairly clean and consistent markup based on a whitelist of elements - which is critical if you're storing HTML directly in a database field.


I thought this article was pretty insightful, regarding Gutenberg and Automattic's response to the open source community: https://foliovision.com/2018/10/gutenberg-f35-of-cms

And since then, these two troubling things have happened:

Oct 9, Accessibility team lead resigns over Gutenberg - https://wptavern.com/wordpress-accessibility-team-lead-resig...

Oct 17, Accessibility audit canceled, because the new accessibility team lead "didn’t have the authority to authorize it in the first place" - https://wptavern.com/gutenberg-accessibility-audit-postponed...


I get that Automattic wants to compete with Wix, etc, but throwing the Wordpress community and ecosystem under the bus is not the way to go.

Gutenberg has its place in the web dev world of 2018 but it should have been a completely new project instead of a replacement of good old Wordpress.


The thing that really concerns me with WordPress and Gutenberg is performance. Gutenberg is great but there is never much concern to making the front-end less top heavy. Gutenberg is likely to make this worse. Each block will add it's own CSS and JS...and the bloat will be immense. Instead of users adding a single page builder plugin, they'll add a whole bunch of individual blocks and each one will load more and more external scripts. PageSpeed scores will be dismal.


Blocks need not do that, and most should be no more overhead than what people were already doing in posts. Perhaps is a big focus though, but one that's been easier to address outside of core with things like expanded CDN support in the latest version of Jetpack Photon.


I like the Gutenberg approach a lot.

Maybe it still requires some polishing but I think that people don't like it mostly because it is something new and they are not used to it yet.


Fyi, I would really like to keep as far away as possible from wordpress.

On the other hand, while everyone predicts the death of wordpress, there is still no viable alternative. So many projects on Indiehackers start on wordpress still. There is still no customizable, verstaile alternative for wordpress in spite of its many failings.

If there is an alternative with an ecosystem as big as wordpress, or atleast has the growth potential to become one, I am very eager to know.


> If there is an alternative with an ecosystem as big as wordpress, or atleast has the growth potential to become one, I am very eager to know.

There probably won't be, because it would introduce many of the same problems WP has.

If you want an ecommerce platform, there are plenty to choose from. Throwing 'woocommerce' on top of your blog solves some problems, but creates (many) others, and if your focus is ecommerce, use a more focused platform. It's the "it can do everything for all people" aspect which has created some of the problems we see.


To be honest, I'd say WooCommerce is probably one of the easiest to use solutions for eCommerce. I mean, Magento is complicated enough that whole companies exist around it and where anything less than a VPS is probably not gonna handle it well, and OpenCart is a bit of a car crash when it comes to figuring out where to get support/decent plugins/documentation. Given those types of alternatives, well, at least WooCommerce is simple enough to pick up for someone who's used WordPress before, and doesn't require learning a whole second overly bloated/complicated CMS system to set up.

What is the best solution for a decent shop nowadays? At least if you want to host it yourself and not rely on a service like Shopify?


Setting up Magento 2 requires a developer, there's no way around that as you need to do a lot of setup using the cli.

WooCommerce on the other hand is all plug and play and easy enough for a lot of shop owners to self-manage.

Magento's admin interface is superior and if your catalog is in the order of 100s of thousands of skus, nothing else is going to cut it. But as you said it needs a lot more server to run effectively.


> Magento is complicated enough that whole companies exist around it

That's an odd metric. There's loads of companies around wordpress and plenty of companies that focus on woocommerce implementations - that's wholly separate from the complexity of the systems in question.


i briefly inherited a woocommerce system with 62 plugins, and because it was so 'easy', the original devs hadn't bothered with things like child themes or version control or documenting any thing they did or why. The WP ecosystem doesn't easily allow for dev sites / testing, and at least one of the plugins was tied to a domain name and wasn't easy to use on non-prod systems.

Paid support from some plugin vendors always ends up with "disable all plugins except ours first and run everything that way before you ask for anything else". "Even the plugins that this one depends on?" I'd ask, to no reply. I understand why, but plugin vendors will point the finger at other plugins - sometimes rightly so - but when so many plugins can change global state all the time, it's a pain to track down what's breaking.

Any time I bring experiences like this up, I'm told "no one has 60 plugins, that's horrendous, I'd never have more than 5 plugins on any WP project ever, you should have started over, you're exaggerating" - some combination of those sentiments. There were 62 (or 65) plugins - IIRC somewhere around 10-12 weren't actively used.

When I inherit projects, I often argue for greenfield rebuilds with the lessons learned from the previous project. When that goes through, I often hit a valley of "we should have refactored". When starting off on the "refactor" path, I often hit a valley of "this should have been rebuilt". There's often not much way to put good tests around WP stuff to get the confidence and repeatability needed to move forward with large scale customizations.

If you start from scratch, have a talented team who understands all aspects of WP development and document things, perhaps it's "good" to start with?

If you're selling a handful of items... yeah. If you're happy with existing themes and don't want any substantive behavioural changes to how themes/plugins work, yeah. Use it. When you want custom or large changes to how the $80 theme sellers think you should run an ecommerce store... I wouldn't recommend it, and I don't know what I'd recommend, really.

Other options: The Sylius project? Foxycart?

Some of the commerce projects I've dealt with are doing hundreds of thousands of dollars, up to millions in sales. They were pushed to woocommerce because 'it's cheap, can do XYZ, no need for "expensive programmers", etc'. You're doing $800k in sales and have no unit tests on the code running your entire operation? On top of that you want changes to fundamental code bits, without easy to setup dev/test/staging/prod workflow or unit tests? Scares the crap out of me. But yeah, I'm not a WP-head, so perhaps you get used to that level of "seat of the pants" working? Or... you spend so much time/effort setting up custom workflow that you can now easily churn out "woocommerce" work with some level of repeatability and confidence? You're probably not on the 'cheap' end, which is often a selling point for WP/woo work.

No doubt, I know that the woocommerce base is used on some big projects. I also have to imagine they had larger teams of people doing custom work fulltime for a long period of uninterrupted time. If you have that team and are doing customizations and integrations, you're not in the realm of "I need something simple that's not magento".

Ultimately, it depends on your needs and skills. Solo/small team, already 'know' WP with existing skills in that world, use woo - knock yourself out. But don't color too far outside the lines.


This...

For a WordPress only site, half a dozen plugins for specific functionality is what I aim for.

But WooCommerce, they pile up really quickly just for core requirements like payment gateways, a quickview, wishlist: Things that are core or would be baked into the theme in Magento.

62, wow. I flip out if they had half that. Usually they're running some sort of cruddy backup system, multiple security plugins because they got hacked previously (not surprised) and a dozen plugins that they don't need.


Great points, I do believe any software has a lifecycle and WordPress is at the end of the road. Curious to see if Getneberg can change this situation.


It would appear that I'm the only one reading this who uses TypePad (since 2004). True, it's clunky, unchanging, and very slow — but that translates to ease of use and reliability.


What are the economic opportunities for React developers with Gutenberg?


This is a step in the right direction. -someone that stopped using WordPress when porn started appearing automatically in random folders because the view tech is php


Writing as an English coder ie I code in the English language so that the human compiler can parse what I write aka more of a hack than a hacker.

Wordpress.org appeals to hackers, but Wordpress.com appeals to hacks. No tech support needed, no 3am beepers because a badly behaved plugin wet the bed.

So I am happy that Wordpress is slow to intro new software. Make it work and make it intuitive. Wordpress is the least annoying tech vendor - like Apple in their best days (not now sadly). Not perfect - who is? Would like better wysiwyg editing. But bigger beef is search. It sucks. I use Google to find info on my own site.


You might like to try https://searchwp.com if you're hosting your own site (it wasn't quite clear from your comment).

It lets you tweak search results by giving different weights to titles, categories, excerpts, and more. I'm not affiliated, but if the default search is no good on your site it might help you get the results you expect instead.


A bit of history:

Up till 2004, the king of all blog software was Moveable Type, written in Perl. In theory, you had to pay for this, but there was a liberal free license. Then in 2004 they got strict and said, hey, everyone has to pay.

This set off a movement to find another free blog software package. For awhile it seemed like there were roughly a million blog software packages, written in different languages. PHP was easy to learn, so it gained traction. Blossom was big, Typo was big. Then WordPress gained traction.

During the long era when other blog software was dying, and WordPress was emerging as the clear winner, the success of WordPress was driven by the understanding of BDFL Matt that designers loved it. It worked well with software such as Dreamweaver. People came to PHP because it was easy to learn, and so WordPress should also be easy to learn. Because of this, Matt insisted that WordPress stick with PHP 4, rather than PHP 5, for many years. I believe PHP 5 had been around for 6 or 7 years before WordPress began using it. I believe Matt was worried that the Object Oriented ideas in PHP 5 would be difficult for newcomers to learn.

I believe the decision to stick with easy-to-learn PHP 4 was essential to the success that WordPress enjoyed during that era.

Which is why I am so surprised by Gutenberg. Telling the whole community that they need to learn React is a shocking change of tactics. Instead of focusing on easy-to-learn, WordPress suddenly wants to become best-of-breed? That is a different niche in the ecosystem of CMSs. Once a good value Honda, WordPress now wants to be the high quality BMW.

React radically increases the amount that new developers will have to learn to become proficient with WordPress. And if you're asking developers to radically increase their investment, then suddenly they are going to consider other options, such as Ruby On Rails. If WordPress suddenly becomes one of those frameworks that needs 2 years of hard study before you really understand it, then maybe you should be learning some other framework during those 2 years? Because there is also a lot of ugliness and technical debt in WordPress, things that made sense when the focus was "make life easy for designers" but which don't make sense if the goal is "be the best framework."

I was around in 2001 when PHP-Nuke decided to go down a similar road. The decision was made that it would be refactored into a series of components, each of which would have an elegant interface for interacting with the other components. PHP-Nuke was going to clean up its technical debt, become more secure, adopt best practices. But previously it had been playing the role of "easiest way to set up a blog or forum". It gave up one role and tried to become something else completely. It self-destructed. Two years later it was dead, no one was using it.

It seems to me that WordPress is going down the same road as PHP-Nuke. Obviously WordPress is a much bigger community than PHP-Nuke ever was, but it seems like it is making the same kind of mistake. I thought Matt was extremely wise for sticking with PHP 4 for so long, but Gutenberg seems like the kind of mistake he would have been making if he'd adopted PHP 5 too soon.


> Once a good value Honda, WordPress now wants to be the high quality BMW.

This is the heart of it.

To extend the analogy further, they actually could take a page from the car industry. When Toyota and Honda and Nissan wanted to move from the value-for-money segment into the luxury-car segment, they invented new brands for those luxury products (Lexus, Acura and Infiniti, respectively) instead of trying to convince people that "Toyota" and "Honda" and "Nissan" stood for something different today than they did yesterday. And this strategy has been quite successful, letting them grow into a new market without undercutting their hard-won position in the old one.


Very good insight. WP should take your words to heart.


Developers only need to know React if they're building editor components. I'd imagine the overwhelming majority of WP developers won't need to touch it.


Have tried it? It's really buggy. The head of UX quit because of the amount of bugs.

Not only technical bugs, the UI is poorly designed.


I thought it was the lead of accessibility, Rien Rietveld, who quit?

The article announcing Riet's resignation is https://rianrietveld.com/2018/10/09/i-have-resigned-the-word... (Working at time of writing this comment)


After reading resignation you've linked... That's no way to lead an innovation. Especially for such a big FOSS project.

Automattic's position of quite verbally "throwing" Gutenberg at users and developers at any cost just shows a really bad example of business driven FOSS project as a base for commercial product (.org for .com).

A11y is just one of the victims. Other community members creating WordPress based websites, services and plugins (myself included) are mostly thrown overboard as a collateral damage. Either learn react fast and figure Gutenberg out by yourself or maybe we'll let you come back later if and when we get to work at least on some documentation and the well-known issues that affect you. With Gutenberg's extensibility being the biggest and most harming one for WP ecosystem.


"The head of UX quit" - source?


The only way to "save" WordPress is to destroy it. The core was not written before PHP had classes, but the project chose to maintain backwards compatibility with a project that was. It's the worst popular codebase, and as this shows, it can't be modernized without changing it into something fundamentally different.


tbh, ive moved away from Wordpress, I find it too bloated for my needs. I been experimenting with Jekyll, and think eventually ill move over to Hugo.


anyone have a sense whether this frontend could be decoupled from the php backend ?


Would love to know as well!


WordPress is having their "Thesis 2" moment. Ironic, really.


It's the end, but it would have died anyway. While WordPress's success is amazing, it's still a pile of PHP that requires constant diligence to keep it running safely.

I use it myself for a simple corporate blog, because it's so widely supported and everything else sucks even worse....


> I use it myself for a simple corporate blog, because it's so widely supported and everything else sucks even worse....

So how is it the end if everything else sucks? Maybe they are stumbling here with Gutenberg (I haven't tried it or even researched it much), but it seems far from the end.

I still don't expect anything to overtake WP. A big reason is that too many agencies rely on it at this point, they aren't going to want to switch to anything else. Also for lower budget clients, pitching anything other than WP is a hard sell these days, as an increasing amount of non tech-savvy users are familiar with it.


Are you not able to use a static site gernerator? Or do non technical people need to update it?


> and everything else sucks even worse

That's why it's not the end.


Gutenberg converts tasks that used to take 2-3 clicks into 10-20 click tasks, or even worse makes them impossible altogether.

What is with catering to the worst and most clueless users only? We need more than that. We deserve more than that. Gutenberg is disastrous for anyone with an IQ above that of a carrot.

But are there any real alternatives?


What is with catering to the worst and most clueless users only? We need more than that. We deserve more than that. Gutenberg is disastrous for anyone with an IQ above that of a carrot.

Well, insulting hyperbole certainly isn't going to help.

From what I can tell (I haven't used Wordpress in a long time, so I didn't know about this), the main complaint is it's more touch-optimized, and as a result desktop editing with trackpad/mouse is more complex.

That's a fair criticism, but not a conclusive argument against. If the most common use case for non-technical users is a touch interface, then making that the default, and giving highly-technical users who prefer the old editor a way to swap back to it... seems like a perfectly reasonable decision to me, and one that should be made on the basis of user research and usage stats, not on the basis of people who sling insults and leave 1-star reviews on a plugin marketplace.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: