In case you didn't know. Children are menaces and lack of sleep can really do a number on you :)

Also, trying a new look. Unfortunately it will be bright for everyone instead of rolling with light or dark. I'm thinking about it and looking into my options. Let me know how you like it.

Productive Opinions in Phoenix

Phoenix is getting more opinionated with age. Specifically I believe the developers are finding their stride and creating a sweet-spot. Many details of the framework look quite different now than they did when I started and I think that is with good reason. There are also some additions and changes incoming that I think will be quite good for those that like the direction.

When I started using Phoenix it was about Controllers, Channels and the asset pipeline was a finicky beast called Brunch. Phoenix was ideal for simpler static pages or as the backing API to whatever Javascript frontend you brought. It was actually fantastic as the backing API. With serious performance overall and the with Channels specifically being very nice for realtime experiences Phoenix had some serious selling points around efficiency, capability and performance.

The first shift there was probably the move away from Brunch in 1.4. Webpack had eaten the frontend world. Phoenix role was  primarily as an API-building tool for many people. I think the idea of aligning with standard practice, Webpack, was reasonable. Phoenix implemented Webpack as the default asset management. Despite being primarily used for APIs the framework did need an asset management story. I will say that beyond the ubiquity I'm not certain that Webpack was a big win over Brunch. Overall I think Node, NPM and assets remained one of the most bothersome parts of working with Phoenix.

The only way to build entirely with Phoenix was if you were willing to stick to controllers. You could bring in some of the Turbolinks style of solutions to get a snappier UI experience. Most projects would end up bringing some level of JS libraries and frameworks to build a production web UI. Channels worked really well to make real-time style UIs. This was also the time and place that Elm won some popularity with Phoenix and also the other way around.

Then LiveView arrived and the possibility space shifted significantly. Now building entirely in Phoenix became much more feasible. Among enthusiasts and aspiring technical founders you had the option of not bringing the Javascript stack into the picture. You could simplify. Stick to Elixir and have your app be this pragmatic and cohesive unit. It became a major selling point. Simplification, simplicity and cohesion.

Phoenix brought it's own preferred frontend framework and it wasn't really a priority to serve other frontend primarily anymore. It still absolutely can. Phoenix is still a fantastic web API for other client frontends. It hasn't lost anything. Now there is a different possibility.

LiveView has necessary parts that are implemented in Javascript. It is unavoidable to do what it does. At least until it makes sense for it to be WASM instead, possibly. It could be done with Vanilla.js (that is, no extra libraries, no build tooling, nothing). The Phoenix hex dependencies bring some JS files though and there are many tools you might want to bring in as you build out your app. As Phoenix wasn't thrilled with the Webpack situation it was still such a common requirement to have a bundler that could take your JS, your CSS and do things to it.

With Phoenix 1.6 the story changed to using Esbuild by default. A small Go program that knows how to wrangle Javascript and CSS into minified bundles. It is fast, it is constrained and it does not introduce a massive unwiedly config file. You can now use Phoenix entirely without Node and NPM as long as you don't require NPM packages. You still get LiveView so you still have this full stack of tools for building highly interactive web applications. Esbuild was introduced using a Hex package that wraps up the install process and the glue to integrate the build tool in your Phoenix dev server and such. Very convenient.

And a Hex package for the standalone Tailwind CLI was introduced recently. This was a delight to me because the setup for Tailwind CSS and Webpack was nightmarish at times. I find Tailwind very useful for building out and iterating UI. Not everyone enjoys Tailwind. That's fine. I'm not religious about it. I was thrilled to see a simpler way.

With the upcoming Phoenix 1.7 offering Tailwind generators we are seeing both of these tools become mainline in Phoenix. These are two opinionated tools. Not extremely controversial and not massive commitments. When Tailwind goes out of style it should be easy enough to transition the framework to a new default. When something replaces Esbuild that should also be fairly simple to adapt to. The new default is getting some opinions though and to me those opinions speak to the idea that Elixir and Phoenix can be your entire application. You don't need anything else to get going and probably not even to get to your final destination.

LiveView obviates a lot of low-value contract layers and frontend dev work. Tailwind obviates a lot of frontend visual design work. Especially if you pay for Tailwind UI, good business they've got there. And Chris MCCord recently wrote about working on a Heroicons package for Elixir. I'm not sure if that's targeted for mainline Phoenix but it will be another opinionated convenience living close to the core of Phoenix.

What I like about this is that I think they are making fairly safe bets that are still useful. The time-to-interactive cool shit is lower with each step. And the bets they are making aren't excluding the possibility of using other options or making a headless API service. You can strip out LiveView, Esbuild and Tailwind and have none of it.

I'm really optimistic about the direction of Phoenix. It should continue to make building web things a lot easier without sacrificing much of anything.

Do you feel differently or strongly agree? Did you know? If you have thoughts to share I love a reply to these email. You can also send to lars@underjord.io or find me on Twitter as @lawik.