Hacker News Reader

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.

https://github.com/ClassicPress/ClassicPress

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

The Joomla fork of Mambo is a good example.

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.

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

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.