6 ms·

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

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!

brap 3y ago
>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.
- Towaway69 3y ago
  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
  - dkdbejwi383 3y ago
    > P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s https://sailsjs.com/ https://sailsjs.com/
  - monooso 3y ago
    Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.
    - pocketsand 3y ago
      Correct.
    - AlchemistCamp 3y ago
      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.
      - kugelblitz 3y ago
        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.
  - riffraff 3y ago
    Wouldn't python's _the framework_ be Django?
    - noirscape 3y ago
      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.
    - mooreds 3y ago
      Yes. Django is to Rails as Flask is to Sinatra, imo.
  - pier25 3y ago
    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.
    - joshmanders 3y ago
      > 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 https://adonisjs.com
      - pier25 3y ago
        It's cool. Another similar option is Platformatic by the creator of Fastify. https://platformatic.dev/ https://platformatic.dev/ But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.
        joshmanders 3y ago
        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 https://packages.adonisjs.com
        pier25 3y ago
        I didn't know about these packages. But still, nothing really that improves rendering. https://packages.adonisjs.com/?category=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.
  - chpmrc 3y ago
    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).
  - reducesuffering 3y ago
    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%2Cnestjs%2Cnuxt.js%2Csvelte%2Cruby-on-rails https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
    - singlepaynews 3y ago
      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%2Cnestjs%2Cnuxt.js%2Csvelte%2Cruby-on-rails%2Cdjango%2Creactjs https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
      - reducesuffering 3y ago
        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%2Cruby-on-rails%2Cdjango%2Creactjs%2Cdjango-rest-framework https://insights.stackoverflow.com/trends?tags=next.js%2Crub...
  - cloverich 3y ago
    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.
  - dominuskelvin 3y ago
    We have Sails which was inspired by Rails
- bdcravens 3y ago
  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.
- Pmop 3y ago
  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.
  - danmaz74 3y ago
    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.
  - tinco 3y ago
    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.
- jasonwatkinspdx 3y ago
  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.
- dominuskelvin 3y ago
  [dead]
ksec 3y ago
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
DoesntMatter22 3y ago
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
hmans 3y ago
[dead]
bbx 3y ago
> “From Hello World to IPO” Which specific documentary is it? Google seems to return a few different options.
- bdcravens 3y ago
  The linked Youtube video.
  - bbx 3y ago
    Ah yes, around 41 min in… Thanks for the reply.
bluedino 3y ago
The structure of Rails was my first experience of web development (as a job, at least) and it completely ruined me for anything else.
southwesterly 3y ago
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?
- cooljacob204 3y ago
  > 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.
- gls2ro 3y ago
  > 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.
PH95VuimJjqBqy 3y ago
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.
- neonsunset 3y ago
  .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?
  - PH95VuimJjqBqy 3y ago
    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/dotnet-core 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.
JohnBooty 3y ago
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.
- mooreds 3y ago
  > 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.
qudat 3y ago
> 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.

brap 3y ago

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

Towaway69 3y ago
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
- dkdbejwi383 3y ago
  > P.S. Perhaps because a JS framework based off the ideas of rails would be called jails! /s https://sailsjs.com/ https://sailsjs.com/
- monooso 3y ago
  Laravel would be a better example for PHP, especially as it borrowed so many ideas from Rails.
  - pocketsand 3y ago
    Correct.
  - AlchemistCamp 3y ago
    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.
    - kugelblitz 3y ago
      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.
- riffraff 3y ago
  Wouldn't python's _the framework_ be Django?
  - noirscape 3y ago
    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.
  - mooreds 3y ago
    Yes. Django is to Rails as Flask is to Sinatra, imo.
- pier25 3y ago
  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.
  - joshmanders 3y ago
    > 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 https://adonisjs.com
    - pier25 3y ago
      It's cool. Another similar option is Platformatic by the creator of Fastify. https://platformatic.dev/ https://platformatic.dev/ But still... There are no queues or jobs. No HTML over the wire. No colocation of presentation logic. Etc.
      - joshmanders 3y ago
        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 https://packages.adonisjs.com
        pier25 3y ago
        I didn't know about these packages. But still, nothing really that improves rendering. https://packages.adonisjs.com/?category=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.
- chpmrc 3y ago
  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).
- reducesuffering 3y ago
  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%2Cnestjs%2Cnuxt.js%2Csvelte%2Cruby-on-rails https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
  - singlepaynews 3y ago
    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%2Cnestjs%2Cnuxt.js%2Csvelte%2Cruby-on-rails%2Cdjango%2Creactjs https://insights.stackoverflow.com/trends?tags=next.js%2Cnes...
    - reducesuffering 3y ago
      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%2Cruby-on-rails%2Cdjango%2Creactjs%2Cdjango-rest-framework https://insights.stackoverflow.com/trends?tags=next.js%2Crub...
- cloverich 3y ago
  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.
- dominuskelvin 3y ago
  We have Sails which was inspired by Rails
bdcravens 3y ago
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.
Pmop 3y ago
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.
- danmaz74 3y ago
  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.
- tinco 3y ago
  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.
jasonwatkinspdx 3y ago
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.
dominuskelvin 3y ago
[dead]

ksec 3y ago

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

DoesntMatter22 3y ago

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

hmans 3y ago

[dead]

bbx 3y ago

> “From Hello World to IPO” Which specific documentary is it? Google seems to return a few different options.

bdcravens 3y ago
The linked Youtube video.
- bbx 3y ago
  Ah yes, around 41 min in… Thanks for the reply.

bluedino 3y ago

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

southwesterly 3y ago

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?

cooljacob204 3y ago
> 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.
gls2ro 3y ago
> 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.

PH95VuimJjqBqy 3y ago

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.

neonsunset 3y ago
.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?
- PH95VuimJjqBqy 3y ago
  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/dotnet-core 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.

JohnBooty 3y ago

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.

mooreds 3y ago
> 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.

qudat 3y ago

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