Hacker News Reader

Comment by mosselman | Hacker News Reader

I had a lot of fun watching this documentary. The one person framework really comes out in the personal story of Toby from Shopify. "From Hello World to IPO". What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one. Sure that can be true for many apps, but in a world of, for example, APIs and front-end stacks, that isn't always the case.

The latest developments in Rails are making the solid foundation even more solid. There is stuff happening to make infrastructure easier: Kamal sure, but also Solid Cache and Solid Queue and there is a lot happening in the front-end with Turbo (Morphing) and mobile apps with Turbo Native and Strada.

We have upgrade to 7.1 already and have a mobile app in production that is built with Turbo Native. I am also excited to start replacing our Redis cache with Solid Cache to make everything simpler and cached longer.

Great to see the Rails community so alive and see the deep connection the (ex) core team members have to the framework!

View on HN

>if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one

I've never worked with Rails, but this sounds amazing. One of the things I really hate about the Node.js ecosystem is that there are no clear conventions, the structure is always different even when the same framework is used. It's a mess. The exception is probably Next.js but it's more frontend-y.

It's a huge benefit for agency/consultant work. You can jump into a project you've never seen before and just know where everything is and how it's wired together. You can be immediately productive.

The downside is if you want to do something that cuts "across the grain" so to speak, things can get messy. Combine that with Ruby's high dynamism and someone trying to be too clever can make a mess fast (alias_method_chain anyone?).

Yeah, node has been incredibly successful but I think it's a fair criticism to say it's also a victim of that success in that it just feels like so much arbitrary complexity. And the flavor of the month changes so fast that projects end up this weird mishmash.

Many of the Node projects (typically Express) I've built start out super tiny, one or two files, but once they grow to any production-level complexity, I find myself more or less mirroring the Rails structure.

Not "any" but "most". I've worked for a company whose RoR codebase/structure looked completely different from the usual because they used a Domain Driven Design-inspired architecture.

This is due to a conflict of philosophies within the RoR community. Basically the clean code enthusiasts (which are also more likely to subscribe to DDD) argue that business logic should not be tied to which specific web application framework you use. So it should basically be in a separate codebase, either in the `lib/` directory or literally in a different project and included into your application as a Gem.

This makes sense from an objective perspective on what constitutes clean code, and I used to believe that this is what a really large enterprise Rails codebase should be refactored to eventually (although I never personally did so).

Rails offers an alternative approach to this however, that is less neat from an objective perspective, but actually follows the Rails principles a lot better and it's called Rails engines. Basically you split your Rails app up into multiple mini-rails apps for each domain called Rails engines, each has the same directory structure as a Rails app and you get the full benefits of a regular Rails app inside each. I used to think this was an ugly approach and I never even considered it, but now after over a decade of Rails development I've made a 180 and I believe this is the way to go.

The "clean" way forces you to construct interfaces between your business logic and the Rails app, basically introducing a lot of extra boiler plate. All for the perceived benefit of making your business logic be abstract of the Rails framework. This violates YAGNI of course, and by a huge margin too. I've never seen the business logic of a Rails app be ported to some other framework in 15 years, the most I've seen is reusing code in a Grape API that was mounted inside the Rails app. And what you give up is Rails' convention over configuration and its predictable structure, and the general documentation and knowledge of that structure that people can carry from job to job.

I'm struggling / thinking about this myself a lot.

