10 ms·

I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other

by midrus 5y ago

I really hope some sanity comes back to this industry. Rails and Laravel are the best tools by far to build like... 90% of what we build on the internet (Other 10% being offline first apps and stuff like figma, etc). It just hurts to see how my team, and previous teams I worked with struggle with all the SPAs and microservices, and Go backends and GraphQL nonsense when what we're doing are just fancy crud forms with maybe one or two really interactive widgets overall. So much time and money wasted just for following fashion.

brightball 5y ago
I’d add Elixir and Phoenix to that list and then agree with you.
- MathCodeLove 5y ago
  I'd add Phoenix to the list when it gets its documentation in the same echelon as that of Rails or Laravel. It may be as productive if you already know how to use it, but good luck building anything non-trivial on your own if you don't.
  - brightball 5y ago
    Don’t you usually learn how to use your tools before you build with them? This feels like a strange response.
    - nickjj 5y ago
      I've always found the Phoenix docs to be more like references. There's "guide-like" aspects to it but in my opinion it's no where near the level of where the Rails docs are. I agree with the person we're replying to, I almost always found myself having to research third party sources when learning Phoenix (blog posts, IRC, etc.) to get answers to questions that I never had to ask about Rails, Flask or Django because their docs covered it very well. The Rails doc feels like you have DHH at your side guiding you on exactly how to do something in the context of a practical application and whenever you think to yourself "that's great, but what if I want to do...", often times the very next sentence in the docs will answer your exact question. The Rails routing docs https://guides.rubyonrails.org/routing.html https://guides.rubyonrails.org/routing.html are a great example of this when they talk about namespaces and scopes but there's a million other examples. It feels like it was written by folks who have been through the thick of it and back 100 times over to extract out the exact questions folks would have when using various features of the framework. Each piece of the docs feels like it's a mini book written on par with any book on a technical subject and then there's a completely separate reference guide docs with more examples. Even the styling of the page itself just feels good. It's really easy to skim and navigate. The Phoenix docs feel more like a big wall of text with a few small headers and code blocks. It's hard to explain but personally my brain identifies the Rails docs as easy to mentally parse where as the Phoenix docs are not based on nothing more than the styling aspect alone. Overall the Rails docs feel like they are written with a ton of empathy around the person reading them, completely holding your hand from beginning to end to solve a practical issue which is exactly what you need when learning something new. The reference guides are always there if all you care about are a few quick examples.
      - brightball 5y ago
        That’s true. Rails docs are fantastic. Don’t get me wrong here, I’m a big Rails fan as well. Been using it for a decade at this point. It’s the best development experience out there. But eventually, you’re going to run into issues that are harder to address with it. Happens on every big project I’ve run into. But, they all became big projects thanks to the productivity of Rails.
    - lovich 5y ago
      As a bronze league engineer who still pulls a decent wage, you absolutely do not need to understand your tools to build things.
  - pythonaut_16 5y ago
    What do you find lacking in the Phoenix docs? I've always been impressed with the docs in the major Elixir and Phoenix libraries.
    - MathCodeLove 5y ago
      There's a good deal that I feel is lacking, but a big issue is the lack of continuity of documentation between Phoenix's component parts. If I want to build a CRUD app with Rail, Django, or Laravel, then I can get all the information I need from their docs. If I want to do the same in Phoenix, I'll have to jump between the docs for Phoenix, Ecto, Plug, and HEEx/Liveview. Rails, while it has its equivalent of these modules, presents them in a cohesive manner and makes it clear the role they play in the greater context of the application. Phoenix doesn't make it nearly as clear and instead of being able to gradually learn these various concepts as they become relevant you have to take on the burden of them all before being able to even begin to be productive.
      - sfusato 5y ago
        Have you looked at the Phoenix Guides [1]? [1] https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html
        MathCodeLove 5y ago
        Yes. They do a poor job of the above and I still stand by what I said.
  - gregors 5y ago
    I like Phoenix, I really really do...but you are correct regarding docs. The documentation in Phoenix is fine for "what does this function do?". However, if you want the Rails Guides experience - it's just not there.
