jchatard
Hi all,
I’m currently evaluating solutions for several projects I maintain (clients websites) and I need to modernize those.
Those projects have a technical debt:
- Built 5 to 8 years ago,
- LAMP stack using Drupal 8 (now migrated to 9),
- Front end using Twig templating engine augmented with VueJS.
The not a problem: backend
My clients are happy having Drupal as a contribution platform, and so are we in my agency. It provides great value for community maintained features (content management, roles & permissions, workflow, etc.). We’ve been using Drupal since version 4, which is prehistory in the CMS world, so we know it pretty well (features, modules, APIs, hosting, security advisories processes, etc). Those websites are mainly static once the content is contributed, everything is cached in Varnish and response time is good. There are few forms (15 to 20 depending on the project), but no user account as of now. So it’s basically cached/static website browsing (Drupal handles cache invalidation pretty well). With a few exceptions here and there of course, that’s about it.
The problem: frontend performances
Today, the problem we’re facing is frontend performances. Nothing to eccentric here, some big images, long scrolling pages, with complex CSS gradients, animations, etc. But the pain point is the JavaScript, which is heavy, because it is bundled as single file, includes dozens of Vue components, still has lots of polyfills and workarounds for older browsers. Parsing time is a issue. So yes, it’s become a giant spaghetti soup and Lighthouse performances are bad, especially on mobile devices: 20 ~ 30 out of 100 :-/. Lighthouse is not God, but still, we have to face reality, mobile navigation is bad unless you have a last generation device. SEO is impacted and is becoming an issue, because Google takes into account Lighthouse scores for its ranking.
Strategy: decoupled CMS with Drupal
We are thinking of decoupling the frontend from Drupal. Keeping the CMS as a contribution platform, exposing the content through either JSON:API, REST, GraphQL… well you know anything like that.
And use COOL_TECH_HERE for the frontend.
I’ve done my research, and come up with a short list:
- Gatsby not sure I like the full static philosophy.
- NEXT.js the goto framework nowadays? Good mix between static and dynamic.
- Phoenix and LiveView ?
Gatsby and NEXT.js share the same philosophy at frontend performance. Reducing bundle sizes by splitting JavaScript files, and loading them as needed. Make the website feel extremely fast using <Link> React component for prefetching data. They also have <Image> component which could be very handy. Next.js is also integrating React Server Component which looks promising.
I’ve been lurking on Elixir for 6 months now, and thoughts maybe Phoenix and LiveView could be a good fit.
I could be wrong, but my understanding is that LiveView could allow us to reduce even more JavaScript size, because some rendering could be computed on the server and applied on demand without having a JS component needing fetching and loading with HTTP roundtrips. I know it doesn’t make sense to do everything on the server, and I would still have some JS on the client side for UI only widgets and the likes.
My goal is to achieve more than 90/100 in Lighthouse performance score with a visually complex website. It’s pretty clear to me how I would achieve this with — let say: Next.js. But do you think it would make sense to go the LiveView way?
For example, I like the idea of link prefetching (shared by Next.js and Gatsby). It’s not clear to me if Phoenix’s live_session is related? Or is there anything similar in the Phoenix world?
Elixir and Phoenix are appealing to me, because, as it’s running as an application, I could have processes fetching data from the CMS, checking regularly for updates, build chunks of caches in the background. All the cool things we can implement with OTP.
I’d love to hear from you guys on that topic. And if you have examples of websites performing insanely high performances scores on Lighthouse it would help me make a choice, ahah!
Thank so much,
Jérémy
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #ai
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #blog-post
- #elixirconf-us
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #security
- #metaprogramming











Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
cmo
This book might be of interest to you. You might want to start trying to improve what you have in the weak spots you’ve identified? What would be the advantage in ditching Vue?
Kill It with Fire | No Starch Press
kokolegorille
This is not the only solution, You can split into multiple bundles, and optimize your javascript code.
I don’t think You will gain speed by replacing JS by Liveview, but You might gain dev speed.
al2o3cr
My recommendation is to try it out - build a minimal Phoenix app that pulls content from Drupal and displays it with Liveview, then get it deployed to a realistic production configuration. You’re definitely going to be facing a rough learning curve deploying BEAM vs deploying LAMP.
derek-zhou
I’d say if it ain’t broken, don’'t fix it.
Porting old code is a thankless job. It is far better to build a new thing and let the old things gradually fade into irrelevancy.
jchatard
Oh, I didn’t think this was such a matter. Is it that complex?
jchatard
Yeah I share your point, but from our (and clients) point of view, the front end IS broken, performance wise. So anyhow, I need to rebuild it, from the ground up!
al2o3cr
It’s nothing impossible, but it’s significantly more complicated than LAMP’s “FTP a PHP file into the web server’s directory and It Just Works” minimal approach.
Check out things around
mix releasefor more details.josefrichter
Can you post some links to those sites you’re talking about? You say they’re mostly static, but a lot of JS/Vue. What kind of content are we talking about and what is Vue used for?
jchatard
I would need to ask my clients of they agree publishing here their website.
Vuejs is used intensely by Vuetify, Lightboxes, Forms, Carousels, Expansion panels, revealing and hiding content, small effects here and there, scroll detection, overlays… Context switching on the page, which could redraw some components.
jchatard
Ahah, you know, PHP is not really about firing an FTP client anymore. It’s about git pull, installing dependencies, dumping the autoload, synchronizing the code on 3 different webservers. Clearing the cages, warming up those caches, etc.