CMS's are designed to be behind a caching layer like Varnish. a CMS takes in user input and renders to html, which should only change in-page on ajax requests. I really wish there were more public configs for Varnish, some things like Mediawiki are impossible to find well-written and documented configs for, and creating one yourself can have a lot of pitfalls. There's four versions of Varnish, so that too makes it a PITA.
The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts".
> [...] to be behind a caching layer like Varnish.
Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind.
You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have.
>The popular CMSes that are mentioned here (WP, Drupal), are not designed. They where mostly hacked together and became immensely popular before any thorough software design took place. They come from a time where software design was not much applied to "web scripts".
Hacked together is still a design. It may not be a Good design, but regardless they are made to be behind a caching layer. Also, Drupal 8 is pretty well designed and thought out.
>Varnish 1.0 is from 2006. WordPress is from 2003 and Drupal from 2000. These popular CMSes where certainly not made with proxy-caching in mind.
Software changes over time, and regardless of timelines the nature of CMS's is to generate output that stays the same, which is good for caching layers.
>You can properly architect and write "your own" CMS in a compiled language (like Go, Rust, C++, OCaml or Haskell) and have <10ms response times (including the db queries). It will just lack the features, plugins/modules, and market pull that WP/Drupal have.
This highly, highly depends upon what you're building. Plugins and modules are not the reason for slowdown in CMS's, the reason is that the data is abstracted into understanable constructs that can take in all forms of data. This requires lots of queries and code to standardize things. In many cases, you're not going to build something better that is as functional or friendly to future developers.
That's degrading the definition of design. WP was not even hacked-together/designed to be a full-fledged CMS in the first place!
> Drupal 8 is pretty well designed and thought out.
It is certainly more designed then the early versions of popular CMSes. But one thing for sure, Drupal 8 is still not designed to be fast.
> the reason is that the data is abstracted into understanable constructs that can take in all forms of data.
Not all languages suffer from slowness by abstractions. Rust, OCaml and Haskell come to mind. These languages are "designed". Again I'd argue that PHP is not designed but hacked together without much thought for design -- find some Rasmus quotes and you know what I mean.
Its not. Bad designs are still designs, design is not a word about quality, it is a word about intentions and implimentation of them.
>WP was not even hacked-together/designed to be a full-fledged CMS in the first place!
Original intentions have no bearing on how the software is now. WP definitely does have issues, but it is designed to be a full fledged CMS now.
>Not all languages suffer from slowness by abstractions.
In this case, they do, because you have to get your data from a database, we're not even talking about programming languages, but constructs of data and how they're sorted. Drupal 8 has a very interesting methodology to categorize data that is well done enough the Views module can take that and is capable of building most data-centric sites. You can build a pure catalog like digi-key with normal drupal 8, no plugins or modifications, just setting the control panel and a theme.
>But one thing for sure, Drupal 8 is still not designed to be fast.
It is, actually. But it being 'fast' is behind its ability to work with data and make it actually configurable to define your own editing workflow and how that gets represented on your editors dashboard, connected directly to how its viewed on your website. Your CMS does not need to be 2fast, since it should be behind caching layers.
>Not all languages suffer from slowness by abstractions. Rust, OCaml and Haskell
All languages suffer from the abstraction higher level languages like PHP, Python or JS provide, namely that they're not typed or compiled and can work with very dynamic data.