hellcow 5y ago
Calling it "fashion" is disingenuous. I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since... I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.
- simplify 5y ago
  Go is good and all, but it's odd to compare it to the vast feature set that Rails provides. The point of Rails is to give you standard tools so you don't have to consider / reimplement / configure / hook up e.g. background processes for every app you build.
- christophilus 5y ago
  This is my experience, too. I'm currently working on a TypeScript+Node service, which is decent, but Go is my preference these days.
- xionon 5y ago
  > I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." This hasn't been a serious problem in a decade. > We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since... The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug. (ex-Braintree engineer, we processed billions of requests on Rails)
  - hellcow 5y ago
    > types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug. If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking. > This hasn't been a serious problem in a decade. That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.
berkes 5y ago
There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software. Rails has its strong sides. And its weak sides. Trade-offs are to be investigated. An extremely weak side of Rails, is how it is very tightly coupled to the database. Which -its strong side- is perfect for simple CRUD applications. But it falls down quickly when you have much more event-driven or domain-logic heavy applications. And yes, I know Rails can be used for this. But just like I can, potentially write a web-app in Bash, it's not where it shines and it will bring you pain. For Rails, the pain quickly becomes evident when a lot of business-rules are spread out through "Validators". Or when migrations become a pain to manage. Or when you have more and more complexity moved into async jobs. All of these are signs that the CRUD-nature and/or the tight database-coupling is harming you more than helping you. Choosing some other architecture that better fits your domain is not "following the latest fashion". It's sane, proper due-diligence.
- Karunamon 5y ago
  >There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software. It's also a forthright description. Developers chase fads, the new shiny, just like everyone else does. Neither are we immune to cargo-culting; I'd go so far as to make the absurd comparison to web apps written in shell script to be an instance of this. I've been behind the curtain on large Rails apps. Every issue you mentioned is either reasonably mitigated or exists more-or-less equally on other frameworks.
  - robertlagrant 5y ago
    Well, Rails wants to be on a relational database. That's a pretty strong constraint that - say - NextJS or Flask avoid. I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects. Still yet to put my money where my mouth is on NextJS though.
treeman79 5y ago
I’ve seen a few times where a company replaced one guy using a Rails monolith with jQuery and replaced em with a 30 person team that is far less effective.
- midrus 5y ago
  THIS I think that if we were more pragmatic and less about following the current fashion or trying to do what FANG does (which probably is just the opposite of what everyone else needs) we wouldn't be in such a high need of developers... which... I shouldn't be saying out loud probably :-)
- midrus 5y ago
  Also, note that when not going the microservices/spa/kubernetes route, the alternative is not "old style reloads on every click and jQuery spaghetti", I'd say that's equally as bad. Nowadays there are alternative middle ground solutions such as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which provide a great way to organize the code and keep it maintainable.
  - treis 5y ago
    I think these are all bad ideas on the other extreme. Once you incur the cost of a round trip to the server the additional latency due to sending HTML instead of JSON is pretty close to 0. You really only need something like Turbolinks to avoid a full page reload/render. Amusingly enough at $Current_Job the JSON we send back that is larger in size than the HTML it's rendered into. We'd likely have better performance doing all server side rendering + Turbolinks.
    - midrus 5y ago
      Yeah, this is the case I was talking about with the 90% of cases I was referring to. At a previous job, we had a many, many thousand lines codebase of typescript, redux, observables, epics, thunks, custom server API libraries, websockets, Elixir backend, Kafka to communicate with other microservices, etc, etc..for...a frigging signup wizard. Which then failed in so many stupid ways, had almost no server validation (everything unexpected was a 500) and it took days to do the smallest of the changes. But hey, don't dare to suggest doing this with Laravel would take 2% of the effort because you'd be crucified in the next frontend guild meeting.
