From Node to Ruby on Rails (opens in new tab)

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.

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.

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.

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.

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.

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.

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

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 ;)

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?

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.

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.

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.

This is also my only complaint with Rails.

I'm a programmer, not a wizard, and I'm not good at magic.

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.

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.

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.

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.

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.

P.s.: Just take a look at how this article is exploding (also most of the other Rails articles on Hacker News lately). They don’t just explode in popularity and comments but every single one of them has given me ridiculous amounts of karma. I would say that is a heavy indicator of a Rails popularity bounce-back, vocal AND silent.

Look at the people in this comment section that are emotionally upset that the author didn’t prefer JS over ruby. They’re calling the author stupid, saying the author is bad at bootstrapping or just not using the right frameworks.

People don’t seem to be emotionally connected to Rails in the same way.

If I started a project today that was slated to be on the web, I'd pick one of two languages. If the least interesting part of the work was the code, and I didn't see significant places where I was worried about future performance in the business logic layer, I'd pick rails. (This is 95% of cases.) If I thought this system would have performance-critical components or would need to scale to thousands of programmers of varying skill, I'd pick java.

(I have a soft spot in my heart for clojure and elixir, and there are some edge cases where I might pick those, and a java ecosystem would allow for clojure interop. For example, some problems lend themselves to functional thinking. And, of course, there are some problems where another language shines - I could see defaulting to another tool if necessary.)

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."

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.

At some point, stuff needs to be maintained. You can still start and drive that 1967 car, after all.

But, the whole point of using a framework like Rails is to let the framework make certain decisions for you, so you can develop quickly according to convention, and not think of lower-level technical decisions. Bypassing the ORM certainly works against that.

I'm constantly monitoring the logs during development to make sure it's doing exactly what I want. And the odd time when it's not the answer is usually within ORM api itself and doesn't require me to shift to raw sql.

This is why I never understood the argument that ORMs are for people that don't know SQL (not to suggest you were making such an argument). If anything being proficient at SQL makes you that much better at handling the abstraction that the ORM provides and that much better at examining the resulting queries.