I've learnt a bit of Django's app-centric model (which is similar to rail's "engines")

I work for a company that enforced the data/domain/interface with a plug-in approach to custom code.. and I liked it.

But for my own projects, I get stuck choosing between the two, I see more benefits in the layered approach, but I feel like I'm fighting the tide with every project I start

That's very interesting! In Django this "Rails Engines" approach is the default. A Django project will be made out of multiple Django "apps", each having its own routers (called URL-dispatchers), controllers (called views - yes, I know its weird to call them that), models and templates.

I really liked the DDD book, but I think that many of the suggestions mostly apply to huge "do it all" enterprise applications, which are also not the best fit for Rails. So I think it's OK if you can't easily apply those patterns to a Rails app - if you actually need to build a single enterprise application to rule them all, you should probably choose a different framework anyway.

True, nodejs really doesn't have _the_ framework. Python had flask, php is WordPress and RoR.

Why is that? Especially since most of the new frameworks copy the ideas of existing frameworks.

P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.

I agree. The only frameworks I’ve found about as productive as Rails are Laravel and Phoenix.

Django and Sails.js both seemed like they were a step down in terms of general productivity, though each had a unique advantage of their own (admin out of the box, websockets & realtime features).

I haven’t had a chance to really give RedwoodJS a trial run, but it's the JS-based fullstack framework I'm most curious about.

After a few years, and as my own application has grown, I feel I'm more productive in Symfony than Laravel, because there's less magic, I know where stuff is, and it's more "loosely" coupled components whilst Laravel is "All in or get out". I've been updating my app since Symfony 3.3-ish to now 6.3 and it's been fun! I've had to exchange the auth, the admin section, added new features, killed off features, but I feel with time, that my code has gotten more stable.

Maybe my first update experience with Laravel was a bit of a mess (v4.2 to v5.0 "The recommended method of upgrading is to create a new Laravel 5.0 install and then to copy your 4.2 site's unique application files into the new application. This would include controllers, routes, Eloquent models, Artisan commands, assets, and other code specific to your application."), and I couldn't easily "see" the models' properties and the Facades, that's why I have shy-ed away from it a bit. I have worked with several Laravel applications since then and have gone through the v6 through v10 upgrade cycle and can say it's gotten easier (though I wish they could settle on a release schedule), but my preference is still Symfony.

Plus when I checked out Django, I felt a bit more "at home" (e.g. see Twig templating language and how they used Django templating language as inspiration).

I've worked with Vue.js and AngularJS 1 and Angular 2+, but I'm glad htmx is coming in strong, so I can focus on logic, speed and stability instead of glueing the frontend and backend API together and debugging in the different browsers.

It will probably not be a well-liked comment, but Spring is absolutely there in terms of productivity, and the cool thing about it is that it never leaves your side when it comes to more and more complex requirements. It really has everything and especially Spring Data with JPA is unbeatable.

I have been using Sails since 2018 and it’s what feels close to Laravel for me and the way I keep coming to for building on the web.

Correct.

I've built Django projects for years and wondered the same thing whenever I had to build something in Javascript land. There are some scaffolding tools that do pretty much what those frameworks do (e.g. create.t3.gg, which I've used recently for a couple of small projects and really liked) but obviously lack that feeling of cohesion that strong opinionated frameworks like Rails or Django come with.

Not sure if that's a plus or a minus, after all there might be devs whose preferred stacks differ by 1 or 2 items (e.g. prisma over drizzle, nextauth over something else) and they'd both benefit from having a standardized template to start with.

EDIT: just remembered I fell in love with Meteor for a while. Then they started shoving React and other external stuff into it to gain more market share and it inevitably lost that opinionanted nature that, IMO, made it so good. Choice isn't always a good thing for the end user (even, and sometimes especially, when that end user is a professional who just wants to get things done).

I've wondered about this for years.

Express was the default with Node for some years but it was mostly used for APIs to feed front ends. These days lots of people have switched to Fastify but again mostly for APIs.

There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.

Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake. And I say this as someone who has been doing mostly front end since the 90s.

> There's really nothing fullstack in the JS world that can be compared to Rails, Laravel, or Django.

I would like to introduce you to Adonis. https://adonisjs.com

It's cool. Another similar option is Platformatic by the creator of Fastify.

https://platformatic.dev/

But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.

All of that stuff can be easily added using 3rd party packages, just like Laravel, Rails, Django, etc all have userland addons. https://packages.adonisjs.com

I didn't know about these packages. But still, nothing really that improves rendering.

