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.
acalejos
taro
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!
0
taro
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.
0
cmo
I’ve only read and heard praise or constructive feedback about Req. Where do you see the dissent?
0
taro
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
acalejos
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
gregvaughn
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
dimitarvp
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
gregvaughn
@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.
5
dimitarvp
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