26 ms·

The years when Rails monoliths were the de facto web stack were some of the best of my career. As I progressed in my career and the popular tech stack shifted t

The years when Rails monoliths were the de facto web stack were some of the best of my career. As I progressed in my career and the popular tech stack shifted to things like microservices, document DBs, serverless functions, Node, importing tiny nom packages for everything, docker containers, React, and GraphQL, the sheer cognitive overhead of getting a simple app up and running gradually took all the fun out of the job for me. The fast, satisfying feedback loop of writing a feature in Rails was replaced with weeks-long coordination efforts between independent microservices, constant discussions about tooling, and doubts over whether or not we had chosen the “right” flavor-of-the-week framework or library for our product. Every time I started a new project or a joined a new company, we had the reinvent the wheel for our bespoke Node/serverless stack and have the same tiring conversations about naming conventions, logging, data consistency, validation, build scripts, etc., all of which Rails gives you by default. I ended up spending more time on tooling setup than actual business logic. I eventually gave up and switched to a semi-technical product management role.

callmekatootie 5y ago
> I eventually gave up and switched to a semi-technical product management role. Could you let me know what your job title is - I am looking for something similar where I would like to work on some semi technical stuff and at the same time manage developers but not sure what title I am supposed to look for.
- zxcq544 5y ago
  Search for "Project managment". There is "Product management" which sounds similar but it's a bit different: project manager talks with developers and manages task complition while product manager talks to product owner(and other business people) and team lead and manages product money making and overall future strategy.
- iamphilrae 5y ago
  “Solution Architect” is normally the role that lies between Product Owners and the Dev team. It’s somewhat technical, especially if you don’t have a Technical Architect counterpart.
haarts 5y ago
I couldn't agree more. Recently I switched back to Rails after 10 years. I can't say I enjoy the whole asset pipeline business but I yearn for a simpler time and Rails gives that (to a degree). My only wish it was simpler to host. I don't necessary want to buy into render.com or heroku.
- jfabre 5y ago
  You should try phoenix and elixir, only been playing with them for less than a week and as a long time rails/ruby developer this is what it feels like again.
  - Toutouxc 5y ago
    I'm also a Rails dev, currently doing Advent of Code in Elixir, I haven't tried Phoenix yet, but writing Elixir feels a lot like writing Ruby for the first time. It's the same kind of sexy, of-course-you-can-do-that feeling.
    - dnautics 5y ago
      That's really funny, my perception of Elixir is generally the sentiment "of course you can't do that". (that's a good thing).
      - Toutouxc 5y ago
        Funny, you're also right. Of course you can't do that weird hacky thing you could totally do in Ruby but maybe shouldn't. I meant something more like "of course there's a function for that with the name you'd expect".
    - AlchemistCamp 5y ago
      For me Elixir didn't feel too much like Ruby, but Phoenix sure felt a lot like Rails. YMMV since Phoenix has gradually become more and more of its own thing than it felt like in 2016 when I learned it. There's really nothing I miss about Ruby for web dev and Elixir feels like a complete win to me these days. Ruby is still far nicer for unix-y scripting, though.
mohanmcgeek 5y ago
I started as a rails developer. This is just looking at the past with rosy lens. Given the popularity of rails at the time, if node.js was unproductive like you say it is, it would have never caught on. The reality is that express was considerably simpler and easier than rails and that's what made many of the internet companies we have today even possible.
- culopatin 5y ago
  Is express still easier than Rails? Im a noob and the reason I’m asking is that I’m getting somewhat stuck with a project in spring and I find their docs very fragmented and the community is more advance/intermediate or business oriented. It’s just me building this and I have no one in my circle that’s familiar with spring.
  - innocentoldguy 5y ago
    I've been a software engineer for 32 years (I'm in management now, but I still write non-critical-path code). During my career, I've used Express, Koa, Rails, Django, Laravel, Pyramid, Sinatra, Flask, Pedestal, Luminus, Phoenix, and several other backend frameworks. If I were starting out as a "noob" today, I'd learn Elixir and Phoenix.
- pawelmurias 5y ago
  node.js was a lot more performant and uses a language people already know from writing in browser code
- simion314 5y ago
  Node productivity changes after a few years, I can give you examples from my work from this week (no internet stories) where the npm packaging bullshit wasted my time , and I just had to hack my way for a fix and postpone the inevitability that a giant cleanup needs to be done in our dependencies. After the sit I seen with my own eyes(not internet stories) I am convinced that there are packages like "red" that defines the color RED="#ff0000" and a package colors that depends on all colors, and probably a few big dev tools that depends on the colors one, this node/npm ecosystem is crazy but we are paid to maintain and fix other people stupidity. EDIT forgot to mention why stuff gets complex after time, you hit cases where you need to get a new version of package A , but A needs say a new node version or some new other shit, but you have a package B that will fail on the new node version with some stupid error, and package B was abandoned or the fix is to upgrade to a new major version... also you will notice that your packages are now abandoned and might have security issues when you inherit some old project , it is a big mess.