Also if you'd like to manage the tables with SQL there's an easy way to generate the models from the database schema (https://docs.djangoproject.com/en/3.2/howto/legacy-databases...). I've used it before at a startup to migrate from hand coded schemas and migrations in SQL that only one person was brave enough to touch (they had no way to run things locally) to a full consistent REST API for like 20 tables ready in 2 days.

I'm also managing an SQLite db on a mobile app that uses hand written SQL (with 20ish tables and a few 100 queries) and any changes to the database end up being a nightmare of manually editing raw strings.

However, most of the other features of these frameworks are just bloat, added complexity that doesn't really make things easier than writing vanilla $lang with rock-solid libraries.

For example, in Go: URL routing, request handling (middleware), html templating, websocket communication are all trivial to implement with standard or well-known libraries. But it's the DB interaction where things get tricky and very code-heavy.

I'm trying out an approach, leveraging pgx and the new Go generics, where I define a simple generic Wrapper struct with some low-hanging fruit methods: CRUD, filtered+pagified lists, unique constraints, etc.

How? `encoding/json` and Postgres JSONB columns. The generic Wrapper is hardcoded with a simple and flexible table schema: an id column and a JSONB column (I also added some timestamp metadata columns as an experiment).

The end result is that I implemented a dumb "ORM" with around 200 lines of idiomatic Go, and can do the following:

wrapper := Wrapper[MyStruct]{pgx.Conn, "mytable"}

record := wrapper.Insert(MyStruct{some,real,data}) // returns a generic Record object which includes the DB id and pointer to the (actual, not interface{}!) struct, as well as other metadata perhaps

record.Data.myField = time.Now()

wrapper.Update(record)

for i, record := range wrapper.List(Params{}) { \\ do stuff with all the MyStructs }

...and so on and so forth. The goal here is not to implement a perfect ORM (e.g. pointer/FK spaghetti) but to secure that initial productivity boost of easily ACIDifying my data. As my data model gets more mature, I can individually migrate these "weak" JSONB schemas to proper, (de)normalized, relational Postgres schemas and define their data access appropriately.

No authentication built in, no ORM, no ActiveStorage, ActionMailer, no nothing really there.

I'm the developing a rails backend with a Vue front-end, and the more I work with js, the more I'm happy that I don't have it everywhere.

React is way better on the view side than ERb/HAML/whatever.

I miss ActiveRecord. Prisma is relatively clunky. I like having fat models integrated with the DB.

It also feels like I'm fighting with the type system because every variation of a row with different joins becomes a different type. I'd rather be lazy about joins.

A much better comparison would be either Blitzjs, Nestjs, redwoodjs, featherjs, or several other full stack js / ts frameworks. I'm pretty sure these frameworks were inspired and influenced by Rails

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 open a file and I feel completely lost.

Well, one of them was done in ten days by a guy who liked Java and the other one was done in a few years by a guy who liked Smalltalk, so...

This is also pretty much obvious from the get-go. When handling a HTTP request, the morally correct function is something like a function which takes a request as a parameter and returns a response.

In flask, for no good reason, a lot of things that are only accessible inside a request get put into global objects, and if you try writing code that accesses them outside of the right context, it will simply crash. You might accidentally refactor such code to the wrong place and you will have no idea until it crashes. This kind of design on top of a dynamically typed language is kind of like drinking poison and then shooting yourself.

Flask is full of insane things like this and it boggles the mind that it ever got as popular as it has. I suppose there weren't many alternatives.

Everyone talks about the complexity of the tooling and I have no clue what they’re talking about. This is from a backend perspective. If you jump on the TypeScript bandwagon, which makes everything infinitely harder, then maybe, sure, I’d agree with you. But JavaScript is dead simple to use.

Even now in frontend land there’s still innovation. Vite has been an absolute pleasure to use and spinning up a React app takes minutes. The irrational hate for JavaScript is really weird.

Yes, almost every other language is still more productive, but all that tooling gives you less and less each year.

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.

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.

I am documenting my process of building my first web app here: http://tbonesteaks.gitlab.io/blog/. Just started it today, so it’s rusty.

Node.js isn't easier but it's more useful in practice IMO.

Learn Next.js after sinatra/express and you are good for 80% of jobs.

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.

A few years ago, in a previous role, I was forced to use Java to start a new web app. I spent a couple months reading up on things, and trying to find a comprehensive example of a CRUD app in Java/Spring/React. I finally admitted defeat, and corresponded directly with the author of JHipster, and he pointed me to an example he had on GitHub, which had never come up in searches, but, unfortunately, was so out of it date, the code wouldn't work in modern versions of the stack. However, I finally cobbled together a working "show" page with nested objects, as ANY real-world web app will need to do. At this point, I again got stuck at trying to figure out how to update nested objects in a form.

As a mental exercise, I rewrote everything I had done in 6 months in Java/JS in Rails in 2 days. These 2 lines of Rails...

    class BankAccount < ApplicationRecord
        self.table_name = 'offer'
        belongs_to :owner
    end

I found another job.

P.S. There's a lot of talk on this forum about Typescript and how great it is, but very often in my months of trying to write this application, I couldn't get the types to line up through the stack, and just had to use generics.

imo the one I like best in nodejs is Blitzjs https://blitzjs.com/

FoalTS https://foalts.org/ is nice too and there are several other full stack frameworks like Nestjs, FeatherJs, and redwoodjs

What's popular is not necessarily what's right for the project.

> the output looks decidedly un-modern

You could say that about anything. The output styles to how you style it.

Also since when is modernness more important than content?

Reddit is not 'real time' app, and this seems like a feature, not a bug. Slack is way beyond where Campfire started out, but can you boil the difference down to interactivity?

In my experience, speed matters the most. Not just of development, but in user-experience. Rails is pretty damn good at this, especially recently. I still can't believe how fast a big Rails site like dev.to loads.

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'm sure there are modern projects that can make this painful, but if you're judicious about dependency management and staying on the LTS version of node, its rare you see any major headaches in our stack.

Even for super old / legacy services (ones without automated dependency mgmt through CI), it takes maybe 15-30m to get everything up to date.

Sveltekit uses an intuitive file based routing system, so for side projects at least, you can build out an app/POC very quickly.

Personally, I like Sveltekit's back end server better than Rails (to be fair, I haven't used Rails heavily since v3/v4) and Express. Having said that, I'm not sure Sveltekit's node adapter has been proven to scale yet.