hombre_fatal 5y ago
At the end, it's all trade-offs. After working with Rails for 10 years, I ended up preferring the opposite end of the spectrum of just using small frameworks like Express and just writing our own boilerplate. I agree with Elm's take on boilerplate: it's not boilerplate and glue code that makes application development hard, and I don't think it's always a net positive to build abstraction around it like you see in large frameworks. As a Rails app grows, I just find myself spending more and more time unrolling abstraction to figure out what's going on. Most things, like authentication, I prefer to just read in the application code itself to see what's being written to the cookie rather than dissect, say, the highly-abstracted Devise gem in a Rails app to debug session issues.
- midrus 5y ago
  Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in elm and building your graphql API with Apollo and your serveless functions on kubernetes your causing a cost to your company which could have been avoided. That's not engineering. That's playing with Legos just because we can.
  - treis 5y ago
    I don't think this is a fair characterization of their post. They aren't playing with legos. Rails trades boilerplate code savings for abstraction. The GPs point is that boilerplate isn't hard to write while abstraction makes everything harder. And I think it's a fair criticism. Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there.
    - waffle_maniac 5y ago
      The abstraction hasn’t hindered me much and I work on a monolith. One problem I have faced is when the amount of database queries on a page explodes it becomes hard to optimize without caching. I would prefer to avoid caching but that doesn’t appear to be the rails way (and for obvious reasons). Also, at a company with a Rails app you do sometimes get other sources and processes polluting your Rails app. And when that happens you can’t utilize the efficiencies that rails provides.

by midrus 5y ago

brightball 5y ago

I’d add Elixir and Phoenix to that list and then agree with you.

MathCodeLove 5y ago
I'd add Phoenix to the list when it gets its documentation in the same echelon as that of Rails or Laravel. It may be as productive if you already know how to use it, but good luck building anything non-trivial on your own if you don't.
- brightball 5y ago
  Don’t you usually learn how to use your tools before you build with them? This feels like a strange response.
  - nickjj 5y ago
    I've always found the Phoenix docs to be more like references. There's "guide-like" aspects to it but in my opinion it's no where near the level of where the Rails docs are. I agree with the person we're replying to, I almost always found myself having to research third party sources when learning Phoenix (blog posts, IRC, etc.) to get answers to questions that I never had to ask about Rails, Flask or Django because their docs covered it very well. The Rails doc feels like you have DHH at your side guiding you on exactly how to do something in the context of a practical application and whenever you think to yourself "that's great, but what if I want to do...", often times the very next sentence in the docs will answer your exact question. The Rails routing docs https://guides.rubyonrails.org/routing.html https://guides.rubyonrails.org/routing.html are a great example of this when they talk about namespaces and scopes but there's a million other examples. It feels like it was written by folks who have been through the thick of it and back 100 times over to extract out the exact questions folks would have when using various features of the framework. Each piece of the docs feels like it's a mini book written on par with any book on a technical subject and then there's a completely separate reference guide docs with more examples. Even the styling of the page itself just feels good. It's really easy to skim and navigate. The Phoenix docs feel more like a big wall of text with a few small headers and code blocks. It's hard to explain but personally my brain identifies the Rails docs as easy to mentally parse where as the Phoenix docs are not based on nothing more than the styling aspect alone. Overall the Rails docs feel like they are written with a ton of empathy around the person reading them, completely holding your hand from beginning to end to solve a practical issue which is exactly what you need when learning something new. The reference guides are always there if all you care about are a few quick examples.
    - brightball 5y ago
      That’s true. Rails docs are fantastic. Don’t get me wrong here, I’m a big Rails fan as well. Been using it for a decade at this point. It’s the best development experience out there. But eventually, you’re going to run into issues that are harder to address with it. Happens on every big project I’ve run into. But, they all became big projects thanks to the productivity of Rails.
  - lovich 5y ago
    As a bronze league engineer who still pulls a decent wage, you absolutely do not need to understand your tools to build things.