aeonflux 5y ago
> cognitive overhead of getting a simple app up and running gradually took all the fun out of the job for me This video was recently linked in other thread on HN, but I feel this comment really resonates with the main conclusion: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk
tannhaeuser 5y ago
Just that React, Webpack, graphql backends and millions of other packages and pipeline tools are on npmjs.com does not mean you have to use them. You can still create super-slim, to the point, and timeless backends using express.js (which was inspired by Ruby's Sinatra after all) and vanilla frontends. Doesn't get you brownie points on your CV though, which I think is the actual problem.
- lostcolony 5y ago
  That, and the OP mentions they have a business background. If you don't come from a "how to write code starting with no batteries, forming your own opinions, etc", and all the tutorials are "you need to put some spaces before a string? We'll include leftpad!" style dependency hells, I can see Rails feeling like a breath of fresh air since it's batteries included, and heavily opinionated.
- julik 5y ago
  True, as long as people mindfully not using them drive the team. But the fact that "they are there" - and the fact that visible folks in the community usually either make the tools or endorse them (no wonder because they have to do personal marketing) means that it only takes that many new team members until every one of them regrets "not having" their favourite mini-tool used on that particular team, on this particular project. It takes extreme will (and some unpleasant conversations) to drive against that trend, and in the end folks might leave because of being denied using what they would like to try. So while you can "not use" all the new fancy tooling you will have the weight of convincing your peers that they do not need them either.
afavour 5y ago
Sounds like the managers that came before you failed you! Not to sound accusing but if this happened with multiple jobs then maybe you could have asked more questions at the interview stage. You can usually see dysfunction like that a mile away. There's no need to chase the latest Node JS shenanigans. It feels like it's all we talk about on HN but a huge, huge number of developers are out there happily coding away in Java, C# and all the rest. Even within Node world the majority are using the exact same React stack (the homogeneity of which is the reason for using it in the first place). IMO Ruby has faded because it never found its niche. Java and C# thrive in the corporate world. Python already exists as a dynamically typed server language. As much as people complain, writing server-side web stuff in JS does make sense given it's what you're using in the client. So where does Ruby go?
- cloverich 5y ago
  The language is less important than the supporting tooling. IMHO we are just now, a decade later, seeing frameworks crop up in node that look anything like the out of the box usefulness that was the rails and django apps I was first exposed to. My honest opinion from several startups is that most sub ten year vets just don’t know that stuff existed already and / or just how much you can ask of your tech stack. I generally agree with your point though.
  - midrus 5y ago
    100% this. I've always said that the ecosystem, the tooling, the editor support, the libraries, the frameworks and the availability of people to hire are far more important than the language. For example it irks me when people say they like react because jsx or Vue because templates...that's the smallest of the reasons to choose one or another!!! Same thing with Rails/Laravel/etc...people don't choose it because PHP or because Ruby , etc...the language doesn't matter at all, the tooling does matter it all.
    - cutler 5y ago
      Paul Graham, founder of YC would disagree. He claimed Common Lisp was the secret weapon behind Viaweb's success.
pjmlp 5y ago
They were only a de fact web stack at certain types of shops, I have been doing Java, .NET and C++ all along, Rails came and went, and I kept doing boring technology. I guess by now Rails could also be considered boring technology. It is tiring to keep track of latest fads, specially those that don't happen to stick around, so only move when dust settles down. Yeah one might lose business opportunities from not being first mover, on the other hand, there are business opportunities to port back the surviving projects into classical development stacks. For me, still much better than dealing with management.
omarhaneef 5y ago
I think this is also a function of team size. Suppose you have been given 100,000 developers to work on a website, but it will have millions of customers and things cannot fail. Now it is actually useful to be able to parcel out the database layer to a group of 1000, and they can split up each service into groups of 100 etc. There are enough people to decide what conventions, logging, validation people ought to use and perhaps measure them. If all of them hack on the same Rails codebase they might be running into each other all the time. Of course, for a solo developer, it makes sense to use Rails/Django/etc. Now there is a little spot in between 2-99,999. It is possible that there is a team or two at this level. And I think that gear shift or pathway has not yet been discovered. Typically you start on rails, suspect you should switch and then switch way too late. A pathway might look like this: Django -> Django API + VueJs -> Redis + update database? It probably depends on the challenges. If someone has an idea, or something they have tried, it would be interesting to take a look so please share. Edited for clarity.
- andjd 5y ago
  This is an interesting example of the 80-20 rule (or some variant of it) The vast majority of businesses/projects are small, and will only have one or a small number of developers working on it. So Ruby on Rails (or PHP or Wordpress) is a suitable choice for maybe 80% of projects. At the same time, a very small number of businesses require 100,000+ (or even just 1000+) developers. These businesses, because they have so many developers, employ the vast majority of professional developers. Thus, maybe only 20% of professional developers work on products that are typical of business needs. This disparity explains why communities on Hacker News are typically so negative towards Ruby on Rails. It also explains part of what makes Ruby on Rails so remarkable. Even after all these years, it has a thriving community and has resisted the pull to become more "enterprisy." It's still a tool that is targeted at and well suited for a large swath of business cases, the vast majority of which will likely never need to migrate to something "better".
  - jack_riminton 5y ago
    "from HELLO WORLD to IPO" as dhh said today https://twitter.com/dhh/status/1471267036793765888?s=20 https://twitter.com/dhh/status/1471267036793765888?s=20
sam0x17 5y ago
At Arist (YC S20) we've found that we can have our cake and eat it too by using Ruby on Jets, which is a nearly 100% drop-in replacement for Rails that runs on AWS Lambda. Our service sends messages to hundreds of thousands of people at scheduled moments in the day, and traffic is incredibly spikey, so combining the productivity of Rails and the Ruby ecosystem with the cost effectiveness and scalability of Lambda was a no-brainer. It also passed muster recently when we subjected our platform to a comprehensive penetration test. We also get the benefits of a mono-repo and the benefits of microservices in the same application footprint, because every controller method is automatically deployed as its own independent lambda (this is core to how Jets works), but we're still in the usual Rails mono-repo format we all know and love. Also very strong integration between ApplicationJob and background lambdas has been killer for us. One thing I've always said is the real difficulties in software development happen at the seams where services connect with other services. This sort of strategy (and particularly, the mono-repo format) minimizes the number of seams within your application, while still giving you the scalability and other benefits of microservices and serverless.
- hu3 5y ago
  That sounds great! Is there a blog post about the tech stack? My main concern with serverless/lambda is cold start time. How do you deal with it? What does the p99 latency look like? Also how do you scale the usual bottleneck which is the database?
  - sam0x17 5y ago
    There is an auto-warming option -- we keep it warmed up every 5 seconds so it's always super peppy -- requests served within 100ms generally, sometimes much faster. Appdex hovers around 0.996 but some webhooks are included in there so it's probably faster in reality.
  - sam0x17 5y ago
    DB-wise we utilize the usual postgresql cluster setup with read clones in several regions. We could easily partition by course or by org if we had to but honestly we could probably scale up to series C+ before needing to do that.
wpietri 5y ago
I get that for sure. I've been avoiding learning React because I keep waiting for the space to settle down. I was very interested to see how the Rails folks are talking about their latest version: https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-visi... In particular there's a theme of JS being totally optional: "Rails 7 takes advantage of all of these advances to deliver a no-Node default approach to the front end – without sacrificing neither access to npm packages nor modern JavaScript in the process." "The same approach is taken with CSS bundlers that rely on Node. [...] If you’re willing to accept the complexity of a Node dependency, you can pre-configure your new Rails app to use any of them" That seems like a smart goal. They're not trying to go it alone, but they're clearly trying to draw some boundaries that keep the JS chaos/complexity at the edges.
- bern4444 5y ago
  React feels pretty settled now, it's been out for 10+ years, hooks and functional components have become the standard. If you want to learn it I think it's at a mature enough place. Popular libraries like redux have been rebuilt to use hooks and simplify the integration. I'd also check out Remix[0] if you wanted to get into a React framework. It's fairly new but extremely promising and easy to get up and running and even deployed anywhere (express server, cloud flare workers, deno, etc) [0] remix.run
  - ozzythecat 5y ago
    The last time I did web development, I used Angular 1.2 or something like that. I had some forms and many different views that talked to some REST APIs. It was never clear to me why/when I would need React. I read and worked through some tutorials years ago, and while the reactive/one way flow pattern was nice, I never had a problem with Angular. I recognize there have been many versions of Angular since then. And there are several web development frameworks, complex build tooling, etc. etc. Meanwhile, I’m still writing services in Java that handle 20,000 requests per second for a service that brings in revenue in the billions of dollars a year. And I’m writing C++ (very straightforward, no templates, few uses of pointers, etc) for cross platform mobile code. I have some Spark pipelines all written in Scala. Meanwhile the web stack continues to evolve… new technologies all just for rendering web pages. I don’t understand why. Admittedly there’s far more complexity in our use cases today than the HTML I was writing in 1999, but much of it is unnecessary bloat from bored developers.
z3t4 5y ago
> and have the same tiring conversations about naming conventions, logging, data consistency, validation, build scripts, etc. Sounds like bike-shedding to me. Eg. You start with solving trivial problems instead of the hard problems. Usually the first thing that is decided is what framework to use, often by a non technical person that herd from a friend that is was good. Rather then having the engineers sit down and think about what are the biggest challenges, and what is the best framework suited to solve the hardest problems.
- slingnow 5y ago
  OP never once stated that they started with those problems. What makes you think the engineering challenges weren't tackled first?
- deleted 5y ago
  [deleted]
neximo64 5y ago
This sounds more like you couldn't adapt to more people joining the company. The stack reflects your org structure.
- anonGone73 5y ago
  Conway's Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway
ozzythecat 5y ago
Micro services are usually overkill unless you’re working at a significant scale. For most projects such as corporate apps, it’s just unnecessary. It’s good to start simple and only add complexity when it’s really needed. It’s unfortunate the current trend is to start with massive complexity.
- innocentoldguy 5y ago
  Excellent advice! I recently worked at a company where the "architect" insisted on using Broadway and Kafka for what should have been basic CRUD operations. He got fired.
  - Nextgrid 5y ago
    That's refreshing to see. In a lot of startups he would've been promoted to some high level position, hired dozens of engineers to maintain the new monster and then invited to an AWS conference to brag about how they solve their (self-inflicted) problems, all while the business is bleeding money in cloud bills and engineer salaries.
princevegeta89 5y ago
Right, but a big project in Rails has all the problems you can think of: - slow to compile and run - easy target for spaghetti code - test suites get sluggish - hard to upgrade - won't scale well - with no static typing, large scale collaboration can easily break things - metaprogramming hell
- jaredcwhite 5y ago
  A big project in any stack has many problems. Vanilla Rails is going to scale way better than some wacky bespoke configuration of stitched-together NPM packages, which in my experience is what a lot of folks build now because they don't know any better.
  - princevegeta89 5y ago
    I've successfully run Java/Go projects with huge amounts of code without a lot of degradation in any direction whereas Rails seems to quickly come to a stopping point compared to other platforms. I've written my side project which is now at a huge size in Elixir, I'm yet to see any degradation so far. I'm sure Rails would have been a pain by now. Sorry I don't have much Node experience so can't comment.
    - jaredcwhite 5y ago
      Simply hasn't been my experience at all, and I've worked with numerous Rails projects large and small since 2008. If you prefer Java/Go/Elixir, knock yourself out, but I'm throughly satisfied with Ruby-based solutions.
      - princevegeta89 5y ago
        Got it. It's not impossible but I've been at multiple jobs involving Rails monolithic apps, they all really sucked from a maintenance and development perspective. P.S would have been happier if you had a better choice of words than "knocking myself out".
skohan 5y ago
By contrast, Node was a breath of fresh air for me. With Rails, you had to start with this already complex system and bend it to do what you want. With a greenfield node server, it only does what you tell it to and nothing more. No surprises.
- jaredcwhite 5y ago
  Building a complex SaaS app or backoffice app on a "greenfield Node server" is a supreme exercise in frustration.
  - skohan 5y ago
    There's a tool for every job, but for most of my use-cases, I'd rather have a webserver which is just a webserver, and get my front-end elsewhere. But I'm sure there are places where Rails is a great fit in the right hands. I'm not even using node very much these days. Serverless is what I would reach for for most professional applications these days.
- eclat 5y ago
  Sinatra covers that use case in Ruby.
p_l 5y ago
Out of those, though, I have to blame document DBs (and the start of NoSQL craze) on Rails :( To cut a long story short, Active Record (especially at the time) wasn't super keen on generating super good SQL that would do as much as possible in database, and Ruby 1.9 arrived with stable ordered hashes. Then someone implemented basic ActiveRecord wrapper on top of key/value store (I think it started with Berkeley DB or similar), and from there NoSQL was off to the races as "new hip thing"[1] [1] Meanwhile IBM IMS has been selling pretty well for last 40 years at the time ;)
- tinco 5y ago
  I don't fully understand your argument. Document DB's never fully got traction in the Rails community. Then Node.JS became popular because it did concurrent IO better, and it put document DB's front and center for no apparent reason.
  - p_l 5y ago
    It didn't get a lot of traction because it required some effort, but essentially the groups that jumped on them were also highly correlated with those that soon jumped to NodeJS, helped along with JSON serialization being rather obvious in JS context Though I would also consider their exodus to be a good thing for Rails ;)
- LargeWu 5y ago
  ActiveRecord was, even then, a much better ORM than exists in the Node world today. It was full featured and well hardened, and required basically no setup other than a class declaration. Plus, you could always drop down to the SQL if you needed to. Generally, it was a joy to use, and the performance was usually good enough. At some point, I gave up on even trying to use any Node ORM's because they were clunky and offered no value. It was easier to just drop straight to a knex session and write the queries natively.
  - kkarimi 5y ago
    You should check what Prisma team has been doing lately
khaledh 5y ago
Because of this unnecessary complxity in the webdev ecosystem, I switched my development career to other areas[^]. If I have to do webdev for a hobby project, I use Django and Postgres, with no JS frameworks whatsoever. It's liberating and fun. [^] Mostly data engineering at work, and low level os/system dev in my spare time.
- cutler 5y ago
  I hear ya. I perversely yearn for my days with Perl and CGI::Application. When I get up in the morning my eyes just happen to land on a stack of O'Reilly Perl books and it sets me off.
rglover 5y ago
Check out https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.
brightball 5y ago
I can relate. I was just about ready to exit programming until 2 things came along that removed all the analysis paralysis for me. 1. Elixir + Phoenix 2. TailwindCSS Elixir because you can build a monolith with it and everything is naturally separated by design. The runtime makes it impossible to hurt yourself. It addresses virtually every web use case in an ideal fashion that balances development speed with long term maintenance and scalability because of the language design trade offs. TailwindCSS because it removed the decision about which of the million frontend stacks in should be using. It makes it so easy to do anything I can dream up without feeling like I need to hire somebody to help with a pet project. And honestly, even though I like DevOps and database work just using Heroku/Fly/Gigalixir so I don’t have to worry about it makes my life easier.
- fouc 5y ago
  Elixir & Phoenix comes across as a "full-stack" framework with tons of potential, much more so than Ruby on Rails.
  - sam0x17 5y ago
    I agree that Elixir & Phoenix are the natural evolution in a post-Rails world, but looking further ahead, I think we've reached a point where the compiled & typed languages are starting to have all the goodies that used to be reserved only for the highest of the high level languages, and with web assembly support on the rise, it's going to start to become possible to use languages like this for both backend and frontend in a unified way. So for me, the next natural evolution is using something like Rust or Crystal but with very solid Railsy conventions and intelligent code sharing between frontend and backend. I think this combined with something like the Phoenix live view, but in Rust, is at least where I want my future to be, and I think a workflow like this could become the dominant pattern before, say, Elixir/Phoenix overtakes Rails. I tip my hat though to people diving into Elixir --- it is definitely a cool direction and one I would follow if I weren't already so sold on Rust/Crystal/etc.
    - montblanc 5y ago
pulse7 5y ago
I like monoliths... which are modular inside... no need for microservices, easy deployment even without Docker and Kubernetes... just a single binary...
tamersalama 5y ago
> I ended up spending more time on tooling setup than actual business logic. This is exactly why, in 2004, I moved from Java (Struts/Spring/Websphere/XML/...) to Rails. History repeats but we never learn. Kudos to Rails for remaining relevant.
register 5y ago
"the popular tech stack shifted": this says it all. Choice of a stack shouldn't be about popularity but rather about meeting the cultural,organizational,functional and non functional requirements of the solution. I said it already and I will continue saying it: our industry is driven more by fashion rather than good engineering practices. Every new trend solves a problem of the old generation but also introduces additional costs and new trade-offs. Adopting something blindly is not a good engineering approach. Software engineering is the art of balancing carefully your trade-offs and not to go with the latest fashion.
iamphilrae 5y ago
Ditto for me except swap RoR for PHP monoliths. Gone are the days where my only cognitive overhead was deciding between Less or Sass and CodeIgniter or “the fancy new” Laravel. Likewise I got fed up of where dev was going in the workplace, and moved into a Solution Architecture / Product Manager role. I still get a lot of satisfaction creating side projects in the tools of old (which IMHO work much nicer than 95% of “modern” applications), but thinking about doing development in my day job would give me a headache from the outset.

callmekatootie 5y ago

> I eventually gave up and switched to a semi-technical product management role. Could you let me know what your job title is - I am looking for something similar where I would like to work on some semi technical stuff and at the same time manage developers but not sure what title I am supposed to look for.

zxcq544 5y ago
Search for "Project managment". There is "Product management" which sounds similar but it's a bit different: project manager talks with developers and manages task complition while product manager talks to product owner(and other business people) and team lead and manages product money making and overall future strategy.
iamphilrae 5y ago
“Solution Architect” is normally the role that lies between Product Owners and the Dev team. It’s somewhat technical, especially if you don’t have a Technical Architect counterpart.

haarts 5y ago

I couldn't agree more. Recently I switched back to Rails after 10 years. I can't say I enjoy the whole asset pipeline business but I yearn for a simpler time and Rails gives that (to a degree). My only wish it was simpler to host. I don't necessary want to buy into render.com or heroku.

jfabre 5y ago
You should try phoenix and elixir, only been playing with them for less than a week and as a long time rails/ruby developer this is what it feels like again.
- Toutouxc 5y ago
  I'm also a Rails dev, currently doing Advent of Code in Elixir, I haven't tried Phoenix yet, but writing Elixir feels a lot like writing Ruby for the first time. It's the same kind of sexy, of-course-you-can-do-that feeling.
  - dnautics 5y ago
    That's really funny, my perception of Elixir is generally the sentiment "of course you can't do that". (that's a good thing).
    - Toutouxc 5y ago
      Funny, you're also right. Of course you can't do that weird hacky thing you could totally do in Ruby but maybe shouldn't. I meant something more like "of course there's a function for that with the name you'd expect".
  - AlchemistCamp 5y ago
    For me Elixir didn't feel too much like Ruby, but Phoenix sure felt a lot like Rails. YMMV since Phoenix has gradually become more and more of its own thing than it felt like in 2016 when I learned it. There's really nothing I miss about Ruby for web dev and Elixir feels like a complete win to me these days. Ruby is still far nicer for unix-y scripting, though.

mohanmcgeek 5y ago

I started as a rails developer. This is just looking at the past with rosy lens. Given the popularity of rails at the time, if node.js was unproductive like you say it is, it would have never caught on. The reality is that express was considerably simpler and easier than rails and that's what made many of the internet companies we have today even possible.

culopatin 5y ago
Is express still easier than Rails? Im a noob and the reason I’m asking is that I’m getting somewhat stuck with a project in spring and I find their docs very fragmented and the community is more advance/intermediate or business oriented. It’s just me building this and I have no one in my circle that’s familiar with spring.
- innocentoldguy 5y ago
  I've been a software engineer for 32 years (I'm in management now, but I still write non-critical-path code). During my career, I've used Express, Koa, Rails, Django, Laravel, Pyramid, Sinatra, Flask, Pedestal, Luminus, Phoenix, and several other backend frameworks. If I were starting out as a "noob" today, I'd learn Elixir and Phoenix.
pawelmurias 5y ago
node.js was a lot more performant and uses a language people already know from writing in browser code
simion314 5y ago
Node productivity changes after a few years, I can give you examples from my work from this week (no internet stories) where the npm packaging bullshit wasted my time , and I just had to hack my way for a fix and postpone the inevitability that a giant cleanup needs to be done in our dependencies. After the sit I seen with my own eyes(not internet stories) I am convinced that there are packages like "red" that defines the color RED="#ff0000" and a package colors that depends on all colors, and probably a few big dev tools that depends on the colors one, this node/npm ecosystem is crazy but we are paid to maintain and fix other people stupidity. EDIT forgot to mention why stuff gets complex after time, you hit cases where you need to get a new version of package A , but A needs say a new node version or some new other shit, but you have a package B that will fail on the new node version with some stupid error, and package B was abandoned or the fix is to upgrade to a new major version... also you will notice that your packages are now abandoned and might have security issues when you inherit some old project , it is a big mess.

aeonflux 5y ago

> cognitive overhead of getting a simple app up and running gradually took all the fun out of the job for me This video was recently linked in other thread on HN, but I feel this comment really resonates with the main conclusion: https://www.youtube.com/watch?v=pW-SOdj4Kkk https://www.youtube.com/watch?v=pW-SOdj4Kkk

tannhaeuser 5y ago

Just that React, Webpack, graphql backends and millions of other packages and pipeline tools are on npmjs.com does not mean you have to use them. You can still create super-slim, to the point, and timeless backends using express.js (which was inspired by Ruby's Sinatra after all) and vanilla frontends. Doesn't get you brownie points on your CV though, which I think is the actual problem.

lostcolony 5y ago
That, and the OP mentions they have a business background. If you don't come from a "how to write code starting with no batteries, forming your own opinions, etc", and all the tutorials are "you need to put some spaces before a string? We'll include leftpad!" style dependency hells, I can see Rails feeling like a breath of fresh air since it's batteries included, and heavily opinionated.
julik 5y ago
True, as long as people mindfully not using them drive the team. But the fact that "they are there" - and the fact that visible folks in the community usually either make the tools or endorse them (no wonder because they have to do personal marketing) means that it only takes that many new team members until every one of them regrets "not having" their favourite mini-tool used on that particular team, on this particular project. It takes extreme will (and some unpleasant conversations) to drive against that trend, and in the end folks might leave because of being denied using what they would like to try. So while you can "not use" all the new fancy tooling you will have the weight of convincing your peers that they do not need them either.

afavour 5y ago

Sounds like the managers that came before you failed you! Not to sound accusing but if this happened with multiple jobs then maybe you could have asked more questions at the interview stage. You can usually see dysfunction like that a mile away. There's no need to chase the latest Node JS shenanigans. It feels like it's all we talk about on HN but a huge, huge number of developers are out there happily coding away in Java, C# and all the rest. Even within Node world the majority are using the exact same React stack (the homogeneity of which is the reason for using it in the first place). IMO Ruby has faded because it never found its niche. Java and C# thrive in the corporate world. Python already exists as a dynamically typed server language. As much as people complain, writing server-side web stuff in JS does make sense given it's what you're using in the client. So where does Ruby go?

cloverich 5y ago
The language is less important than the supporting tooling. IMHO we are just now, a decade later, seeing frameworks crop up in node that look anything like the out of the box usefulness that was the rails and django apps I was first exposed to. My honest opinion from several startups is that most sub ten year vets just don’t know that stuff existed already and / or just how much you can ask of your tech stack. I generally agree with your point though.
- midrus 5y ago
  100% this. I've always said that the ecosystem, the tooling, the editor support, the libraries, the frameworks and the availability of people to hire are far more important than the language. For example it irks me when people say they like react because jsx or Vue because templates...that's the smallest of the reasons to choose one or another!!! Same thing with Rails/Laravel/etc...people don't choose it because PHP or because Ruby , etc...the language doesn't matter at all, the tooling does matter it all.
  - cutler 5y ago
    Paul Graham, founder of YC would disagree. He claimed Common Lisp was the secret weapon behind Viaweb's success.

pjmlp 5y ago

They were only a de fact web stack at certain types of shops, I have been doing Java, .NET and C++ all along, Rails came and went, and I kept doing boring technology. I guess by now Rails could also be considered boring technology. It is tiring to keep track of latest fads, specially those that don't happen to stick around, so only move when dust settles down. Yeah one might lose business opportunities from not being first mover, on the other hand, there are business opportunities to port back the surviving projects into classical development stacks. For me, still much better than dealing with management.

omarhaneef 5y ago

I think this is also a function of team size. Suppose you have been given 100,000 developers to work on a website, but it will have millions of customers and things cannot fail. Now it is actually useful to be able to parcel out the database layer to a group of 1000, and they can split up each service into groups of 100 etc. There are enough people to decide what conventions, logging, validation people ought to use and perhaps measure them. If all of them hack on the same Rails codebase they might be running into each other all the time. Of course, for a solo developer, it makes sense to use Rails/Django/etc. Now there is a little spot in between 2-99,999. It is possible that there is a team or two at this level. And I think that gear shift or pathway has not yet been discovered. Typically you start on rails, suspect you should switch and then switch way too late. A pathway might look like this: Django -> Django API + VueJs -> Redis + update database? It probably depends on the challenges. If someone has an idea, or something they have tried, it would be interesting to take a look so please share. Edited for clarity.

andjd 5y ago
This is an interesting example of the 80-20 rule (or some variant of it) The vast majority of businesses/projects are small, and will only have one or a small number of developers working on it. So Ruby on Rails (or PHP or Wordpress) is a suitable choice for maybe 80% of projects. At the same time, a very small number of businesses require 100,000+ (or even just 1000+) developers. These businesses, because they have so many developers, employ the vast majority of professional developers. Thus, maybe only 20% of professional developers work on products that are typical of business needs. This disparity explains why communities on Hacker News are typically so negative towards Ruby on Rails. It also explains part of what makes Ruby on Rails so remarkable. Even after all these years, it has a thriving community and has resisted the pull to become more "enterprisy." It's still a tool that is targeted at and well suited for a large swath of business cases, the vast majority of which will likely never need to migrate to something "better".
- jack_riminton 5y ago
  "from HELLO WORLD to IPO" as dhh said today https://twitter.com/dhh/status/1471267036793765888?s=20 https://twitter.com/dhh/status/1471267036793765888?s=20

sam0x17 5y ago

At Arist (YC S20) we've found that we can have our cake and eat it too by using Ruby on Jets, which is a nearly 100% drop-in replacement for Rails that runs on AWS Lambda. Our service sends messages to hundreds of thousands of people at scheduled moments in the day, and traffic is incredibly spikey, so combining the productivity of Rails and the Ruby ecosystem with the cost effectiveness and scalability of Lambda was a no-brainer. It also passed muster recently when we subjected our platform to a comprehensive penetration test. We also get the benefits of a mono-repo and the benefits of microservices in the same application footprint, because every controller method is automatically deployed as its own independent lambda (this is core to how Jets works), but we're still in the usual Rails mono-repo format we all know and love. Also very strong integration between ApplicationJob and background lambdas has been killer for us. One thing I've always said is the real difficulties in software development happen at the seams where services connect with other services. This sort of strategy (and particularly, the mono-repo format) minimizes the number of seams within your application, while still giving you the scalability and other benefits of microservices and serverless.

hu3 5y ago
That sounds great! Is there a blog post about the tech stack? My main concern with serverless/lambda is cold start time. How do you deal with it? What does the p99 latency look like? Also how do you scale the usual bottleneck which is the database?
- sam0x17 5y ago
  There is an auto-warming option -- we keep it warmed up every 5 seconds so it's always super peppy -- requests served within 100ms generally, sometimes much faster. Appdex hovers around 0.996 but some webhooks are included in there so it's probably faster in reality.
- sam0x17 5y ago
  DB-wise we utilize the usual postgresql cluster setup with read clones in several regions. We could easily partition by course or by org if we had to but honestly we could probably scale up to series C+ before needing to do that.

wpietri 5y ago

I get that for sure. I've been avoiding learning React because I keep waiting for the space to settle down. I was very interested to see how the Rails folks are talking about their latest version: https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-vision https://rubyonrails.org/2021/12/15/Rails-7-fulfilling-a-visi... In particular there's a theme of JS being totally optional: "Rails 7 takes advantage of all of these advances to deliver a no-Node default approach to the front end – without sacrificing neither access to npm packages nor modern JavaScript in the process." "The same approach is taken with CSS bundlers that rely on Node. [...] If you’re willing to accept the complexity of a Node dependency, you can pre-configure your new Rails app to use any of them" That seems like a smart goal. They're not trying to go it alone, but they're clearly trying to draw some boundaries that keep the JS chaos/complexity at the edges.

bern4444 5y ago
React feels pretty settled now, it's been out for 10+ years, hooks and functional components have become the standard. If you want to learn it I think it's at a mature enough place. Popular libraries like redux have been rebuilt to use hooks and simplify the integration. I'd also check out Remix[0] if you wanted to get into a React framework. It's fairly new but extremely promising and easy to get up and running and even deployed anywhere (express server, cloud flare workers, deno, etc) [0] remix.run
- ozzythecat 5y ago
  The last time I did web development, I used Angular 1.2 or something like that. I had some forms and many different views that talked to some REST APIs. It was never clear to me why/when I would need React. I read and worked through some tutorials years ago, and while the reactive/one way flow pattern was nice, I never had a problem with Angular. I recognize there have been many versions of Angular since then. And there are several web development frameworks, complex build tooling, etc. etc. Meanwhile, I’m still writing services in Java that handle 20,000 requests per second for a service that brings in revenue in the billions of dollars a year. And I’m writing C++ (very straightforward, no templates, few uses of pointers, etc) for cross platform mobile code. I have some Spark pipelines all written in Scala. Meanwhile the web stack continues to evolve… new technologies all just for rendering web pages. I don’t understand why. Admittedly there’s far more complexity in our use cases today than the HTML I was writing in 1999, but much of it is unnecessary bloat from bored developers.

z3t4 5y ago

> and have the same tiring conversations about naming conventions, logging, data consistency, validation, build scripts, etc. Sounds like bike-shedding to me. Eg. You start with solving trivial problems instead of the hard problems. Usually the first thing that is decided is what framework to use, often by a non technical person that herd from a friend that is was good. Rather then having the engineers sit down and think about what are the biggest challenges, and what is the best framework suited to solve the hardest problems.

slingnow 5y ago
OP never once stated that they started with those problems. What makes you think the engineering challenges weren't tackled first?
deleted 5y ago
[deleted]

neximo64 5y ago

This sounds more like you couldn't adapt to more people joining the company. The stack reflects your org structure.

anonGone73 5y ago
Conway's Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure. — Melvin E. Conway

ozzythecat 5y ago

Micro services are usually overkill unless you’re working at a significant scale. For most projects such as corporate apps, it’s just unnecessary. It’s good to start simple and only add complexity when it’s really needed. It’s unfortunate the current trend is to start with massive complexity.

innocentoldguy 5y ago
Excellent advice! I recently worked at a company where the "architect" insisted on using Broadway and Kafka for what should have been basic CRUD operations. He got fired.
- Nextgrid 5y ago
  That's refreshing to see. In a lot of startups he would've been promoted to some high level position, hired dozens of engineers to maintain the new monster and then invited to an AWS conference to brag about how they solve their (self-inflicted) problems, all while the business is bleeding money in cloud bills and engineer salaries.

princevegeta89 5y ago

Right, but a big project in Rails has all the problems you can think of: - slow to compile and run - easy target for spaghetti code - test suites get sluggish - hard to upgrade - won't scale well - with no static typing, large scale collaboration can easily break things - metaprogramming hell

jaredcwhite 5y ago
A big project in any stack has many problems. Vanilla Rails is going to scale way better than some wacky bespoke configuration of stitched-together NPM packages, which in my experience is what a lot of folks build now because they don't know any better.
- princevegeta89 5y ago
  I've successfully run Java/Go projects with huge amounts of code without a lot of degradation in any direction whereas Rails seems to quickly come to a stopping point compared to other platforms. I've written my side project which is now at a huge size in Elixir, I'm yet to see any degradation so far. I'm sure Rails would have been a pain by now. Sorry I don't have much Node experience so can't comment.
  - jaredcwhite 5y ago
    Simply hasn't been my experience at all, and I've worked with numerous Rails projects large and small since 2008. If you prefer Java/Go/Elixir, knock yourself out, but I'm throughly satisfied with Ruby-based solutions.
    - princevegeta89 5y ago
      Got it. It's not impossible but I've been at multiple jobs involving Rails monolithic apps, they all really sucked from a maintenance and development perspective. P.S would have been happier if you had a better choice of words than "knocking myself out".

skohan 5y ago

By contrast, Node was a breath of fresh air for me. With Rails, you had to start with this already complex system and bend it to do what you want. With a greenfield node server, it only does what you tell it to and nothing more. No surprises.

jaredcwhite 5y ago
Building a complex SaaS app or backoffice app on a "greenfield Node server" is a supreme exercise in frustration.
- skohan 5y ago
  There's a tool for every job, but for most of my use-cases, I'd rather have a webserver which is just a webserver, and get my front-end elsewhere. But I'm sure there are places where Rails is a great fit in the right hands. I'm not even using node very much these days. Serverless is what I would reach for for most professional applications these days.
eclat 5y ago
Sinatra covers that use case in Ruby.

p_l 5y ago

Out of those, though, I have to blame document DBs (and the start of NoSQL craze) on Rails :( To cut a long story short, Active Record (especially at the time) wasn't super keen on generating super good SQL that would do as much as possible in database, and Ruby 1.9 arrived with stable ordered hashes. Then someone implemented basic ActiveRecord wrapper on top of key/value store (I think it started with Berkeley DB or similar), and from there NoSQL was off to the races as "new hip thing"[1] [1] Meanwhile IBM IMS has been selling pretty well for last 40 years at the time ;)

tinco 5y ago
I don't fully understand your argument. Document DB's never fully got traction in the Rails community. Then Node.JS became popular because it did concurrent IO better, and it put document DB's front and center for no apparent reason.
- p_l 5y ago
  It didn't get a lot of traction because it required some effort, but essentially the groups that jumped on them were also highly correlated with those that soon jumped to NodeJS, helped along with JSON serialization being rather obvious in JS context Though I would also consider their exodus to be a good thing for Rails ;)
LargeWu 5y ago
ActiveRecord was, even then, a much better ORM than exists in the Node world today. It was full featured and well hardened, and required basically no setup other than a class declaration. Plus, you could always drop down to the SQL if you needed to. Generally, it was a joy to use, and the performance was usually good enough. At some point, I gave up on even trying to use any Node ORM's because they were clunky and offered no value. It was easier to just drop straight to a knex session and write the queries natively.
- kkarimi 5y ago
  You should check what Prisma team has been doing lately

khaledh 5y ago

Because of this unnecessary complxity in the webdev ecosystem, I switched my development career to other areas[^]. If I have to do webdev for a hobby project, I use Django and Postgres, with no JS frameworks whatsoever. It's liberating and fun. [^] Mostly data engineering at work, and low level os/system dev in my spare time.

cutler 5y ago
I hear ya. I perversely yearn for my days with Perl and CGI::Application. When I get up in the morning my eyes just happen to land on a stack of O'Reilly Perl books and it sets me off.

rglover 5y ago

Check out https://github.com/cheatcode/joystick https://github.com/cheatcode/joystick.

brightball 5y ago

I can relate. I was just about ready to exit programming until 2 things came along that removed all the analysis paralysis for me. 1. Elixir + Phoenix 2. TailwindCSS Elixir because you can build a monolith with it and everything is naturally separated by design. The runtime makes it impossible to hurt yourself. It addresses virtually every web use case in an ideal fashion that balances development speed with long term maintenance and scalability because of the language design trade offs. TailwindCSS because it removed the decision about which of the million frontend stacks in should be using. It makes it so easy to do anything I can dream up without feeling like I need to hire somebody to help with a pet project. And honestly, even though I like DevOps and database work just using Heroku/Fly/Gigalixir so I don’t have to worry about it makes my life easier.

fouc 5y ago
Elixir & Phoenix comes across as a "full-stack" framework with tons of potential, much more so than Ruby on Rails.
- sam0x17 5y ago
  I agree that Elixir & Phoenix are the natural evolution in a post-Rails world, but looking further ahead, I think we've reached a point where the compiled & typed languages are starting to have all the goodies that used to be reserved only for the highest of the high level languages, and with web assembly support on the rise, it's going to start to become possible to use languages like this for both backend and frontend in a unified way. So for me, the next natural evolution is using something like Rust or Crystal but with very solid Railsy conventions and intelligent code sharing between frontend and backend. I think this combined with something like the Phoenix live view, but in Rust, is at least where I want my future to be, and I think a workflow like this could become the dominant pattern before, say, Elixir/Phoenix overtakes Rails. I tip my hat though to people diving into Elixir --- it is definitely a cool direction and one I would follow if I weren't already so sold on Rust/Crystal/etc.
  - montblanc 5y ago

pulse7 5y ago

I like monoliths... which are modular inside... no need for microservices, easy deployment even without Docker and Kubernetes... just a single binary...

tamersalama 5y ago

> I ended up spending more time on tooling setup than actual business logic. This is exactly why, in 2004, I moved from Java (Struts/Spring/Websphere/XML/...) to Rails. History repeats but we never learn. Kudos to Rails for remaining relevant.

"the popular tech stack shifted": this says it all. Choice of a stack shouldn't be about popularity but rather about meeting the cultural,organizational,functional and non functional requirements of the solution. I said it already and I will continue saying it: our industry is driven more by fashion rather than good engineering practices. Every new trend solves a problem of the old generation but also introduces additional costs and new trade-offs. Adopting something blindly is not a good engineering approach. Software engineering is the art of balancing carefully your trade-offs and not to go with the latest fashion.

iamphilrae 5y ago

Ditto for me except swap RoR for PHP monoliths. Gone are the days where my only cognitive overhead was deciding between Less or Sass and CodeIgniter or “the fancy new” Laravel. Likewise I got fed up of where dev was going in the workplace, and moved into a Solution Architecture / Product Manager role. I still get a lot of satisfaction creating side projects in the tools of old (which IMHO work much nicer than 95% of “modern” applications), but thinking about doing development in my day job would give me a headache from the outset.