
Should we decouple Drupal with a client-side framework? - ingve
http://buytaert.net/should-we-decouple-drupal-with-a-client-side-framework
======
hunvreus
Honestly, Drupal is doomed. I wrote about it years ago when I left the
community [1] around the time many of the smart folks who were contributing
started moving on to better things.

Just a look at Google Trend for Drupal [2] shows you that it's been declining
steadily since 2009. Comparing it to Wordpress [3] shows you the extent of the
gap with the leader.

Drupal has always been stuck trying to address an odd user; not exactly a
developer, but somebody technical enough to leverage the insane amount of
configuration interfaces that allow you to compose a Drupal website.

Personally, I think most CMS have it wrong: coupling content management and
front-end generation is a sure way to end up spreading yourself thin and not
properly addressing either problem. I think content API (e.g. Prismic.io or
Contentful) are good examples of what a better approach could be.

Have a content management system that has great editorial tools and exposes
the content through an API and let developers do what they do, integrating the
content from the API.

[1]: [http://teddy.fr/2013/01/25/dropping-the-
drop/](http://teddy.fr/2013/01/25/dropping-the-drop/)

[2]:
[https://www.google.com/trends/explore#q=drupal](https://www.google.com/trends/explore#q=drupal)

[3]:
[https://www.google.com/trends/explore#q=drupal%2C%20wordpres...](https://www.google.com/trends/explore#q=drupal%2C%20wordpress&cmpt=q&tz=Etc%2FGMT%2B5)

~~~
huskyr
> I think content API (e.g. Prismic.io or Contentful) are good examples of
> what a better approach could be.

I wrote about this in a blogpost a couple of months ago called 'the perfect
CMS' [1]. I think Contentful is pretty spot-on in terms of features, but i
would really love to see an open source project (like WordPress or Drupal)
taking this same approach.

[1]: [http://www.haykranen.nl/2015/07/08/perfect-
cms/](http://www.haykranen.nl/2015/07/08/perfect-cms/)

~~~
hunvreus
We're building something that we're gonna Open Source soon. In the meantime
you could check out Cockpit: [http://getcockpit.com/](http://getcockpit.com/).

------
lkrubner
It's tough to see the healthy path forward for Drupal. 10 years ago it filled
an obvious need. But now that need is getting squeezed from both sides. On the
low end, for a company that only needs a simple-to-moderate CMS, there is
WordPress. But on the other side, where many complex modules are needed, think
about how easier it is now to pull together a bunch of modules using one of
the new services that automates microservices. Think of something like lsq.io.
Suppose you need 19 modules, so you roll out 19 simple Node apps, each
basically just some Node package, and then a service like lsq.io automates the
orchestration and deployment of those 19 modules. Is that more difficult than
Drupal? I would argue that in most cases it is easier.

So what set of needs exists for which Drupal is the perfect answer? That set
of needs is getting smaller all the time, as other options get better. "Easy
to configure CMS" is still the best bet for Drupal. That is what it was
originally known for. That was what let it win the competition with
ExpressionEngine and Joomla.

If Drupal focused on stability, they could claim to be the stablest answer for
configurable CMSs. That is probably a niche it could hang on to for another 5
years. Beyond that... its tough to see where it goes after that, but at least
that is something to hang on to.

~~~
ausjke
Wordpress still remains to be a blog, not really a CMS per se

~~~
joshmn
I'd argue that WordPress is used far more as a _web_ (not just content)
management system than a blog.

My idea of a blog is what blogger/blogspot provides. Your common WordPress
config today has 5+ pages, maybe a store, maybe directory of employees (who
don't even know what WP is), maybe manage subscription memberships, maybe
running a flash arcade (so 2006, but you get the idea)...

Yeah, WP has a core function of making a post, but it's evolved into 100x
that, and that was the goal (probably in like 2008 they set out? I don't
know). Did they accomplish it? I'd say so.

------
monk_e_boy
There are so many other things that need fixing first. They should spend some
time getting all the most used modules to use the same UX. Panels looks and
acts totally differently to Views, both of which are totally different to
Blocks.

We found a module the other day that had a Delete TAB, not a button, not a
link but a TAB. Honestly. Who does that?

Sometimes the save button is at the bottom, sometimes the top, sometimes it
saves via AJAX...

What they should do is like the module HOOK system, do the same for the user
experience/GUI front end.

And Drupal is so slow. So painfully slow. Install a few modules and e-commerce
and wow. Slow. Slow. Slow.

And as soon as you start debugging it, nearly all the code ends up being along
the lines of:

    
    
        $function($args);
    

due to the HOOKs. When you're five or six levels deep and the call stack is
just full of $function() calls... what then?

~~~
mikeytown2
Drupal 8 is a lot different from all previous versions. It still has issues
but some of the points you made have been "fixed".

~~~
monk_e_boy
Drupal 8 isn't ready until it has all the modules that a customer may need.
Most of ours are ecommerce or 'rooms' (online booking) ... I think those are
perfectly reasonable minimal functionality for a CMS that is supposed to be
better than Word Press.

So Drupal 8 core may be out, but for 99% of Drupal developers we're all
waiting for the modules to catch up.

------
lotyrin
Drupal needs to decide what it is, do that well. It needs to decide what it
wants to be, and optionally also work toward that.

I hate to see its evolution as never-quite-there toward a never-quite-decided
future.

Whatever they do, the years-long release cycle needs to die, allow whatever
improvements you'd like on head without worrying much about BC, occasionally
cut off a LTS release that never gets anything new without 100% BC. Maintain
these long enough that it's economically feasible for people to base projects
on (Whatever the benefit of the project is * years that benefit is durable >
cost of development). Focus on data migration for when people re-build sites
on newer platform instead of continuous upgrades -- nobody does these unless
they're painless, they will never be painless.

There's too much coupling between presentation, client-side behavior, server-
side behavior and data model for me to see this particular change going
anywhere good.

You can't truly decouple client and server while still letting non-developers
build web apps unless you build a UI-configurable framework for consuming an
API generically and building client-side presentation and behavior. Even then,
unless you also go so far as to infer things about my data from its API, it's
still twice as much work to describe both my server-side domain model and its
presentation instead of letting one be implied by the other.

But in typical Drupal fashion, they probably don't mean "decouple" when they
say that word, so it's really just rewriting the current hodge-podgy fully-
coupled client-side behaviors in a more structured but still coupled way using
a client-side framework -- absorbing it the way they did Symfony for the
server, not the best move but definitely with value and very achievable.

~~~
monk_e_boy
It needs to become simpler. We've had a team of four doing drupal sites for
over a year and we all still feel like n00bs. Very little idea of best
practices. Mixing themes and modules together always produces something
different, some new way of laying out pages or dealing with data.

I think some backwards compatibility breaks are needed in Drupal 9 to just
simplify things.

~~~
jefflinwood
Drupal's a little strange in that every major release (Drupal 5,6,7,8) is
incompatible with the previous major release, so all of the contributed
modules need to be rewritten or updated.

In practice, this means that if you are going to build a Drupal site, it may
take several months to a year after the official release before everything's
stable enough to build out a new site.

Drupal 8 should simplify things a lot, compared to Drupal 6/7, in that they
are actively developing Drupal for developers who _aren 't_ Drupal developers.
The question is whether that's enough to make Drupal a viable CMS/application
platform going forward.

~~~
cdnsteve
This can't be ignored. If you want to build anything of significance then you
are re-writing your entire app every couple years, or less depending on their
cycle.

Literally nothing between 7 to 8 works. You are starting over. This is not
acceptable in the markets Acquia is going after (enterprise).

~~~
jacquesm
Worse than that. By the time the module eco-system has finally caught up
Drupal has already moved on. It's un-workable.

------
adrtessier
Given Drupal's highly-modular architecture, React and a manager like Redux
makes the most sense IMO.

Building the Drupal module frontend as React Components seems like it would be
easy to add on as a toggleable layer. You push state into the global Drupal
root and mimic the module tree in the state store, and then reduce based upon
a dispatch from individual modules somewhere in the document tree.

It's a very clean fit into Drupal's legacy architecture and easy for a Drupal
developer to wrap their head around, as it's all one-way.

------
tunesmith
Is there market evidence that websites are getting penalized for serving up
html and not using client-side frameworks?

~~~
pbreit
If anything, it would be the opposite, I would think. Client-side frameworked
pages generally don't answer Google inquiries very well.

------
bikamonki
Yes, that's where things are going. The vast majority of websites out there
never really needed 18-wheeler CMSs to move a small box. The vast majority of
web dev shops cannot afford a full-time fully qualified ops/server admin
employee. Conclusion: serverless architectures are the obvious answers for
most websites and web apps. For the two or three must-be-done-in-server
processes, services like AWS Lambda will do (or APIs from vendors). Turn
Drupal into a PAAS with an API that any front-end CMS can use. I've already
tested this hypothesis with a few small/medium sized clients (size measured in
traffic and user base). It works. I had to put together a simple CMS
(backbone+bootsrap) but it would be nice to see a popular CMS with themes +
plugins going into this direction.

------
pbreit
This seems like a gross mis-understanding of your product. Content sites are
still almost entirely regular web pages, not any of the fancy new "single page
app" stuff.

------
jefflinwood
Realistically, the selling point of Drupal is the strong integration between
the front end and the back end - if Headless Drupal becomes the norm, there
won't be a lot of good reasons to deploy Drupal on the back-end instead of
say, Rails API.

If the Drupal project gets solidly behind Angular, React, Ember, or something
else, and Drupal 9 modules support client-side as well as server-side
rendering, this could be a very interesting development.

------
rickcarlino
How will this impact SEO? Have any other CMSes managed to take the SPA route
successfully?

~~~
_neil
There's a fair amount of movement behind doing this sort of thing with
Wordpress/WP-API. There's even a conference[0]. The conference site itself is
a pretty cool example of a site using WP-API (see the "View API Request" at
the bottom).

I've used this pattern on a couple projects now and it's an enjoyable Devon
experience. And the client gets the benefit of a nice admin interface.

[0] [https://feelingrestful.com](https://feelingrestful.com)

~~~
_neil
*dev experience. That's a weird autocorrection choice.

------
okonomiyaki3000
yes

------
programminggeek
This is a terrible idea, and will destroy Drupal, but other than that, sure
why not?