Rails has a lot of nice stuff baked in though. So in terms of the many other moving parts of making an app, such as migrations, db connectivity, I think that's where a lot of time can be added on the Node side, especially if you don't already have a shortlist of go-to libraries for the core functionality you want/need.

the weird part about this post is it compares a framework to a runtime. that's weird and dishonest. a more realistic comparison is ruby to javascript.

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've worked many years with Django (doing old style MVC), then moved to do all the SPA stuff (worked with React mostly and some Vue). Now I'm back to MVC using Laravel and Livewire and it is simply awesome. If the decision is on me, I'm not going back. Laravel is awesome, and current day PHP is not 10 years ago's PHP the same current day JavaScript is not 10 years ago's JavaScript

https://opalrb.com/

If yes, what was your opinion? I never tried it since I'd rather just work in two languages.

The performance degradation for 99% of web app use cases is negligible compared to the productivity increases. My team switched from a node/react environment to a full stack rails monolith with stimulusjs and we're shipping faster with less bugs.

What do you consider "too much magic"?

Is this Rails version still a monolith? Because the way Web3 is trending and with decentralization, microservices should remain the dominant architecture.

MVC all the way, because otherwise you're never going to finish it. Doing a separate backend + SPA is an insane amount of work compared to a traditional full stack framework. Just thinking about validations (both server and client) make my brain hurt. Also you'll have to rewrite the frontend before even finishing it given how fast the landscape changes.

And even being a small team and not just yourself, I'd only think of an SPA if 1) You need an offline first experience, or 2) You don't have full stack engineers at hand and you only have backend people which don't want to touch JavaScript and frontend people which only want to work with JavaScript..... but this is more of a people problem than technical one.

I've done a lot of Django in the past, then a lot of SPAs for the last 6 ~ 8 years, and now I'm back to Laravel + Livewire and I'm living in a dream right now. Everything is so easy that I feel I've been cheated the last few years.... so much time and money (from my employers) wasted...

JavaScript is much harder to avoid because there's isn't really a native alternative in the browser. JavaScript is forced down our throats, liking it or not.

So yes, I personally resent js and its community for it. And I feel extremely pissed when I'm told how supposedly awesome this technology is, because I'm having an indigestion. It's not about getting a rise out of bashing, it's just the expression of an immense fatigue about this ubiquitous stack.

So there's the light trolling of other stacks, and there's js. :)

Laravel:

- no admin (although there are good free projects like filament admin)

- not well defined models

+ queues builtin

+ task scheduling builtin

+ livewire builtin

+ webpack builtin (this saves a ton of time as if you have a problem someone else likely has had it as well)

+ builtin relatively sane api framework (although the inertia integration for things like Vue, seems to almost encourage exposing more data than you mean to, I see this a potential data leak vector with unexperienced developers)

+ composer is way better than poetry/pip/pipenv/ whatever

+ first party support for many things you'll need (Payments, Browser testing, Hosting, Docker development, etc)

+ cheaper developers

+ Laravels facades such as Collection, Arr, Str remove many of the warts of PHP and in some cases can make some manipulations almost as concise and readable as Python

+ Laravel seems to monetize things better which imo is a path to sustainability.

+ Encourages use of modern css frameworks / javascript frontends.

Django:

+ admin (although dated looking and very hard to sell for client facing admin stuff, as it will never look like they want it to), honestly maybe the best admin out there for speed of setting up etc.

+ better models with db columns defined in model, could use typing though.

+ way better documentation

+ python's better more concise syntax on most things

+ fully automatic migrations (although you will eventually run into issues here, with good practices can work very well)

- python packaging in a horrible state

- too many basically essential packages not in core (api, queues (even database based queues))

+ python packages for basically anything out there somewhere

- Django rest framework (this project was okay for its time, but it is seriously dated, and takes the air out of some better projects such as django-ninja)