Massive props to Studio 24 for showing their working in public on all of this. It is amazing to see. More large scale projects of this kind should do this sort of thing.
Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!
There are a couple of interesting things in this article.
1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.
2.
> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?
Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.
3.
> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.
This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.
- Use Craft
- "We are currently considering a Headless CMS option for front-end page delivery"
It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".
Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.
Further: the headless CMS option.
Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.
One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?
Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.
Its really thrilling to see someone think technical decisions out loud. So keep it up, despite what I am about to type!
There are a couple of interesting things in this article.
1. It is absolutely remarkable they got 15 days to rather requirements and choose a CMS. Having worked in a couple of agencies, this is a lot of time, which is to the good W3C paid for it.
2.
> We have very talented front-end developers, however, they are not React experts - nor should they need to be. I believe front-end should be built as standards-compliant HTML/CSS with JavaScript used to enrich functionality where necessary and appropriate.
It makes a lot of sense for websites to be written in HTML/CSS in this progressively enhanced way, but does it make sense for complex user interfaces like any WYSIWYG editor?
Even the Classic Editor basically dropped probably thousands of lines of (actually third party) Javascript into the mix in the form of TinyMCE.
3.
> We won’t stop trying though and plan to do more R&D with Gutenberg in the future. The W3C project, however, did not feel like the right place to do this. On a project as wide-ranging as this one, development time does become a factor.
This is about agency and project risk which is entirely fair enough. However, what is slightly strange, if risk of delivery due to unfamilar technology is a factor, is that the project then goes onto make two other decisions.
- Use Craft
- "We are currently considering a Headless CMS option for front-end page delivery"
It is unclear from this piece if they have much experience using Craft, but my project manager alarm bells are ringing a bit when a team is intending to "deliver project in technology they have no internal expertise in".
Of course, Craft is by all accounts excellent, but could be a source of problems. The judgement is between the technical difficulty of using Gutenberg and learning a whole new CMS as a developer.
Further: the headless CMS option.
Do the team have the experience of doing this? Where I currently work we are actually considering moving back from headless CMS because the current leader in the field, Gatsby, has some pretty major downsides.
One of the reasons is that site build time is terrifically slow. Their approach seems to be roll our own headless thing with Symfony which will presumably do calls in real time. Symfony is very full-featured, but this seems like rolling your own headless framework - who is going to maintain it?
Of course it could be very simple, but launching a project in: an unknown CMS, with an unknown way of doing a website, seems a strange move when one object seems to be reduce technical risk.