Hm, not sure I’d agree. Software starts small sure, but as you say out of necessity, but that doesn’t make it minimalism–precisely because it’s a necessary step–until one makes the choice not to add to it. But I sense a danger of falling into an agile process discussion on this point so I’ll leave it there 
Hello, I am opposed to python and my choice of elixir is for education and exploring ideas. My focus is on the logic of scaling. Please refrain from calling my decisions crazy, and bringing us off the theme of elixir by dropping a mess of python code into a discussion of a new crucial package.
My blog does more than static generation, and I display git codebases there also. While phoenix is a burden, I’m happy that I made some progress in elixir and plan to push further in this direction using Nex. If you begin to read my essays and code, you may see how I am lining up experiments for programs and machine deployments.
Ah, sorry for that. I didn’t mean that in a disparaging way. Maybe “overkill” or something would be a more appropriate word to articulate my meaning than “crazy”? In any case, I apologize for offending you. If the goal is to learn/experiment, then by all means use whatever technologies interest you. I’m all for that!
The Python code was just an example of how to build a static website manually because I had it lying around (it’s the real code that builds my blog and the static FE/doc site for a public API I run). The same thing could be done with .exs scripts in Elixir, and Elixir would probably be a better fit for that particular script actually since it is component-based. Basically, it just looks for <!– modulr-component: component-name –> comments in html pages and replaces them with the HTML in a src/components/component-name.html file. Works well for reuse between articles/pages without any runtime cost in the built site. Elixir is great for that kind of processing due to it’s pipeline syntax and concurrency primitives. I wrote a CLI tool to do language-agnostic find-replace (like sed but without making my brain hurt) across an entire project in Elixir and it’s lovely. I use it for e2e renames at work all the time.
I will say that I can understand if you find Python off-putting. A lot of people do, but it’s a very useful language to know since it’s the most convenient glue/automation language out there. I think all devs should know a bit of Python and JS (even though I hate JS) since they are so ubiquitous.
I also wouldn’t say that Phoenix is a burden. It just comes with a lot of extra stuff that most blogs wouldn’t need, which is why I mentioned static site generation.
Cheers!
2 Likes
Great to see an alternative to Phoenix based on convention-over-configuration. I rather like that paradigm for the same reasons Elixir has a rigid build-in formatter.
A ‘support it all’ framework is nice to have but will always need to expand when the use base growth (so the relative amount of features use decreases). Having a fixed set based on a philosophy and resisting the urge to please everyone, keeping the mental modal small, will be a selling point imho.
For that you might turn to Routex - build powerful Phoenix routes: localize, customize, and innovate
One thing that I am watching with curiosity in all such similar threads is the seemingly inevitable intent of the community to deconstruct a bigger framework like Phoenix to its constituent parts and make sure they all can work together and it then becomes an exercise of “assemble your own framework”. F.ex. you might have multiple ways to do routing and static file serving.
And this concept is already kind of in place with mix phx.gen.auth where you generate it and then customize it to your liking.
While that does somewhat sound intuitively nice to have, I am not sure how maintainable it will be in reality.
I’ve spoken against one particular aspect of Phoenix in the past: too many files. Outside of that though, it does seem to do what it needs to do fairly well. Very curious about alternative frameworks like Nex and how they fit!
1 Like
This is a big problem with the JS ecosystem. JS devs are spoiled for choice with npm libs, but they end up needing to write so much glue code to make incompatible libraries work together that they might as well just build it themselves.
One of the things I love about Elixir is that it doesn’t suffer from this nearly as much. Most of the time, I don’t feel like I need to reach for a library at all since the standard lib is very rich, but when I do, the library usually fits together with regular standard lib code very well because of common patterns like OTP/supervision and pipeline-based apis.
2 Likes
Oh, absolutely. My ideal such architecture would be N choices that implement the same set of API (guess we could call them protocols in Elixir parlance) and people would choose based on various merit.
But I know: what color do I like my dragon?
1 Like
It is a curse to fell into the dependency hell. Someone I respect deeply even went all the way to claim package managers are evil.
There was a quote attributed to our own José:
In real life, when you have a dependency, you are responsible for it
In software, many people have the opposite idea that one can offload responsibility by adding a dependency.
1 Like
Yeah, I like to think of using an open source library the same as hiring an independent contractor. I’m relying on them for some crucial part of my business/application, so I should treat it that way (and pay them if it’s feasible).
In practice, it’s difficult to actually use the classic c-style vendor-deps approach, but it’s not impossible. The godot engine does it in their codebase due to license incompatibilities and problems with dynamic linking when cross-compiling for different release platforms. It’s a lot of work to maintain vendored deps, but it works, and I’ve never had godot fail to compile from source due to some missing binary on my laptop.
What’s the idea behind these articles, exactly?
Most good devs on this planet understand the problems. But nobody is willing to fund a true change of the status quo.
I suppose it was therapeutic for the author to write it because there would be zero other positive effects on the world coming from the fact that one more such article got written.
GingerBill is the creator of Odin, which is a manifest of all of his philosophy, including not providing a package manager and actively encouraging user to vendor 3rd party libraries. So he walks his walks.
