I’m no so sure that’s a fair comparison. Req is a wrapper on Finch offering opinions and ergonomics. It does not re-create an HTTP client. I don’t think that’s a fair comparison to rebuilding a web server from scratch because Phoenix is “too complex”.
3 Likes
And his implementation leverages plug with the expressed intent of making it more ergonomic. I think it’s an apt comparison, but it doesn’t even have to be for the point to hold true.
3 Likes
Thanks for the proposal with a great example!
I am careful about necessitating macros from the library, because it adds something the user needs to learn and do, which goes against the whole point of the initiative. I was thinking something like @path, because it looks like @spec or @doc.
But if I can incorporate it as an option, Mar Might be able to align gradual learning curve as it expands functionalities!
Thanks for the encouragement! I appreciate it.
That’s also what I’m trying to learn doing this kind of projects. How people react to ideas, bracing myself for it.
Whaaat I was introduced to Req for the first time, It’s just the thing I imagined using Finch! This is way cooler and complete than Mar, but thanks for the analogy. I hope I’ll be able to contribute at this level.
I’ve only read and heard praise or constructive feedback about Req. Where do you see the dissent?
Hi @gregvaughn !
Apparently I haven’t made it yet, but I wanted Mar to be a wrapper on Plug offering opinions and ergonomics.
My experience was more like “Phoenix has a steep learning curve for absolute beginners”. The difficulty was not in the complexity of how the library works, but in the lengthy examples, generated files, and scattered informations that obfuscate the simple nature of Elixir.
The real problem is not that it has such a wall, but that the wall prevents newcomers casually marching into making web stuff with Elixir. At this point, I think they should be guided to a Plug project first. There’s a reason CS50 teaches Flask instead of Django. The less prepared junior devs, the less companies adopting Elixir.
When did it become about Phoenix itself? It surprises me when people take it as a derogation against Phoenix. Phoenix is great. It’s a complete project for production. I understand that the experienced developers might not resonate with this. They understand the entirety of Elixir, absolutely crush working with it. But there are infinitely more things Phoenix might have been missing, which is not its fault or anything.
5 Likes
This is just one such example
https://x.com/yannickfricke/status/1684119526005436417?s=46
I’m not saying it was the majority, but it definitely was there.
1 Like
Nevermind me. I shouldn’t have spoken up, but I was in a curmudgeonly mood yesterday. Our experiences and opinions are vastly different. I should not dissuade you. Maybe you will finally be the one who succeeds in making things easier enough for newcomers so this topic doesn’t need to be revisited yet again. Please carry on.
4 Likes
On the contrary, do speak up, but we should also recognize all sides.
So let me attempt to demonstrate that I get your POV: for people who work with Phoenix on the front lines every day complaints like mine and @taro’s are likely puzzling and seem unimportant and niche-serving. Also there was this other thing said: going super-minimal doesn’t scale which I agree with but there are many projects that never become big so having a super-minimal framework might still be beneficial for the community at large.
As for you understanding my POV: as a polyglot programmer who periodically forgets specifics of frameworks I really wish more frameworks went the extra mile to (1) minimize amount of files so you can see what’s going on in a single screen and (2) went for the extremely minimal DSL in each and every case (though this part I think Phoenix covers well f.ex. I can’t find a way to devise a shorter Router syntax, I like it quite a lot even).
1 Like
@dimitarvp I appreciate you trying to include me, but you’re right – I see this as a niche that does not apply to me.
I’ll share a brief related story. About 12 years ago I was working for a company based on Rails that had a group of Rails community leaders (also, this was about the time I was mildly annoyed that a Rails contributor named José Valim that I followed on Twitter was talking more about his new personal language than Rails 
). I was told by our architectural team that our new (micro-ish) service should be written in Rack instead of Rails (like Plug instead of Phoenix). 6-8 months later we had added about 75% of Rails as dependencies as the features grew. It was a Frankenstein app – most of the parts of Rails put together in an unconventional way. It was a hassle to maintain because we could not just throw someone familiar with Rails at it. Using this “simplified” base ended up creating a maintenance nightmare.
I could spend many more thousands of words talking about the lessons I learned, but I have neither the time nor desire to do so. I wouldn’t change anything. Most of us need to make our own mistakes to learn a lesson. It’s the rare person who can actually learn from the mistakes/experiences of other people.
3 Likes
Oh, I and others agree wholeheartedly. It’s just that there are apps that will never scale (much) so using something more micro might be worth it. For all other cases you are right and I agree.
Also true. With time this stopped saddening me and I started seeing it as a positive: while you are screwing around with making a micro-framework you can also learn many other lessons that can and will be applied to your commercial work after.
1 Like
No, it’s still not full agreement. While I agree there are apps that never need scale, we, as a software engineering community, are horrible at predicting this. I don’t trust any of us, not even myself. For something that we don’t think will need to scale, let’s add a new controller to an existing Phoenix app. However, if the company has no existing Elixir in production, my opinion is that it’s a bad idea to introduce a small endpoint that’ll never scale to their portfolio of technologies. As much as I love Elixir and want to see it grow, it does not leave a good impression as “that one app the passionate engineer talked us into trying, then left us with no one else to maintain it”.
2 Likes
Hm, I am not sure why you brought different programming languages / frameworks into this but I don’t disagree with what you said there either. 
Sure. Same here. But I will gradually, over time, be chasing after using technology that spares my brain. Currently the amount of files I have to follow in order to be truly productive in Phoenix is unacceptable for me. Nobody has to agree but I’ve experimented all over the spectrum and “less files” is my best productivity enabler so far.
And as mentioned a few times, I don’t work with Phoenix’s specifics every day, I am a backender / data guy / CLI tools encyclopaedia and an alright Linux sysadmin – and I’ve never been impressed by almost any web framework; they leak too much of HTTP’s idiosyncrasies into what should be strictly business domain code, and Phoenix is no exception.
But I think we as senior devs understand that leaky abstractions are one of the most difficult problems to solve. Hence I don’t complain too much and do my best to keep discussions on the topic productive because I know this stuff is mega-hard.
But I’m free to pursue ways of doing stuff that make me smile, be excited about programming again, and also be productive – because as much as I love flinging characters on the screen, I also want to make money and not be a hobby computer nerd until my grave. There are many more things to life than this that also make it a joy to live through, and trying to be more productive is one way to help us pursue those instead (== less hours in front of a screen), and not the ever-elusive 100% mastery.
2 Likes
@taro Sorry for off-topic, got carried away.
@AstonJ feel free to separate comments in an off-topic thread if you feel it must be done. I simply enjoy chatting with @gregvaughn so much. Or if not, feel free to delete this comment because it is definitely off-topic.
1 Like
You absolutely are. However …
This does not resonate with me. I almost never notice the organization of source code on the file system any more. I don’t have anything to offer to help. So, that’s why I’m bowing out of the conversation.
2 Likes
I use Live Grep in my IDE as well.
But I want to be able to fit a small app into one screen. For me it’s a hard requirement.
Thanks for engaging. 
3 Likes
Oh I appreciate every single comment. I read and learn and take notes from all of them. Thanks for sharing your wisdom. I hope moderators are happy too. Your off-topics are inspiring. I took a note of DSL for text protocols.
Please speak up. Difference is the very reason we should be talking. It’s probably only thing I’m bringing to this community. No one has to get dissuaded. I appreciate that you have chimed in when it’s rainy. I have my hopes for Elixir adoption. But I can’t do it alone. So I started the discussions in this community.
I started web development learning SvelteJS. SvelteKit is amazing in its way but there was not enough batteries included for my project. I wanted to learn a major framework and an awesomer language. Found Phoenix on Fly.io and Elixir was perfect. I understand the benefits and wisdom behind full-scale frameworks just that much.
As I come from more design disciplines, I find some software development practices are destined to overload one’s cognitive capacity. They would diverge into infinity without coming back to a simple principle. When it hits the critical point, it becomes an abomination that no one understands. And I see the effort to mitigate this in, for example Saša’s Boundary and his posts.
The source of this complexity doesn’t seem trivial and I haven’t fully explored this. But I wonder if it’s rooted to the file system of OS? Files are often grouped by their categories in a project, instead of their context. spawn feels weird to me because among all the functions that describe logics and data flow, it describes processes, which feels like another dimension of the system. Yet they are all written and managed the same way in the files of the directory system.
4 Likes
I like this. It’d be cool if you extended this idea for a channel router as well, maybe borrowing ideas from ChannelHandler with some adjustments on the syntax to fit Mar.
2 Likes
