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.
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.
Is AWS lambda really cost effective? It has been many years since I was part of a team that was assessing AWS Lambda as _workers_ but the resource limitations at the time alongside cost calculation made PHP+VMs the cost-effective choice by orders of magnitude.
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?
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.
I'm in exactly the same boat, and hoping that others follow suit. It feels like "the good old days", but the community is still small and resources are scattered, so sometimes doing simple things mean a bit of trial and error at first. Still, it's actually been enjoyable again.
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-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.
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)
Yea, I'm really glad they dropped Webpacker. It was the worst "Webpack abstraction" I've had to deal with, and the only documentation was always out of date and confusing.
I think it's important to be a little careful with the terminology here: JS itself is not optional, really. If you want in on Hotwire and the rest, it's inevitable that it's there.
What's optional is whether you need to use node or npm itself as a developer-facing tool, and needing ESM support in the browser for the way they've done it means it's only relatively recently that that's been practical.
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.
Why do you think it isn't simple to host? If you yearn for the simple times, no one is stopping you from just spinning up a VPS with Ruby, Passenger, Nginx and your favorite database.
Of course the larger your project is, the more hassle, but that's not specific to Rails.
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.
I think it can be simple if you keep it simple :). In my book Deployment from Scratch I show people how to run Rails on a cheap VPS with a couple hundreds lines of Bash.
You're welcome to adapt the AWS deployment scripts I setup for Haven[1]. I tend to adapt them when deploying other personal projects like the sites I've built for my family tree or privately hosting/sharing old family home movies.
Python/Django developer here, but I've found Digital Ocean+Dokku to be a pretty decent cheap alternative with more flexibility than Heroku, especially for an early-stage side project where a single server is enough for your needs.
Take a look at Cloud66. Been using it for every project over the last 10 years or so... It's like Heroku except you can control a lot more and not get locked into "enterprise" pricing when you need to scale or simply don't want to expose your database to the open internet (imagine that).
Check out https://www.hatchbox.io/, it lets you easily host stuff on various hosting platforms (using your own account) with similar ease to Heroku. Which also means it's WAY cheaper. Heroku's pricing has always seemed insane to me.
I think it used to be harder to host than it is now. I think the only thing that might be hard now is sifting through all the tools for hosting and the analysis paralysis that can come with that. Heroku can get pricey at scale, but heroku and others are options that make it dead simple. Then there are a ton of options for how you might want to self-host. There are plenty of guides for getting docker setup with it, opensource heroku-like alternatives (most using docker under the hood), and plenty of resources (maybe too much).
I've had good success on my side-business with Piku: https://piku.github.io
It's essentially a lightweight PaaS that you can run on your own hardware (even ARM)
I have been using a software called dokku for about six years. It‘s like Heroku, but you self host. It even uses the same buildpacks.
You just run the dokku installer and off you go.
If you don't mind hosting on AWS, Elastic Beanstalk is a pretty streamlined way to host Rails apps, and it doesn't cost anything more than the AWS resources you consume.
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.
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.
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.
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.
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.
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".
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.
> 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.
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.
I knew a few people at university, who were pretty hyped about it. That was in 2008, I think. They used it at some companies where they jobbed and found it too limiting.
I was building customized stuff with bare PHP in those days and found it quite flexible. Later, the Rails hype came to PHP, but I already left for Node.js and never looked back.
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 ;)
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.
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.
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.
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?
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.
Ruby's has been startups—Stripe, Coinbase, Instacart, Teespring, Podia, Twitch, Gitlab, Github, etc... despite never having been the most popular language or even close, it's been absolutely dominant as an initial back-end language for top-tier startups.
>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?
In the web server side, helping you build web apps faster. That has been it's niche (with Rails) and it's still doing well there.
> Python already exists as a dynamically-typed server language.
Ruby isn't new; it's only slightly younger than Python, and brought things to the table. Rails and Django are roughly the same age (and Django started off more as a CMS). That Python exists isn't an argument against Ruby. Lots of other languages exist, each with their own cost/benefit tradeoffs.
> [...] writing server-side web stuff in JS does make sense given it's what you're using in the client.
I don't understand the argument. Matching client/server language is a different goal than matching task/language, and the task isn't the only driving factor.
There's some crossover in that the language is the same, which means you could standardize on JS developers, but the ecosystems are not the same, and the required overall skillset is different. In wee shops the tradeoff may be worth it, but at scale, the benefit is oversold.
> JS does make sense given it's what you're using in the client.
Well JS is forced upon us on the browser and not everyone is tremendously happy about it. It has improved, but still. Plenty of folks out there will seek other languages, we will never all fully agree on what's good on the backend.
BTW - are we positive JS will have a monopoly on browsers 5-10 years from now? (I'm talking about WebAssembly). Cos if the monopoly is gone JS will die a violent death I think.
Ruby captured a lot of webdev market before python became mainstream, and you can see it in the maturity of the tools around this domain (ruby's way more evolved). The tables turned because python became the de-facto ML language, and everyone and your engineering manager will be afraid of betting on anything other than python in fear of hampering future ML-based optimizations (which is in practice utterly wrong, but try tell that to management...)
"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.
> 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.
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.
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.
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.
> 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.
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.
“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.
I like monoliths... which are modular inside... no need for microservices, easy deployment even without Docker and Kubernetes... just a single binary...
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.
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.
Have you tried implementing a well structured and well developed migration system for node? How about a unified folder structure, best practices and patterns? Scheduled cron jobs? Templating and asset bundling? All of this came with Rails out of the box with sane defaults.
I guess I should be thankful re-inventing the wheel on all of these aspects in node has given me hundreds if not thousands of hours in compensation.
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.
I have spent a lot of time with node(express), Java(Spring) and rails. I see a lot of complaints about node, but node with typescript has been a joy to work with. It is lightweight and has a type system. I know where every piece of code is coming from, there is no magic involved. I either wrote the function in that file, I am importing it, or it is a method on a js object. I only have know one language for both front end and back end. A better standard library would be nice.
Rails is nice in terms of getting the project set up, not bikeshedding about the tooling, and working with the db. But the actual coding has been painful for me. I really dislike working with a non typed language. I dislike optional parans in function calls and optional braces for hashes. I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base. I would rather write a bit more code for a bit more clarity. Maybe if python were typed I would like Django? But python has all of that nonsense around virtualenv.
Spring has been ok, but not great. Too much bloated abstract factory creator nonsense. Dependency injection never really clicked for me. All of these annotations. I quite liked plain Java but Spring just felt like this monster.
All in all node(express) has been the nicest for me.
> I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base.
This is also my only complaint with Rails.
I'm a programmer, not a wizard, and I'm not good at magic.
I understand the "too much Magic" criticism of Rails from novices & intermediate Rails developers, but once you reach a sufficient level of mastery, I think this goes away.
After using Rails every day for 12 years I know pretty much all the ins and outs, and what is "magic" to others is just the robust tooling I love. Just like any tools, they are overwhelming and daunting when you don't know how to use them, but once you become proficient with them, they make your life so much easier. While it might be difficult when the "magic" doesn't do exactly what you want for your edge case, when you have a sufficient level of mastery, it's easy to find a way to adapt/modify/override the tooling and make it do what you want. Further, many times the tooling is there to keep you from doing things you probably should not be doing, and this kind of strict, opinionated, best practice enforcing philosophy has gotten me out of trouble at times, and I think it makes it much easier for engineers to move between Rails codebases and start being productive even faster.
I've done plenty of Node/JS/React and I honestly do not understand how people can prefer to use these stacks over Rails. For full stack web dev, Rails is such a pleasant place to work every day.
I never really understood the criticism about "magic" in Rails.
We are surrounded by magic (which only means things we can not realistically be bothered to take the time to really understand, in contrast to things which are incomprehensible). I have no real clue why the terminal works. I have no real clue why my OS works. I have no real idea how TCP/IP does its thing. Sure, I can use them – but I couldn't really explain and much less recreate them.
What I need in all the above is replicability. I do x, and I know y is going to happen. Get x, do y. This is true in Rails.
If I really wanna know more Rails is open and easily explorable. No one is preventing me from finding out how any piece of the "magic" works.
"Magic" class inheritance is a thing in JS as much as it is in Rails.
Express isn't really like Spring, Rails or Django. Express is very simple and may be good for someone learning the basics, but how is a novice web developer supposed to know what is missing? There concerns from security, authorization, sessions, and many more that Express doesn't handle out-of-the-box.
> ... how is a novice web developer supposed to know what is missing?
That is a great question. Is it the job of the tooling to prevent a novice developer from shooting themselves in their foot? Do we need higher-level abstractions in our frameworks that are analogous to memory safety in programming languages? Perhaps.
Alternatively, I don't think that security practices are particularly hidden. Anyone who's used the web knows has used a login form. I would give most novice developers the benefit of the doubt that they're going to be curious and look into that.
I would argue that it is, in part, their responsibility to learn these things. It's our responsibility perhaps as stewards of the secure web to teach and enforce best practices. I don't think baking in these best practices into frameworks does these developers any favors, except that it allows them to focus on something else.
I often think of languages like Haskell that could offer the clarity and expressiveness and the static types I want, but the developer experience and killer software (react, phoenix, rails) has just never been there.
TypeScript to me is the compromise I'm willing to settle on. It is also lackluster from many aspects but day by day it gets a bit easier.
If you haven't already found it, you should look into IHP (https://ihp.digitallyinduced.com/). It aims to build the convenience of Rails on top of Haskell's powerful type system. I've not yet built anything serious in it, but I've been following its progress, and it's looking really good so far.
Im a noob starting a project in Spring and I get lost in the jargon. I find that all the Spring knowledge I’ve gathered is to know what is NOT written in the code that Spring is doing for me.
In other words, feels like knowing Spring is being able to read between the lines and placing annotations more than building with it. Which is fine, but it’s easy to get lost when starting out.
It’s also for me to find help since the community seems much smaller and none of my friends are interested in helping out because they don’t want to learn Spring.
Yeah, Spring is incredibly 'magic' heavy. Works great when you know the exact right annotation incantation, but it's a pain to actually understand what's going on.
I've found the official documentation to be very detailed, so it's helpful if you really need in-depth knowledge, but if you don't it's a bit hard to parse out the relevant bits. Copying something from the official guides seems often the easiest way...
In regards to the community, I didn't find it to be much smaller? The stack overflow tag is very active. I have the same experience that nobody I know wants to learn Spring out of their own volition though.
I can't vouch for them, but it looks like they're being actively developed.
I like the idea of full-stack JavaScript (or TypeScript), but last time I tried to use Node for a back end, I couldn't find anything that compared to libraries/frameworks like Django, Rails, SQLAlchemy, etc.
We're using django-stubs and we've been pretty happy with it. We've started the project with it, which was fairly simple. There's one or two model field types that are not supported but those can be skipped. We're using pre-commit to run mypy, this makes sure that we never commit a state that isn't type-checked.
Idk if its just me but I find the testing frameworks for expressJS to be _awful_ -- chai and mocha work great but throw in sinon and its like pulling teeth.
The lack of good documentation is painful and often treats me like I don't already know the concepts involve.
Sequelize isn't as intuitive as Django's ORM either imo.
Let me assure you, there is 0 magic in Rails. Just because something is available to you via a convention doesn't mean there's magic, it means you haven't read the docs and don't understand the convention.
Couldn't disagree more, but I think you're taking the term "magic" too literally.
There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.
Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.
Everytime you see something you don't know where it's coming from, it's magic. Every time I interacted with Rais ive seen it, you have to know that some file somewhere registered or autoloader something else, etc. You don't see the imports to find it, you have to grep the repo instead and sort through all the matches.
Same experience with a medium sized Rails project here. I joyfully ejected after several months, I needed a detox from the untyped mess, every singe library was different, there were no coherent apis/interfaces at all. All Rails patterns were replaced with some random "smarter" counterparts, dry-rb here, some "better" orm developed in a shack there, all glued together. I recognized it's not the issue with Rails per se, it's the Ruby devs culture and I'm not compatible with it (even though the team was quite good, just a lot of cruft to deal with).
This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.
Other Ruby "features" that I dislike:
1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
3. Out of bounds indexes on Arrays/Maps return nil.
4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.
> Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
Well, Ruby has functions, they're just called Procs. Lambdas are a special, more strict breed of Procs, and blocks are just (pretty complex) syntax sugar for passing a Proc to a method. The main function-like concept is always a Proc.
> Out of bounds indexes on Arrays/Maps return nil.
Calling the #[] or #slice method on an Array with an out-of bound index returns nil, calling the #fetch method raises an IndexError or returns an arbitrary default value. You can use whichever suits the situation.
Ruby on Rails is awesome to write, horrible to maintain. It’s the fastest way to build a web app but good luck with staying productive once you have 100 engineers working on it and a million lines of rails soup to wrangle.
So its been a while since I used Rails but when I did I enjoyed it. In particular, say what you will about DHH I think having a fairly "opinionated view" on how the framework should function makes it much easier to deal with. Every time I need to do something full stack with Node I feel I need to go back and figure out what the current state of ORM's are.
However the reason I don't use Rails as much is that I'm not writing a lot of "full-stack" apps. A lot of the work these days is gluing together various SaaS services. Okta/Firebase for Auth, Contentful for CMS, Stripe + Webhooks for Commerce etc. I just don't do anywhere near as much "CRUD" style programming as I used to do earlier in my career, which is both a comment on my career and the state of programming today.
I'd love to see a project that wraps up a bunch of best-of-breed technologies and creates a full framework and doesn't try to be all things to all people. ie React for Front-End, Bookshelf ORM, Express Server etc (pick your favorites, but have an opinion that evolves but only in one direction.
DI/IoC is a separate thing from the ecosystem; the benefits are just as strong in JS or Ruby--it's just that in JS/Ruby some of the benefits aren't as noticeable because of language malleability and openness.
Prediction: the big move in the next few years is going to be "back to hypermedia"
People are realizing that you can accomplish quite a bit more with hypermedia than you could in the past, and that the complexity of javascript stacks isn't worth it in many cases.
Older, mature hypermedia-based technologies like rails, django, and even PHP, will experience a resurgence and a lot of older lessons and techniques in web development (caching, SQL tuning, etc.) will be rediscovered.
I have a dog in this fight, w/ htmx, but I think we are increasingly seeing evidence for this move.
The biggest CMS of one of the biggest languages is moving away from the approach you call hypermedia by implementing a JS-based editor and REST apis. Effectively they are building a headless version on top of their legacy platform, which can be used like a JavaScript stack.
This can be used as an argument for the hypermedia approach: "Let's just use this thing for now, we can always implement our SPA inside it later, if we need to."
>Older, mature hypermedia-based technologies like rails, django, and even PHP
Not sure what you refer to as hypermedia.
In the first part of your comment I assumed something like a new version of Flash. Here you seem to simply imply http/hypertext.
But then again, those technologies where never lost (to need to be rediscovered). They're as popular as ever, people just add more stuff on top, at the client JS layer.
If we see a return to "hypermedia" it won't be wholesale, but rather in the form of a static site generator that does the 80% work and is easy to extend the rest of the way. Something somewhere between Svelte and Gatsby. The react component model and JSX style bracketed DSLs both have a lot of traction, the main issue is the amount of groundwork and glue needed to do simple things with them.
i think it will rather be in non-javascript technologies with strong existing hypermedia infrastructure again, like rails, django, etc
the front-end component model is anti-RESTful and is really a mechanism for handling the complexity of the current client-server approach, it becomes significantly less important as hypermedia is re-embraced
I think requirements have generally shifted quite bit from what plain html can do, if that's what you mean with "hypermedia". Though true, there's probably a growing understanding that one doesn't need React on every website. So maybe it'll rather be more refined understanding of when to use certain technologies.
Yeah it's funny... Now 10 years+ in the web dev business. I occasionally got drawn by the hype, dug myself considerably deep into express based frameworks, sails.js, koa.js, nest.js... But in the end i had to conclude, my first go-to framework django always came out superior in terms of developer productivity. It even eventually covered the bases where i still thought node was superior like async/websocket communication. Imho Django and similar batteries-included frameworks are as state-of-the-art as they've ever been.
Especially if you couple it with HTMX / Alpine.js you get a really good stack that covers all the dynamic page updates people are getting used to, without adopting massive frameworks.
I just started with HTMX and so far I think it's really promising. Similar things happening with Rails and Hotwire.
It took a while for these frameworks to accept that JS and the frontend are also important aspects of the stacks, and hard to avoid if you want to build modern applications. But now that they're picking up, heavy JS frameworks start making less sense.
At my first job we were migrating from Coldfusion to Java. This Middle Aged Sri Lankan guy refused and only worked on ASP.NET. Much respect to him! He knew what he was comfortable with - and most likely looked at Java in disgust the same way Java folk would look at ASP.NET :P
I've said this before on here, but the Rails philosophy really clicks with me. Working with Rails is just more fun than with any other language/framework, especially JavaScript. I understand that this is subjective, but it's good that different choices, including Rails, exist.
PHP clicked with me for 15 years. I was extremely reluctant to use Node/Express because it required me to be more nuts-and-boltsy, I liked how PHP just did everything (like multi file uploads from forms). What one me over about node was that PHP never forced me to develop with module patterns, it was just brute force, spray code everywhere and walk away (we all did that, actually, which made support a nightmare). It also came with robust CI/CD testing (Jest is a big deal once you get over the step-function). Perhaps PHP has all of this integration and testing, but I'm so into node now that I don't really want to go back.
And I see very little reason to pick Rails over PHP over Django over Node!
Whatever works for your team is what matters. I bet you could find a Fortune 500 company that uses any one (or all) of those.
I can't speak to PHP, but I can speak to the others.
Node's easy, as it's technology, not a framework, so you'd pick Rails over it if you wanted a lot out of the box. JS also "thinks" differently than Ruby (callbacks, and now async, pretty much everywhere). PS - If you haven't played with lots of curried functions in JS, it's fantastic (IMHO).
If I wanted a more same-same comparison, the choice is between Sinatra and Node, and IMHO that's a lot more even (and for me, broken by one of them being in Ruby ;) )
Django's more subjective, but my experience with it was very not-great. There's a lot of decisions in Django that look good on the surface (apps, for example) that then don't pan out (apps all end up blurred together, for example). Particularly compared to Rails, I found Django waaay more boiler-plate and frictiony (particularly the migrations), but that's fitting for a language (Python) that's actually more lower-level than expected. Python (and Django) are opinionated where Ruby (and Rails) are welcoming, IMHO.
Just to throw my hat in the ring, Currently CTO /founding engineer of health tech company that runs a Rails backend that serves about 150QPS.
I hear over and over that rails doesn’t “scale”.
Performance wise, we have never had a problem scaling rails itself. The issues were always at the database level. Most slow endpoints (1.5s+) are 10% Ruby, 90% Postgres.
Even if Ruby was magically infinitely fast, these endpoints would go from 1.5s -> 1.35s.
Optimizing data infrastructure gets 10x returns compared to the application code.
Maintenance wise, it’s a bit harder, Rails loves to put everything in the global namespace. This comes down to your team being conscious of properly namespacing different logical parts of your app.
Having built a Rails app with my team that handles ~76k rpm on peak days (99% of responses within 90ms), I've learned that you scale your architecture, not your framework. Rails is just fine.
Agreed. Scaling application servers is "easy" since they can be scaled horizontally; in other words, you can just throw more hardware at the problem. Scaling databases is "hard" because of CAP/PACELC-type issues in maintaining consistency, and because some DBs (like Postgres) don't have good support for horizontal scaling.
I’ve found DDD’s insistence that cross-aggregate aggregation be done through IDs to be helpful here. It makes transitioning to other persistence implementations easier.
Preach! I do not understand this criticism at all. Rails scales just fine, in a web app it's the DB that's the bottleneck 99% of the time. Sure, the ORM can get you into hot water easily if you do dumb things (or just don't pay enough attention to N+1's etc), but one should be using the ORM wisely and deliberately, rather than living ignorantly of what's happening behind the scenes.
Anyone have any recommendations for books or resources to look at when scaling a rails app beyond a single database, or when your app starts to move into the realm of "big data"?
You can "componentize" various parts of Rails and make it less of a monolith by using Rails engines.
I do it by having a new folder "components" on the Rails root and adding `gem 'name_of_component', path: 'components/name_of_component'` which looks like a vendored gem.
Rails engines has the ability to "isolate_namespace" which is I think the default for a new engine. This is where you can avoid global name spacing issues where each component can be thought of separately. Effectively, you have something _kinda_ like a microservice but it runs as a monolith. And if you need you can have each component depend on others so long as you don't wind up in a loop.
Note: I have a component "common_models" which is just for commonly used items across various components. The main app should have nothing in it's Rails.root/app since you instead have components.
I'm not related to this but here's a basic idea: https://cbra.info . (Pretty sure the author of this page made the Railsconf talk that inspired me to move to this years ago.)
My takeaway from this is that it’s extraordinarily important to try different tech stacks.
I’ve primarily worked as a Java dev for the past 20 years, but I’ve got significant time doing python and one non-trivial Rails app.
The funny thing is I’m most comfortable and I believe most productive in the Java ecosystem, but only because of the time spent working in other languages. Coming back to Java after python, one gets a better feel for what’s essential and what’s cruft. Similarly, when Rails first came out, it can’t be understated how revolutionary it was with respect to web development. Coming from the J2EE universe it was like the true essence of web development had been hidden from us with servlets, JSPs, wars and ears.
That being said - I’m happy being a Java - well JVM at least - developer. The ecosystem is alway changing and often improving, but I assure you it wouldn’t if not for the evolutionary pressures of things like JS & Node, Ruby & Rails and Python & Django.
I'm in a similar boat to you - I've built non-trivial side projects in other tech stacks, but I'm a JVM developer at heart. I've been conflicted about whether to dig into ruby/rails more to jump ship recently because of the philosophy in the community.
I love kotlin as a language and enjoy working with spring boot but the hype in the JVM community around JSON API + React SPA does make me wonder whether I'm moving away from it philosophically.
I'm particularly excited by Spring Native right now. Having a Spring Boot app startup quickly and use less memory will fit heroku-like PaaS environments perfectly.
Same boat as both of you guys I find myself in this weird world of loving Go's simplicity, loving Rails get shit done mentality + community and Java reliability (but SpringBoot makes me sad).
I'm glad I ventured out of my Java only mindset however. Lots of interesting things going on but decision paralysis sucks.
The Java space though unloved but the younger crowd is still super strong and Spring Boot gives all those competing platforms a run for their money leveraging the enormous JVM ecosystem. Java may not be the most concise of languages but I think many people would be surprised by how little boilerplate there is in modern Java and Spring.
Spring is pretty lean as long as your use case is typical and common - you can practically setup most of the foundation just via config. However, anytime you have to deviate from the typical, the complexity of the Spring framework underneath starts to show and the beans and boilerplate start to grow pretty fast - not unmanageable but not exactly lean either. Fully agree about the ecosystem.
> Coming from the J2EE universe it was like the true essence of web development had been hidden from us with servlets, JSPs, wars and ears.
20 years ago, Java development wasn't that complicated. Big consultancy came in and complexified the ecoystem just for the sake making the entry level way too high. A Rails developer only needs to know Rails and Active record and maybe Capistrano and some server.
A Java developer has to know Servlets, Glassfish, Tomcat and other containers, JSP,JNDI,EL, JSTL, JSF, JDBC, JPA, CDI, EJB, Hibernate, Spring, Maven, Gradle and God knows what to find a job.
For a beginner, the documentation is also all over the place. Java the language is improving sure, but some people are still stuck with maintaining struts applications to this day, with tons of XML files...
Just reading these make me depressed. I'm taking over a JSF project that uses gradle these months which puts even the complicated old spaghetti gulp build files to shame in terms of complexity.
Even more confusing is that there are some people who love that complexity. They are actually proud of it! Why would you have a globel gradle file in your $HOME that has project specific configuration? Why does your stupid project only run with some specific Eclipse plugins? Why does it take 2 days of depressing configuration work to have a running instance? I used to love Java! What happened when I wasn't looking!? They tell me "but you do it once!!", I digress.
The cool think about rails is not just that you don’t have to take care of the “pluming” (you get that from any halfway decent framework and could stick with JavaScript and nestjs for example to get that benefit) but the libraries that exist to get you going quickly for login, third party apis and so on. That is the bigger benefit of rails.
In other languages there might be multiple frameworks and multiple libs all of which might do none of just part of what you need and if you find a lib you might not find an integration into your framework and need to build that yourself.
Rails was so big and the community was/is cooperative enough that you usually get fewer libs that are more complete and more likely to fit you needs and come with rails integration.
No need to test 10 or more libs to find out all of them sort of suck and then do it yourself or chose the least sucky one and integrate it yourself. THAT is what maid Rails productive and at times frustrating (you often only deep dive the components once something goes wrong).
Long term it will be interesting to see how many companies run with setups that are Node.js heavy in comparison to not just Rails but also Python, PHP and even Java, .NET and Perl (yes old but not dead).
Perl was one of the early languages and I don’t think there will be as many projects in it as there are in PHP. Python has a good amount of stuff and they didn’t really have a time of heavy hype (like PHP, Ruby on Rails or Node.js enjoyed) and Java and .NET are going to be more heavily traditional corporate than the rest.
Would be nice if somebody knows a link or two to explore this a little bit better.
Yup, but there is more. I think overall we as a community appear to show good taste in what we do (this is opinionated) and if we do something it tries to be as complete as possible.
When I think of all the half backed JS projects I’ve looked at when searching for a solution and compare that with Ruby, there is a difference.
Nest.js really helps to put a solid structure around Node.js/Express.js projects . I have found the teams much more productive, with strict conventions to help them build solid and scalable backend platforms.
As you mentioned, the Node.js ecosystem is full of specialised libraries to achieve typical use cases such as authentication/authorisation, ORM/persistence, etc. The Nest.js documentation is a great reference as they include a list of recipes for all those common scenarios and how to implement them in a Nest.js backend.
I don't think I've ever had a great ORM experience with node. I inherited a project that was nest + typeorm. I've found nest pretty pleasant but typeorm is buggy and was generating way to many queries for stuff.
Readit News
I eventually gave up and switched to a semi-technical product management role.
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.
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?
Deleted Comment
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.
But I feel no typesystem would bite me in bigger project.
Deleted Comment
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.
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
What's optional is whether you need to use node or npm itself as a developer-facing tool, and needing ESM support in the browser for the way they've done it means it's only relatively recently that that's been practical.
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.
Of course the larger your project is, the more hassle, but that's not specific to Rails.
I think it can be simple if you keep it simple :). In my book Deployment from Scratch I show people how to run Rails on a cheap VPS with a couple hundreds lines of Bash.
Just Ruby + chruby + Puma + systemd (and optional systemd socket activation).
I include a scripted demo (so you don't have to do it yourself) which demonstrates all of the this:
- Setting up a git-pust deployment for Ruby applications
- Using chruby to automate installing requested Ruby versions
- Configuring NGINX as a proxy using UNIX sockets
- Setting up systemd socket activation for graceful restarts
- Configuring NGINX to serve static assets
- Configuring NGINX to proxy WebSockets connections for Action Cable
- Automatic SSL/TLS certificates with Let's Encrypt
- Redirecting HTTP traffic and subdomains to main domain over HTTPS
- Running PostgreSQL and Redis on the same server
- Building a custom SELinux module
- Configuring firewall
- Setting up automatic weekly system update
- Setting up log rotation for NGINX and PostgreSQL logs and max limit for system log
- Doing application backups and restores
- Creating admin tasks
Although it sounds like a lot, the demo is reasonably small and clean so you can go through all the files in 2 hours.
I think people many times complicate what they don't need to complicate...
[1]: https://github.com/havenweb/haven/tree/master/deploymentscri...
And it's great!
Hatchbox takes the maintenance and setup out of DevOps for me!
Using Hatchbox makes it easier to treat servers like cattle and less like pets!
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.
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".
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.
He got fired.
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.
- 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
Really?
https://twitter.com/ShopifyEng/status/1465806691543531525
Github is in Rails. I mean, seems like it scales just fine.
I knew a few people at university, who were pretty hyped about it. That was in 2008, I think. They used it at some companies where they jobbed and found it too limiting.
I was building customized stuff with bare PHP in those days and found it quite flexible. Later, the Rails hype came to PHP, but I already left for Node.js and never looked back.
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 ;)
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.
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.
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?
https://twitter.com/logicmason/status/1371255029412233218
In the web server side, helping you build web apps faster. That has been it's niche (with Rails) and it's still doing well there.
Ruby isn't new; it's only slightly younger than Python, and brought things to the table. Rails and Django are roughly the same age (and Django started off more as a CMS). That Python exists isn't an argument against Ruby. Lots of other languages exist, each with their own cost/benefit tradeoffs.
> [...] writing server-side web stuff in JS does make sense given it's what you're using in the client.
I don't understand the argument. Matching client/server language is a different goal than matching task/language, and the task isn't the only driving factor.
There's some crossover in that the language is the same, which means you could standardize on JS developers, but the ecosystems are not the same, and the required overall skillset is different. In wee shops the tradeoff may be worth it, but at scale, the benefit is oversold.
Well JS is forced upon us on the browser and not everyone is tremendously happy about it. It has improved, but still. Plenty of folks out there will seek other languages, we will never all fully agree on what's good on the backend.
BTW - are we positive JS will have a monopoly on browsers 5-10 years from now? (I'm talking about WebAssembly). Cos if the monopoly is gone JS will die a violent death I think.
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.
Deleted Comment
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
[^] Mostly data engineering at work, and low level os/system dev in my spare time.
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.
Dead Comment
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.
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.
I guess I should be thankful re-inventing the wheel on all of these aspects in node has given me hundreds if not thousands of hours in compensation.
Never understimate the power of fad, tech pop culture, hype, and trying a shiny new thing...
It’s just me building this and I have no one in my circle that’s familiar with spring.
Rails is nice in terms of getting the project set up, not bikeshedding about the tooling, and working with the db. But the actual coding has been painful for me. I really dislike working with a non typed language. I dislike optional parans in function calls and optional braces for hashes. I dislike all the magic of rails. I never know what is going on because there is some functionality that inherits from a rails class or some other part of the code base. I would rather write a bit more code for a bit more clarity. Maybe if python were typed I would like Django? But python has all of that nonsense around virtualenv.
Spring has been ok, but not great. Too much bloated abstract factory creator nonsense. Dependency injection never really clicked for me. All of these annotations. I quite liked plain Java but Spring just felt like this monster.
All in all node(express) has been the nicest for me.
This is also my only complaint with Rails.
I'm a programmer, not a wizard, and I'm not good at magic.
After using Rails every day for 12 years I know pretty much all the ins and outs, and what is "magic" to others is just the robust tooling I love. Just like any tools, they are overwhelming and daunting when you don't know how to use them, but once you become proficient with them, they make your life so much easier. While it might be difficult when the "magic" doesn't do exactly what you want for your edge case, when you have a sufficient level of mastery, it's easy to find a way to adapt/modify/override the tooling and make it do what you want. Further, many times the tooling is there to keep you from doing things you probably should not be doing, and this kind of strict, opinionated, best practice enforcing philosophy has gotten me out of trouble at times, and I think it makes it much easier for engineers to move between Rails codebases and start being productive even faster.
I've done plenty of Node/JS/React and I honestly do not understand how people can prefer to use these stacks over Rails. For full stack web dev, Rails is such a pleasant place to work every day.
We are surrounded by magic (which only means things we can not realistically be bothered to take the time to really understand, in contrast to things which are incomprehensible). I have no real clue why the terminal works. I have no real clue why my OS works. I have no real idea how TCP/IP does its thing. Sure, I can use them – but I couldn't really explain and much less recreate them.
What I need in all the above is replicability. I do x, and I know y is going to happen. Get x, do y. This is true in Rails.
If I really wanna know more Rails is open and easily explorable. No one is preventing me from finding out how any piece of the "magic" works.
"Magic" class inheritance is a thing in JS as much as it is in Rails.
What is so special about Rails and "magic"?
In express there are packages for those things, ie https://www.npmjs.com/package/express-session. Agree it would have been nice as part of the express library.
That is a great question. Is it the job of the tooling to prevent a novice developer from shooting themselves in their foot? Do we need higher-level abstractions in our frameworks that are analogous to memory safety in programming languages? Perhaps.
Alternatively, I don't think that security practices are particularly hidden. Anyone who's used the web knows has used a login form. I would give most novice developers the benefit of the doubt that they're going to be curious and look into that.
I would argue that it is, in part, their responsibility to learn these things. It's our responsibility perhaps as stewards of the secure web to teach and enforce best practices. I don't think baking in these best practices into frameworks does these developers any favors, except that it allows them to focus on something else.
TypeScript to me is the compromise I'm willing to settle on. It is also lackluster from many aspects but day by day it gets a bit easier.
Im a noob starting a project in Spring and I get lost in the jargon. I find that all the Spring knowledge I’ve gathered is to know what is NOT written in the code that Spring is doing for me.
In other words, feels like knowing Spring is being able to read between the lines and placing annotations more than building with it. Which is fine, but it’s easy to get lost when starting out.
It’s also for me to find help since the community seems much smaller and none of my friends are interested in helping out because they don’t want to learn Spring.
I've found the official documentation to be very detailed, so it's helpful if you really need in-depth knowledge, but if you don't it's a bit hard to parse out the relevant bits. Copying something from the official guides seems often the easiest way...
In regards to the community, I didn't find it to be much smaller? The stack overflow tag is very active. I have the same experience that nobody I know wants to learn Spring out of their own volition though.
Types can be checked with mypy: http://www.mypy-lang.org/
For Django, there are these two typing packages:
- https://pypi.org/project/django-stubs
- https://pypi.org/project/django-types
I can't vouch for them, but it looks like they're being actively developed.
I like the idea of full-stack JavaScript (or TypeScript), but last time I tried to use Node for a back end, I couldn't find anything that compared to libraries/frameworks like Django, Rails, SQLAlchemy, etc.
The lack of good documentation is painful and often treats me like I don't already know the concepts involve.
Sequelize isn't as intuitive as Django's ORM either imo.
Let me assure you, there is 0 magic in Rails. Just because something is available to you via a convention doesn't mean there's magic, it means you haven't read the docs and don't understand the convention.
There is a ton of magic in Rails. It consists primarily of magic. I've been doing Rails since <1yr of introduction (Ruby for longer than that, and Lisp for longer than either). I'm very familiar with metaprogramming. Metaprogramming fits the canonical definition of magic in this context.
Ruby, and Rails, also makes it very easy, and seductive, to add more magic. This is powerful, but dangerous. Like Lisp macros. Understanding the magic is not just a matter of "understanding the conventions" and reading the docs.
This is my #2 problem with Ruby, and it's also the reason why a lot of folk love it. I think of macros in the same way I think of RegEx, if you're writing one you better hope it works perfectly because chances are that you'll be the only one to maintain it.
Other Ruby "features" that I dislike:
1. Blocks + Procs + Lambdas are all function-adjacent. Can't we just call them functions?
3. Out of bounds indexes on Arrays/Maps return nil.
4. method_missing() is super cool and super abusive. Again it feels like magic when functions come from nothing.
Well, Ruby has functions, they're just called Procs. Lambdas are a special, more strict breed of Procs, and blocks are just (pretty complex) syntax sugar for passing a Proc to a method. The main function-like concept is always a Proc.
> Out of bounds indexes on Arrays/Maps return nil.
Calling the #[] or #slice method on an Array with an out-of bound index returns nil, calling the #fetch method raises an IndexError or returns an arbitrary default value. You can use whichever suits the situation.
However the reason I don't use Rails as much is that I'm not writing a lot of "full-stack" apps. A lot of the work these days is gluing together various SaaS services. Okta/Firebase for Auth, Contentful for CMS, Stripe + Webhooks for Commerce etc. I just don't do anywhere near as much "CRUD" style programming as I used to do earlier in my career, which is both a comment on my career and the state of programming today.
I'd love to see a project that wraps up a bunch of best-of-breed technologies and creates a full framework and doesn't try to be all things to all people. ie React for Front-End, Bookshelf ORM, Express Server etc (pick your favorites, but have an opinion that evolves but only in one direction.
People are realizing that you can accomplish quite a bit more with hypermedia than you could in the past, and that the complexity of javascript stacks isn't worth it in many cases.
Older, mature hypermedia-based technologies like rails, django, and even PHP, will experience a resurgence and a lot of older lessons and techniques in web development (caching, SQL tuning, etc.) will be rediscovered.
I have a dog in this fight, w/ htmx, but I think we are increasingly seeing evidence for this move.
The biggest CMS of one of the biggest languages is moving away from the approach you call hypermedia by implementing a JS-based editor and REST apis. Effectively they are building a headless version on top of their legacy platform, which can be used like a JavaScript stack.
This can be used as an argument for the hypermedia approach: "Let's just use this thing for now, we can always implement our SPA inside it later, if we need to."
Which CMS is this?
Not sure what you refer to as hypermedia.
In the first part of your comment I assumed something like a new version of Flash. Here you seem to simply imply http/hypertext.
But then again, those technologies where never lost (to need to be rediscovered). They're as popular as ever, people just add more stuff on top, at the client JS layer.
i think it will rather be in non-javascript technologies with strong existing hypermedia infrastructure again, like rails, django, etc
the front-end component model is anti-RESTful and is really a mechanism for handling the complexity of the current client-server approach, it becomes significantly less important as hypermedia is re-embraced
At some point, stuff needs to be maintained. You can still start and drive that 1967 car, after all.
I just started with HTMX and so far I think it's really promising. Similar things happening with Rails and Hotwire.
It took a while for these frameworks to accept that JS and the frontend are also important aspects of the stacks, and hard to avoid if you want to build modern applications. But now that they're picking up, heavy JS frameworks start making less sense.
[0]: https://www.django-unicorn.com/
Dead Comment
Rails is opiniated, and I love that: https://rubyonrails.org/doctrine/
Edit: Oops, looks like the new website they release somehow fudged the doctrine page. Here's the Wayback Machine link: https://web.archive.org/web/20211126010919/https://rubyonrai...
Update: Oh, they changed the link, here you go: https://rubyonrails.org/doctrine/en
And I see very little reason to pick Rails over PHP over Django over Node!
Whatever works for your team is what matters. I bet you could find a Fortune 500 company that uses any one (or all) of those.
Node's easy, as it's technology, not a framework, so you'd pick Rails over it if you wanted a lot out of the box. JS also "thinks" differently than Ruby (callbacks, and now async, pretty much everywhere). PS - If you haven't played with lots of curried functions in JS, it's fantastic (IMHO).
If I wanted a more same-same comparison, the choice is between Sinatra and Node, and IMHO that's a lot more even (and for me, broken by one of them being in Ruby ;) )
Django's more subjective, but my experience with it was very not-great. There's a lot of decisions in Django that look good on the surface (apps, for example) that then don't pan out (apps all end up blurred together, for example). Particularly compared to Rails, I found Django waaay more boiler-plate and frictiony (particularly the migrations), but that's fitting for a language (Python) that's actually more lower-level than expected. Python (and Django) are opinionated where Ruby (and Rails) are welcoming, IMHO.
Deleted Comment
I hear over and over that rails doesn’t “scale”.
Performance wise, we have never had a problem scaling rails itself. The issues were always at the database level. Most slow endpoints (1.5s+) are 10% Ruby, 90% Postgres.
Even if Ruby was magically infinitely fast, these endpoints would go from 1.5s -> 1.35s.
Optimizing data infrastructure gets 10x returns compared to the application code.
Maintenance wise, it’s a bit harder, Rails loves to put everything in the global namespace. This comes down to your team being conscious of properly namespacing different logical parts of your app.
Asking for.... a friend.
I do it by having a new folder "components" on the Rails root and adding `gem 'name_of_component', path: 'components/name_of_component'` which looks like a vendored gem.
Rails engines has the ability to "isolate_namespace" which is I think the default for a new engine. This is where you can avoid global name spacing issues where each component can be thought of separately. Effectively, you have something _kinda_ like a microservice but it runs as a monolith. And if you need you can have each component depend on others so long as you don't wind up in a loop.
Note: I have a component "common_models" which is just for commonly used items across various components. The main app should have nothing in it's Rails.root/app since you instead have components.
I'm not related to this but here's a basic idea: https://cbra.info . (Pretty sure the author of this page made the Railsconf talk that inspired me to move to this years ago.)
I’ve primarily worked as a Java dev for the past 20 years, but I’ve got significant time doing python and one non-trivial Rails app.
The funny thing is I’m most comfortable and I believe most productive in the Java ecosystem, but only because of the time spent working in other languages. Coming back to Java after python, one gets a better feel for what’s essential and what’s cruft. Similarly, when Rails first came out, it can’t be understated how revolutionary it was with respect to web development. Coming from the J2EE universe it was like the true essence of web development had been hidden from us with servlets, JSPs, wars and ears.
That being said - I’m happy being a Java - well JVM at least - developer. The ecosystem is alway changing and often improving, but I assure you it wouldn’t if not for the evolutionary pressures of things like JS & Node, Ruby & Rails and Python & Django.
I love kotlin as a language and enjoy working with spring boot but the hype in the JVM community around JSON API + React SPA does make me wonder whether I'm moving away from it philosophically.
I'm particularly excited by Spring Native right now. Having a Spring Boot app startup quickly and use less memory will fit heroku-like PaaS environments perfectly.
I'm glad I ventured out of my Java only mindset however. Lots of interesting things going on but decision paralysis sucks.
20 years ago, Java development wasn't that complicated. Big consultancy came in and complexified the ecoystem just for the sake making the entry level way too high. A Rails developer only needs to know Rails and Active record and maybe Capistrano and some server.
A Java developer has to know Servlets, Glassfish, Tomcat and other containers, JSP,JNDI,EL, JSTL, JSF, JDBC, JPA, CDI, EJB, Hibernate, Spring, Maven, Gradle and God knows what to find a job.
For a beginner, the documentation is also all over the place. Java the language is improving sure, but some people are still stuck with maintaining struts applications to this day, with tons of XML files...
Just reading these make me depressed. I'm taking over a JSF project that uses gradle these months which puts even the complicated old spaghetti gulp build files to shame in terms of complexity.
Even more confusing is that there are some people who love that complexity. They are actually proud of it! Why would you have a globel gradle file in your $HOME that has project specific configuration? Why does your stupid project only run with some specific Eclipse plugins? Why does it take 2 days of depressing configuration work to have a running instance? I used to love Java! What happened when I wasn't looking!? They tell me "but you do it once!!", I digress.
In other languages there might be multiple frameworks and multiple libs all of which might do none of just part of what you need and if you find a lib you might not find an integration into your framework and need to build that yourself.
Rails was so big and the community was/is cooperative enough that you usually get fewer libs that are more complete and more likely to fit you needs and come with rails integration.
No need to test 10 or more libs to find out all of them sort of suck and then do it yourself or chose the least sucky one and integrate it yourself. THAT is what maid Rails productive and at times frustrating (you often only deep dive the components once something goes wrong).
Long term it will be interesting to see how many companies run with setups that are Node.js heavy in comparison to not just Rails but also Python, PHP and even Java, .NET and Perl (yes old but not dead).
Perl was one of the early languages and I don’t think there will be as many projects in it as there are in PHP. Python has a good amount of stuff and they didn’t really have a time of heavy hype (like PHP, Ruby on Rails or Node.js enjoyed) and Java and .NET are going to be more heavily traditional corporate than the rest.
Would be nice if somebody knows a link or two to explore this a little bit better.
When I think of all the half backed JS projects I’ve looked at when searching for a solution and compare that with Ruby, there is a difference.
As you mentioned, the Node.js ecosystem is full of specialised libraries to achieve typical use cases such as authentication/authorisation, ORM/persistence, etc. The Nest.js documentation is a great reference as they include a list of recipes for all those common scenarios and how to implement them in a Nest.js backend.