- pythonaut_16 5y ago
  What do you find lacking in the Phoenix docs? I've always been impressed with the docs in the major Elixir and Phoenix libraries.
  - MathCodeLove 5y ago
    There's a good deal that I feel is lacking, but a big issue is the lack of continuity of documentation between Phoenix's component parts. If I want to build a CRUD app with Rail, Django, or Laravel, then I can get all the information I need from their docs. If I want to do the same in Phoenix, I'll have to jump between the docs for Phoenix, Ecto, Plug, and HEEx/Liveview. Rails, while it has its equivalent of these modules, presents them in a cohesive manner and makes it clear the role they play in the greater context of the application. Phoenix doesn't make it nearly as clear and instead of being able to gradually learn these various concepts as they become relevant you have to take on the burden of them all before being able to even begin to be productive.
    - sfusato 5y ago
      Have you looked at the Phoenix Guides [1]? [1] https://hexdocs.pm/phoenix/overview.html https://hexdocs.pm/phoenix/overview.html
      - MathCodeLove 5y ago
        Yes. They do a poor job of the above and I still stand by what I said.
- gregors 5y ago
  I like Phoenix, I really really do...but you are correct regarding docs. The documentation in Phoenix is fine for "what does this function do?". However, if you want the Rails Guides experience - it's just not there.

hellcow 5y ago

Calling it "fashion" is disingenuous. I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since... I've been happily running Go backends for the past 7 years now, and they're stable and fast and easy to refactor.

simplify 5y ago
Go is good and all, but it's odd to compare it to the vast feature set that Rails provides. The point of Rails is to give you standard tools so you don't have to consider / reimplement / configure / hook up e.g. background processes for every app you build.
christophilus 5y ago
This is my experience, too. I'm currently working on a TypeScript+Node service, which is decent, but Go is my preference these days.
xionon 5y ago
> I ran Rails in production years back and swore it off then. We had constant memory leaks that seemingly came from Rails itself, and the only solution we had was "just restart the server." This hasn't been a serious problem in a decade. > We also had no typing then, so every bug was a runtime bug. Hopefully it's improved in the years since... The ecosystem has been introducing gradual typing, but even at high scale, types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug. (ex-Braintree engineer, we processed billions of requests on Rails)
- hellcow 5y ago
  > types were not remotely the most common type of problem I ever ran into, and certainly not "every" bug. If you took that away from what I wrote, I apologize. I meant that without a compiler and type-checker, you would only find bugs at runtime. In my experience, the vast majority of these would be easily discovered by a compiler. Presumably that experience is shared by Ruby devs since they're now adding type-checking. > This hasn't been a serious problem in a decade. That may be true. I haven't had any need to revisit Ruby or Rails since I moved to Go. But it was a serious problem with no workaround, and I've never encountered any scenario like that since switching to Go.

berkes 5y ago

There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software. Rails has its strong sides. And its weak sides. Trade-offs are to be investigated. An extremely weak side of Rails, is how it is very tightly coupled to the database. Which -its strong side- is perfect for simple CRUD applications. But it falls down quickly when you have much more event-driven or domain-logic heavy applications. And yes, I know Rails can be used for this. But just like I can, potentially write a web-app in Bash, it's not where it shines and it will bring you pain. For Rails, the pain quickly becomes evident when a lot of business-rules are spread out through "Validators". Or when migrations become a pain to manage. Or when you have more and more complexity moved into async jobs. All of these are signs that the CRUD-nature and/or the tight database-coupling is harming you more than helping you. Choosing some other architecture that better fits your domain is not "following the latest fashion". It's sane, proper due-diligence.