https://packages.adonisjs.com/?category=Rendering

And the fact that these aren't official is kind of the point I've been making. In the JS world there isn't a holistic fullstack framework. You have to stitch it all up yourself. In Adonis, Express, Fastify, Next, SvelteKit, etc.

> But still, nothing really that improves rendering.

Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.

> In the JS world there isn't a holistic fullstack framework.

This is true for all monolithic frameworks in every other language. Even Rails you have to use 3rd party addons for stuff. It's not feasible to build everything in for every possible use case, so they make it easy to add on stuff.

I think now you're just starting to move the goalposts.

> Because most people are content with using Adonis' Edge templating with something like Alpine for sprinkling in interactivity, or using Vue.

I'm not talking about adding client-side interactivity though. Read my comments again.

> I think now you're just starting to move the goalposts.

I think you're not really reading my comments.

Obviously no solution will solve everything 100%. That's not even an argument.

> to kludge front end components into the server which IMO is

I think you make a good point here, JS is uniquely able to be executed both frontend and backend, hence things such as underscore templates.

Other languages don't have that ability. Therefore I would agree that there is no point in making a 1to1 copy of existing MVC ideas.

Being an ex-rubyist and now doing a lot of NodeJS, I really enjoy moving server code to the client at zero mental cost since it's mostly the same APIs

Sharing code is cool but OTOH the back and front end are two completely different beasts.

Trying to use client patterns to solve the server has been mostly a mistake. OTOH separating server and client and using an API to glue has produced a lot of issues too (SPAs, etc).

I think the future is a hybrid model where 80-90% of the front end is orchestrated from the server (LiveWire, Hotwire, LiveViews, etc) and 10-20% is a pure client side solution.

I totally agree (also originally a Rails dev). And with Typescript and Remix I get type safety and auto complete from the database layer (Prisma) all the way to the React UI. It’s amazing.

>Current fullstack solutions (Next, Nuxt, SvelteKit, etc) in JS are trying to kludge front end components into the server which IMO is a mistake.

why?

Wouldn't python's _the framework_ be Django?

Yeah for a default rigidness with the ability to tinker in obvious ways the framework for python is imo Django.

Flask is almost completely freeform in what it allows you to do, it just has a few style recommendations and a ton of community convention, but you could technically ignore 90% of it since Flask doesn't really expect any sort of structure.

Yes.

Django is to Rails as Flask is to Sinatra, imo.

> P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s

https://sailsjs.com/

IME many of the earlier new frameworks were somewhat poor attempts at replicating established players from other languages. That resulted in a lot of cargo culting of bad code, then inevitably churn. I think that's one (of several) reason(s) why Express became more ubiquitous early on. Then from there, since Express became the most popular, and it was more of a micro framework, it allowed multiple competing sub frameworks to emerge. I really tried to use some of the other JS frameworks at the time, and having migrated from Python / PHP always felt they were not very usable by comparison.

Moreover, JS really encouraged the use of API driven development + React, at a time when that trend was in general growing. I bet this impacted the ORM development space, as I suspect FE style devs were perhaps more demanding of an ORM while more backend oriented devs were perhaps fine writing SQL. With other frameworks I find the coupling of ORM and template views to be slightly more natural. Maybe this is just me inventing story lines but its how it feels. I think the lack of a quality ORM _really_ hurt the most.

Lastly there was a growing trend towards micro dependencies and assembling from parts, and I think it promised more than it could deliver. I think if Node had shipped a higher quality standard lib, perhaps akin to Go or (maybe) how Deno is trying to do, the story might have looked much different.

This is my take as a consumer, rather than creator / maintainer of these frameworks, so not sure how accurate this is. Just my viewpoint with my dev career growing alongside the early emergence of Node.

Despite what others will say here, it actually is Next.js. People don't agree with parts of the stack (just as C#/Java people didn't agree with what Rails was doing in 2005), or point out projects with the equivalent mindshare of Sinatra/Flask like Nuxt and Svelte, but when you look at what company-level projects are majority building with in 2023, it's Next.js.

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

