And then another developers has to work at the code base and:
learn your new (likely less) documented custom conventions
can’t find answers at ElixirForum and Stackoverflow
can’t ask “Phoenix questions” but has to resort to “we’re using a combination of Plug and X”
Have seen companies go ‘bare bone’ and instead they just rebuild a less documented, less dev friendly, less secure, less optimized ‘fat bone’ over time.
There might be very rare cases where it is beneficial but in general it’s just not worth it.
It’s more a Want To upgrade, not a Have To upgrade. Isn’t it? Compared with the JS ecosystem, keeping up to date with Elixir libs is a breeze
several different files in the right places
This one is annoying me a bit more indeed. I really like the decoupling of name spaces and file location (let the editor handle jumping around) and Phoenix is quite relaxed about it. But once in a while it DOES matter and then you trip over it.
Don’t forget about some nasty macros (I think all of us are guilty of creating them). But in general I totally agree, when I saw for first time proxies ( that of course became full fledged servers after a short period) in golang with some custom decoders, converters and middleware that never were abstracted in a separate layer, I just decided this is not worth investing my time, just nasty practices that cost tens of thousands of dollars.
Oh absolutely. It’s my personal and professional weakness that I get OCD when I know there’s a new version of something. I intuitively fear I am missing out which I’ll admit had led to not making strictly informed decisions before inflicting pain on my personal – and some professional – projects. What can I say. Still haven’t cured that defect of mine.
Also no need to compare with JS, we all know the horror show of programming.
Yeah that’s exactly it. You never truly exercise these things on the level to put them in long-term memory and they surprise you EVERY DAMN TIME. I hate it.
But I’ll say again – Phoenix is one of the best of the best web frameworks in the world. I am kind of piggybacking on this thread to just share quickly that I don’t have much interest in working with it. I know it well and whatever I managed to forget I remind myself of it in literal minutes but… I never enjoy working with Phoenix nowadays.
If we are talking about education, personal projects or the likes it really doesn’t matter.
For anything else where more than a person needs to collaborate i agree with the previous replies.
I’ve seen my fair share of Express Frankensteins and Flask project’s than ended up being a worst Django by a large mile but without any proper docs.
Now, about lightweight, Phoenix works fine in one file for simple use cases.
I agree and I’ve seen ungodly Golang messes as well but there’s an upside to it: they are very rarely modified and are self-contained which is a boon for maintainability – if you are the original dev.
But yeah, if the original dev leaves then ouch, it’s bad for everyone else after.
The reality is that it doesn’t matter who left the turd, you come and usually as it happens the original dev is long gone and you have to make that mess work, without any documentation or guidance, you are lucky if that person used some logic behind his code structure, which is rarely the case for low paying dev positions as there are in my country.
One thing that set Phoenix apart from other frameworks is that it does not force you to adopt everything it offers. In one solo project I have, I use neither Phoenix.Template nor Phoenix.HTML, or any javascript from Phoenix for that matter. However, I still use Phoenix. The functionalities that I do not use don’t bother me; they are hardly noticeable.
Wow, this thread has gotten more traction than I initially hoped fo. Some good thoughts in here. Trying to reply to some of them.
Yes, this could happen. I’d argue that this only tends to happen if devs involved do not understand or agree with the good and bad parts of the frameworks used in the past and try to mimick them (also true for Rails/Phoenix forks). Not everything is good in every framework. It’s of course a subjective matter. Unfortunately it requires time and experience of multiple programming languages, their ecosystems and frameworks to have an objective opinion about good and bad parts and this is not something all devs (yet) have, thus it’s easy to get lost and build every other Rails feature back on, when in reality it’s not really needed.
When I started with Ruby and Rails 4 in my coding career, I came from a bloated Java EE world, I found Ruby and Rails to be like a fresh breath of air. Everything looked so clean and elegant. This was until some problem came along and I needed to troubleshoot it by going through all of the complex layers behind the curtains of Ruby and Rails magic. This made me understand that I liked magic at first because as long as you follow the road correctly then everything works as expected, but if you have a small misstep, then good luck understanding what’s wrong. You just can’t see this in the code because there’s so much magic going on and not that many lines of code. Rails became to me as one of these fancy frameworks which sells itself with the statement that developers can concentrate on solving customer’s business problem, but this is only true at the beginning of a project. At one point you need to start dealing with all of the extra-weight brought in with the choice of the framework devs took a long time ago. And then you need to upgrade it because you want to have latest and greatest features and run it on newest programming language runtime/compiler. A separate “upgrade framework” tickets will be created into project planning software and no-one has any ideas how long it will exactly take due to many unknowns and vigorous testing (not just unit-testing, since there might be production-only problems coming up).
I would disagree that LiveView is a boring technology. It looks like that at first, but i’d consider it still cool/fancy new technology compared to the old and boring ones. Instead of having a HTTP+HTML (and maybe a few JavaScript files) you end up with HTTP+WebSockets+proprietary protocol built on top of it+specifically written code for LiveView at server-side and frontend+JavaScript running in the frontend to patch DOM. There’s many layers which could go wrong and might be hard to debug when this happens as opposed to plain old HTTP+HTML where you can see request and response and understand what was or was not sent back to the browser.
I guess I might have not communicated clearly enough. My idea was never to build something from scratch, but instead of having a heavy-weight framework like Phoenix as a project dependency, I would use smaller and only necessary dependencies as a building blocks. This doesn’t mean that I need to write everything from scratch, but gives me freedom to change/update/test these parts separately if keeping code neatly designed. Also, less bugs and security problems not more due to having less complexity and ways to go wrong.
Agree, there’s nothing better (you who love SPA frameworks and their endless complexity, go back to drawing boards ). However, as you also stated then there’s some annoyances and problems of keeping it up to date. Someone wrote here that there’s no need to upgrade, but this is also not true since by not upgrading Phoenix you can’t upgrade Elixir at one point to get faster runtime/compilation etc. To upgrade Elixir, you might need to upgrade project depenendencies and by having smaller/less dependencies, it’s definitely easier/less error-prone and takes less time plus it’s much safer to deploy to production since rolling back is going to be much easier too.
This again tends to happen when less experienced developers try to do it without following good coding practices and want to create clever code full of magic. I, however prefer explicit code over implicit code at any time and would not include any magic whenever possible. Code is meant for reading most of the time not writing so having all of these extra characters there will help at one point. It’s one of the reasons I even started to look at Elixir and Phoenix at one point since it felt that there’s not that much of magic going on. I love Elixir compared to Ruby because it is quite explicit as long as macros are not used. In Ruby you never know what the value of self is in runtime. It’s even much worse compared to JavaScript this. Comparing Phoenix with Rails is a good example where Phoenix took mostly good parts from Rails by ignoring bad parts and one of the things is having less magic involved. There’s still some, but still a lot less in my opinion.
Again, happens when less experienced devs try to be smart without having a full understanding where the boundaries should be kept etc. I’ve done few projects in Java/Kotlin where similar approach was used - instead of going for de facto full-of-magic Spring Boot, which is used in Java world our team decided to spend more time at the beginning of project by creating a good foundation by using more simple Spark and/or ktor respectively (don’t recommend it, since it has some nasty bugs). Code was really explicit, easy to understand, maintain, test and easy to write due to help of the type system. Also, boundaries were in a way that it would have been quite easy to replace whatever framework was used since most of the code was plain-old Java/Kotlin without any external dependencies and dependencies were kept in a separate layers by wrapping them away. No documentation really needed since you can open up a router and follow from there downwards. No magic annotations or file locations required just a few familiar concepts if dev has any previous experience with MVC frameworks. I’ve also created something similar with Ruby + Sinatra, but it was more like a hobby project. With Phoenix I have few instances running in production where asset pipeline has been stripped and no LiveViews are used. Works awesomely.
It’s lightweight, but definitely not something I had in mind. I meant by lightweight of having fewer dependencies and less framework-specific code in my business logic layers. Lightweight still means that code should be loosely coupled and have a good design principles. Throwing everything into one file writing as few characters as possible is definitely not it
For these cases it doesn’t really matter if a Phoenix-like framework was used or not. That kind of devs think that using a popular framework solves all their code-base problems and if they still happen to end up with a really smelly code-base then they blame the framework and go with the next best thing using the same undisciplined coding practices. Ironically it’s good in a way that this kind of devs are unable to write much on their own, which means that conventions created by a framework might help a little when it comes to understanding as long as some of them has been followed.
Yes, agree. I also didn’t use LiveView (as explained above), nor it’s asset pipeline, form/tag builders, code generators and few other things.
Just to conclude: for this particular case I have a feeling that there’s an easier way compared to Phoenix (why have any functionality in your code-base when it’s not used?), but it requires some discipline and experience, thus this road is definitely not for everyone. For this particular case I’m trying to experiment for my own solo project. I would not use this in production for a customer yet. However, after this experiment I will definitely have a better understanding of the lower level libraries/components already used by Phoenix, which in turn help me troubleshoot problems with Phoenix in a more efficient way. And maybe in my next customer project I will choose this path if experiment is successful
Thank you for all the thoughts and replies so far!
The one file example is extreme of course, but you don’t need to put eveything into 1 file, but can organize the project as you want even using Phoenix, just skip the generators (phx.new), that’s what I meant.
The dependencies that Phoenix gives you will be the ones you’ll end up writing anyway, but use the ones you need and skip the rest. But if you still really want the simplest thing, just use plug_cowboy.
I think the reason we haven’t seen projects in the Sinatra like space it’s because those type of frameworks (I used to use KoaJS and Flask) aren’t as used as they used to be, so there isn’t as many people comming from other languages trying to mimick the same in Elixir. Also Phoenix is probably the biggest drawing point for Elixir, I mean, I guess it’s because of Phoenix that a lot of folks try Elixir in the first place, so it makes sense they stay, specially because Phoenix gives you thing’s that other frameworks generally don’t, easy realtime (Channels), LiveView (different paradigm), which are not trivial to replicate on your own, so it makes sense to stay.
). However, as you also stated then there’s some annoyances and problems of keeping it up to date. Someone wrote here that there’s no need to upgrade, but this is also not true since by not upgrading Phoenix you can’t upgrade Elixir at one point to get faster runtime/compilation etc. To upgrade Elixir, you might need to upgrade project depenendencies and by having smaller/less dependencies, it’s definitely easier/less error-prone and takes less time plus it’s much safer to deploy to production since rolling back is going to be much easier too.