[adevx]

I know this is not for everyone, but sometimes it makes sense to jump off the CMS bandwagon and build a custom site. First I used Drupal but got tired of rewriting the site on every major release and jumped on WordPress. Then on WordPress I realized I could not create the user experience I was after without committing massive amounts of time and resources in custom plugins/themes. Leaving me too dependent on a moving target that might take a direction I don't agree with. It looks like there is a plugin for everything, but having them all play nice together is difficult. The more plugins the bigger the security risk, and the greater the risk of an update breaking your site.

I rewrote the site in Node.js/Express with Vue.js and server side rendering. The ecosystem is ready with so many libraries to quickly get up and running. Another major benefit is being able to design your own database instead of having everything stored as a post (WordPress).

[newsbinator]

I've been using this exact structure too, via Nuxt: Node/Express + Vue on the front end (with templates written in pug via pug-loader).

The benefit is that I can use scoped CSS on any given article I write to better match its content. And writing in pug is, to me, equivalent to writing in Markdown.

I import in packages if/when I need them, instead of relying on a plugin ecosystem.

But this is not a CMS: it's me writing pug, compiling, and generating static pages.

If this were client-facing, I'd need to drop in a CMS/db. But since it's only me, this system has been ideal.

[two2two]

I would love to do something like this. Drupal was a nightmare for me as a designer. Wordpress is much more manageable, but HTML/CSS/Javascript are king for me to have full control. What I'd like to learn next is implementing a database to cover the CMS side of things. Any resources you care to share that would put me on that path?

[malydok]

I believe that the static site generators of this day are the next step in custom web development. I'm currently working on a Gatsby.js project using Contentful as the content provider and it really feels like the stack of the future - build with all the shiny tools but send a fast, static website to the end user.

[cityzen]

If you're interested in full stack serverless solutions, AWS Amplify looks really good. It handles a lot of the provisioning of resources and creation of GQL resolvers, etc. I spent an afternoon with it a few weeks ago and it completely changed my outlook on the future of the web and CMSs.

https://aws-amplify.github.io

[adevx]

For what it's worth, I went with PostgreSQL, decided not to use an ORM but a query builder (knex.js). Knex.js gives you database migrations and is good for basic querying. It is easy to drop down to raw SQL if you need something more complex or optimized.

[andybak]

Apples and oranges. If you needed a comprehensive client accessible CMS then how did you replicate that side of things in Node etc?

If you didn't need a CMS then I'm not sure why you were using Drupal/Wordpress in the first place. The only reason I can think to use them is if you want to hand off content editing to a non-developer.

[adevx]

I agree that I did not replicate the theme and plugin system of WordPress. But the beauty is that you probably don't have to. WordPress has to cater to all, which is probably the source of all the issues people face.

But neither is my website a simple brochure site. Members create their own content, upload photos, enter their location on a map, enter available dates, have the ability to chat with other members. When I tried to do al this with custom and available plugins, it never felt as a coherent experience. Then there is a lot of automation in the background, notifying members of unanswered messages, expiring profiles, notifying members of expiring memberships. Getting all this properly done with the CMS provided API's is more work then writing it from scratch yourself. With the benefit of not having to worry about CMS API deprecation.

[andybak]

You're making a completely different distinction to the one I was making.

I was saying "client-editable content" vs "not" and you seem to be saying "brochure site" vs "dynamic site".

Brochure sites sometimes need to be client editable. And sometimes complex, dynamic sites don't. It's an orthogonal point.