How do we know it's not Django/React?(not sarcasm; trying to learn) Adding those two to your link shows them on similar "these increase as rails decreases" correlations, with more area under curve:

https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...

Well, for one, stackoverflow trends are not the only criteria I'm using here. Recent GitHub projects, HN who's hiring threads, frequency of features shipped, and more are being factored in, personally.

Next.js is using React, it's a piece of the fullstack framework, like Rails and erb. React is the primary fullstack JS templating system, that's even more featureful as it's a better client side JS interop story than html templates.

By the stackoverflow graph, it's clear that most complex projects have moved onto frontend frameworks like React, instead of templated html, which standard Django is using. Django used in conjunction with a frontend framework, is most often through Django Rest Framework, which fares much less popular on stackoverflow trends:

https://insights.stackoverflow.com/trends?tags=next.js%2Crub...

We have Sails which was inspired by Rails

And lots more.

Ruby 3.3 YJIT is 2x faster than Ruby 2.5 in RailsBench.

Work on brining more Ruby Gem from C to Ruby ( easier JIT )

Lots of dev tooling around Ruby and Rails coming.

Hopefully there are more good things to come in Rails 8.0 and Ruby 3.4

What's funny to me is I have been doing Rails for 15 years, even wrote books on it, and I just thought Tobi was a guy who made a lot of popular Rails stuff. Didn't realize he was the founder and worth 5.5 billion dollars lol

     it looks basically the same in structure whether it is the 
     biggest Rails app there is or a new one

Totally agree! Developers tend to really undervalue this aspect of RoR.

In addition to easier onboarding, it greatly reduces bikeshedding.

MVC maybe isn't the best paradigm for everything, but it's good enough for most things.

> Developers tend to really undervalue this aspect of RoR.

I agree! I think maybe because the consistency only shows its value:

* over years