Karunamon 5y ago
>There is no "sanity" lost, nor are the masses "following fashion". That is unfair to those who put real thought, time and effort in their software. It's also a forthright description. Developers chase fads, the new shiny, just like everyone else does. Neither are we immune to cargo-culting; I'd go so far as to make the absurd comparison to web apps written in shell script to be an instance of this. I've been behind the curtain on large Rails apps. Every issue you mentioned is either reasonably mitigated or exists more-or-less equally on other frameworks.
- robertlagrant 5y ago
  Well, Rails wants to be on a relational database. That's a pretty strong constraint that - say - NextJS or Flask avoid. I think it's true that it sometimes feels a little crazy that form posts are so much tricker in the SPA world. I sometimes wonder if NextJS has got this right: build a semi-old fashioned web app with a frontend and a backend, so all the data transport in between those is pretty light on code, and then use APIs to data services with nicely defined domain objects. Still yet to put my money where my mouth is on NextJS though.

treeman79 5y ago

I’ve seen a few times where a company replaced one guy using a Rails monolith with jQuery and replaced em with a 30 person team that is far less effective.

midrus 5y ago
THIS I think that if we were more pragmatic and less about following the current fashion or trying to do what FANG does (which probably is just the opposite of what everyone else needs) we wouldn't be in such a high need of developers... which... I shouldn't be saying out loud probably :-)
midrus 5y ago
Also, note that when not going the microservices/spa/kubernetes route, the alternative is not "old style reloads on every click and jQuery spaghetti", I'd say that's equally as bad. Nowadays there are alternative middle ground solutions such as Livewire, Hotwire, LiveView, Unpoly, Htmx, etc which provide a great way to organize the code and keep it maintainable.
- treis 5y ago
  I think these are all bad ideas on the other extreme. Once you incur the cost of a round trip to the server the additional latency due to sending HTML instead of JSON is pretty close to 0. You really only need something like Turbolinks to avoid a full page reload/render. Amusingly enough at $Current_Job the JSON we send back that is larger in size than the HTML it's rendered into. We'd likely have better performance doing all server side rendering + Turbolinks.
  - midrus 5y ago
    Yeah, this is the case I was talking about with the 90% of cases I was referring to. At a previous job, we had a many, many thousand lines codebase of typescript, redux, observables, epics, thunks, custom server API libraries, websockets, Elixir backend, Kafka to communicate with other microservices, etc, etc..for...a frigging signup wizard. Which then failed in so many stupid ways, had almost no server validation (everything unexpected was a 500) and it took days to do the smallest of the changes. But hey, don't dare to suggest doing this with Laravel would take 2% of the effort because you'd be crucified in the next frontend guild meeting.

hombre_fatal 5y ago

At the end, it's all trade-offs. After working with Rails for 10 years, I ended up preferring the opposite end of the spectrum of just using small frameworks like Express and just writing our own boilerplate. I agree with Elm's take on boilerplate: it's not boilerplate and glue code that makes application development hard, and I don't think it's always a net positive to build abstraction around it like you see in large frameworks. As a Rails app grows, I just find myself spending more and more time unrolling abstraction to figure out what's going on. Most things, like authentication, I prefer to just read in the application code itself to see what's being written to the cookie rather than dissect, say, the highly-abstracted Devise gem in a Rails app to debug session issues.

midrus 5y ago
Yes, me too. But it makes absolutely no sense business wise. We like to play with tech, and learn and use the new shinny. While you're writing your frontend in elm and building your graphql API with Apollo and your serveless functions on kubernetes your causing a cost to your company which could have been avoided. That's not engineering. That's playing with Legos just because we can.
- treis 5y ago
  I don't think this is a fair characterization of their post. They aren't playing with legos. Rails trades boilerplate code savings for abstraction. The GPs point is that boilerplate isn't hard to write while abstraction makes everything harder. And I think it's a fair criticism. Large Rails projects are difficult to work in because of that abstraction. It can be hard to even figure out what code is running let alone identifying bugs there.
  - waffle_maniac 5y ago
    The abstraction hasn’t hindered me much and I work on a monolith. One problem I have faced is when the amount of database queries on a page explodes it becomes hard to optimize without caching. I would prefer to avoid caching but that doesn’t appear to be the rails way (and for obvious reasons). Also, at a company with a Rails app you do sometimes get other sources and processes polluting your Rails app. And when that happens you can’t utilize the efficiencies that rails provides.