* in its absence (on other projects which aren't using rails)

Which means it is easy to miss.

I see the same thing with spring. Having constraints helps free you up to solve different kinds of problems. I lived through the "let's define everything from the ground up, picking all our libraries, etc" phase of Java (in the early 2000s; I remember Tapestry and Wicket and Struts and Expresso and XMLC). Would prefer to not do that again.

But coalescing on a particular framework is something that a community has to arrive at together. While I think that JavaScript, for example, would benefit from this, I don't know how to encourage it (other than by leaving comments on HN, maybe :) ).

And don't think that coalescing means there are no other frameworks. Java has a number, and Ruby does too (trailblazer is a rails++ , Hanami is a rethinking of MVC, Sinatra is like flask). But having one big player makes it easier to focus on higher order solutions.

The structure of Rails was my first experience of web development (as a job, at least) and it completely ruined me for anything else.

So if I have an idea for an online service / app. I can go an make it using Ruby on Rails all on my lonesome?

Do I have to deal with JavaScript in any way?

> I can go an make it using Ruby on Rails all on my lonesome

Sure can. However I won't pretend it's the only framework you can do this with and be productive. I love Rails and Ruby but it has great competitors these days.

> Do I have to deal with JavaScript in any way?

Really depends on what you're doing but probably.

> Do I have to deal with JavaScript in any way?

You can use Hotwire (look at turbo frames and turbo streams) and you will write less Javascript code while achieving some very nice interactive UI.

> What I also loved is that he mentioned that if you open up any Rails application, it looks basically the same in structure whether it is the biggest Rails app there is or a new one

Which is funny because uncle bob cites this as a major downside to architecting code.

> “From Hello World to IPO”

Which specific documentary is it? Google seems to return a few different options.

The linked Youtube video.

Ah yes, around 41 min in… Thanks for the reply.

I'm going to have go push back on this.

I don't like the RoR community, not because they're bad people, but because I think they're insane from a tech perspective.

I only occasionally pick up RoR work because of how off-putting my first experience was. But what makes it worse is that every project I've been on (including one I just started on a few weeks ago) has just been a cluster.

What you're saying here is true in theory, but what you're not telling people is how the community is about as close to the attitude of npm as you can get on the server side. hundreds of gems on your typical application, many of which are used in 1 or 2 places, helping avoid a grand total of less than 5 lines of code.

Then there's the ratwheel you opt into with rails. Every single damned time I find myself having to manually patch libraries to get it working properly. I even once had to track down an old Ubuntu image of a version that had EoL'd 5 years prior and THEN had to manually patch a few C dependencies just to get it to build and run.

Don't even get me started on wkhtmltopdf, fuck that dependency. If you use that in your RoR project, fuck you.

^ that's only partially meant to be humourous.

My experience is that developers suggest RoR then run off into the sunset on their new project, leaving companies not understanding that they're now on a ratwheel of maintenance and upgrades until it's so bad only someone such as myself even has the skillset necessary to pick up the pieces.

Contrast this with asp.net core. Each LTS version is supported for 2 years (which is too short imo), but more importantly, you can install the EOL versions just fine. I would never recommend RoR over asp.net core (asp.net 6+ ... LTS only) because developer productivity isn't worth the maintenance cost.

I think you have encountered some projects built by undisciplined teams. That is not a reflection on the framework, rather a reflection on the people improperly using it.

while that's true and obviously you can avoid these problems with any framework with enough discipline, my point is that the community in general isn't disciplined.

I've repeatedly seen the same things over a 15+ year timespan.

Maybe people only need to hire you when they have problems, and the ones where things went well don't need your help?

The culture encourages a lack of discipline; indeed, high framework coupling is seen as the Rails way.

Framework coupling sure, but that has little to do with adding other random dependencies.

Also why would you be afraid of coupling to the framework? It's not like you're going to be able to change the framework after the project grows, anyway.

For all the complaints of slow tests, the Rails community is reluctant to decouple from the framework, which is the root cause of the issue. To me, that is lack of discipline: choosing the framework way (e.g. tribal identity) over engineering integrity.

It may be that slow tests are just easy to complain about, and there isn't much business value in doing that. Totally fine. But, other things come to mind: weird cottage industry of gems that did dubious things to speed up tests (and were prone to breaking), the skepticism around interactors, the hegemony of active record (the pattern). None of those are bad things, but they reinforced the fact that the technical values of the Rails community do not work for me.

.NET's LTS releases are supported for 3 years and STS are supported for 18 months. I wish LTS support was 5 years, it seems like ecosystem has matured enough post-going-OSS-wild-ride starting with .NET 6 release and is ready for such a support timeframe. Or at least they could have every other LTS be ELTS?

Also, I do wonder if RoRs perceived productivity is by inertia? I have a hard time believing you can top the productivity of quick scaffolding for back-end you get circa .NET7-8?

On the flip side, within the last few years, upgrading .NET versions has become typically a very easy exercise.

The ASP.NET team tends to churn stuff wayyy more often than I'd like for questionable reasons, which can make keeping more painful than I'd like - but tbh I often just keep using the older ways of doing things in ASP.NET since it's almost always still supported...

I do think .net moves faster than it should (faster than it used to for sure) but I assuage that worry with the fact that you can still install .net framework 1 and it'll work.

you're right, looking closer I got my wires crossed.

non-LTS is 2 years, LTS is 3 years

https://dotnet.microsoft.com/en-us/platform/support/policy/d...

imo, short term RoR will beat the pants off asp.net core in terms of developer productivity. mid to long term asp.net core wins hands down in terms of developer productivity.

I don't think the RoR productivity story is fake, but I do think it's not worth the long term maintenance costs.

Perfect storm of dynamic typing, needing to keep up with breaking changes, thought leaders that thought leader too much, and a community that seems to push back on anything that calls into question The True Rails Way.

Reply on news.ycombinator.com