Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I'm gonna go back a short bit and say, for me? Ruby on Rails.

In 2007 I was plugging away at PHP with whatever frameworks were around at the time -- the vast majority of web dev that I saw then was pure procedural scripting down the page, maybe some `include` statements to pull in database functions. Especially in PHP, which encouraged mixing logic and HTML. The consultancy I was with had built custom stuff on top of Zend framework, and it helped a lot.

But around summer of 2007 is when I started hearing folks crow about Ruby on Rails, this hot new web framework written by a Dane in a Japanese programming language. It had been out for a few years and it was the hot topic in web dev circles, and so I decided to see what the fuss was about one weekend.

Instantly stuff I'd always had to do by hand was done for me. A decent data access layer with a few lines of code per db table, that automatically handled preparing and executing statements, and could handle keeping the database up to date with migrations. A REPL where I could load up the code I'd written for the app and use it for one-off debugging or maintenance tasks. A thriving plugin scene where many of the things I'd bashed together over the years were available, for free, just by cloning a repo.

That weekend I reimplemented the core functionality of one of the apps we'd been working on for a client. We'd taken about 10 weeks to get this thing into rough shape and I had its equivalent in two not-very-busy days. Authentication, authorization, CRUD, and fancy database queries I'd all had to hand-roll before just fell out of Rails.

I'm not overselling it when I say that for me, Rails was an absolute game-changer, and I myself and many folks I know owe their careers to the Ruby community and its (not always perfect) attitudes about software development. MINASWAN.

(I'm still active in Rails and the local Ruby community [Columbus Ruby Brigade!] but I'm running an Elixir/Phoenix shop now, which feels to me like the next step on the path Rails forged us.)



Cannot agree more.

The convention over configuration was brilliant - the implicit mappings made so much more sense. I could look at any given url and imply so much about what route/controller/view code was going to execute. The standardized code organization. ActiveRecord using the column names as data attributes.

Was CoverMyMeds written in Rails?


Ironically this is exactly what I don't like so much about Rails. It's such a "batteries included" framework that if you want to do what Rails is good for, it's going to be super easy, but if you want to do something a little bit different a lot of times it feels like you have to almost break Rails to make it work.

To some degree I think it's a matter of taste, but I would much rather start from a blank slate, with a set of sensible tools to build my solution up from scratch, rather than having an almost finished product I have to carve my solution out of.


> that if you want to do what Rails is good for, it's going to be super easy, but if you want to do something a little bit different a lot of times it feels like you have to almost break Rails to make it work.

I feel like this is implicit in the name: these are the guide rails, stay on them and you will deliver more value in less time than you ever have before. If you need to do anything where you have to leave them, you have deRailed the whole thing.

The train metaphor is actually a pretty good one.


> you will deliver more value in less time than you ever have before

I think this is arguable. It's also not that hard, for instance, to get a bare-bones node API up and running and pair it with a React single-page app. And that approach is more modular so you can replace components in the future in a way which is harder than with rails.


This gets a hard disagree from me. I _really tried_ to give the whole node + react approach a go because, to me, GraphQL & all the things you can generate with it is _magical_ (especially fine-grained authz with app-specific graphql directives - beautiful!). Singularly, the availability of xstate to replicate business processes identically between api & ui. So useful! So undervalued!

Then I ran into finding myself spending time on background jobs, authentication management (not the basic functionality but tinkering & modification past password reset / session management, blacklist/expiry if jwt's, etc), file upload integrations, db management (when not utilizing prisma or hasura), etc. High variety of effort spent on tasks where I found myself asking the question, "why am I having to work on this...?"

I still ship more in Rails. It's still a better tool for most things. There are cases where I'll reach to node when needs are simple and short-lived. Other tools have the potential to exceed Rails (and I hope they do), but they're not there yet.

One of my least favorite things about Rails, & one of the best ideas to emerge in the past decade or so, is react. The componentization of views driven by state is such a useful approach. Rails has historically had a has & belong to many relationship between controller contexts and views, which is essentially global and easy to get super confusing. React (and now browser-react aka web components) provide a better way of tackling this problem.

And... they hook up directly to my cache? They provide a great way of broadcasting dom updates directly? They interoperate with web components no problem where I need high fidelity interaction/performance? etc etc. Rails... has done it again.

No getting away from how useful it is.


For most of the professional work I've done, I'm doing a CRUD web app. So if Rails or Phoenix lets me get to market faster with a tested solution, I'm sold. I've even got a talk I used to give about getting Rails to work with a legacy database, which has gotten much easier from the early days.

Now that I'm hiring devs, I do not want to pay them to build a CRUD framework from scratch, I'd rather have them building business logic we can't get off the shelf for free.

But whatever ends up working for you is cool!


It’s hard to know what cases you’re discussing without specifics?

A majority of online information based systems take input via forms and retrieve data from a database based on that input.

This is where Rails is the GOAT.


The initial application that powered CoverMyMeds was PHP, as it grew out of the consultancy I mentioned in my original post and we were a PHP shop then. AFAIK it still exists and is actively maintained.

Most other apps and services at CMM were written in Rails after we showed that we could ship better software faster with it, and it now accounts for the vast majority of code there.


I haven’t used RnR but I assume its similar to Python/Django in taking people who know how to program in any language and turning them in to full stack web developers.

Its a funky learning curve where all team members are effective and few need to have extensive experience with the framework.


I've used Django, and while there's a base similarity the philosophical differences between it and Rails are definitely there.

Not gonna take a side on the Rails vs Django deal though. Like you said, if a team can effectively ship software with it that's the only measure that counts.


I’m curious what your take is on the JAMStack+lambdas style of app development.

I am working on a new web app. Initially, Elixir/Phoenix was looking like an excellent option, but then I looked at hosting and decided it would be easier to use something like the Serverless framework for AWS deployment which JAMstack+lambdas seems to match better — no need to manage VMs and networking infrastructure, mostly.


JAMstack is...not my jam.

I'm a big fan of rendering majority on a server and then shipping it, especially with Phoenix's LiveView which allows you to write reactive UI without writing Javascript.

But I said it in another comment: shipping value beats everything. If you can ship quickly and effectively in JAMstack to lambda, don't let anyone tell you that's wrong.


Shipping value is important. If you can build a solution faster in a monolithic, MVC style framework running on EC2 instances, then do that. I think people get too bogged down in the minutiae up front and forget they are being paid to solve a problem ASAP. Worry about optimisations and improvements when its going to add more value than right up front when the burning need of the business is to have something - ANYTHING - up and running and helping generate revenue.


I have been building JAMstack apps since 2016 using exactly the stack you are asking about. Using something like the Serverless Framework to help you build and deploy your collection of microservice backends into AWS as well as your static frontend into S3 is just awesome to behold. I have had an app running for 3 years with spikes of traffic and have never had to worry about maintenance or downtime.


As a Perl programmer I didn’t get the hype of Ruby. Then I wrote my dissertation on it. I still didn’t get it. Python is fine and I see it’s strengths and weaknesses but Ruby is just hipster Perl and doesn’t have Moose. Don’t, as they say on Twitter, “at” me.


I think you’re making the classic mistake of confusing Ruby with Rails.


Which is an oddly pervasive mistake! I had a coworker once assume since I knew Ruby the language, that I'd be completely comfortable with Ruby on Rails' Active Record system.


Absolutely. I learned Ruby at the same time as Rails, and then when I started using Ruby by itself I saw how much heavy lifting ActiveSupport had been doing for me.


Rails seems to land best with those having an Intimate and Arcane Knowledge of the Ye Old Webbe and Its Attendant Developmente.


GP is talking about Rails.


Earlier this year I played around with Phoenix for a bit. As a JS dev learning about all this all at once it looks like such a great dev env.

One thing that still felt rough around the edges was the tie in with npm packages. Has that part been improving?


AFAIK Phoenix doesn't tie in with npm packages whatsoever.

You have an `assets/` dir that contains your javascript stuff, and out of the box Webpack is set up there, but besides that it's all your choice, with the exception of the pre-shipped stuff for Channels and LiveView.


It’s not supposed to tie in with NPM packages. Phoenix handles the back end, and can handle the HTML as well. If you want to include any front end JS stuff, just include the scripts or bundles like you would a regular site where you include JS stuff.


Can i do Ruby in rails without having to learn Ruby? I like Python, I think.


Oh definitely. I picked up Rails without doing a single line of Ruby beforehand, and I think that's true for many of the Rails devs I know. Knowing Python is a plus, much of the language is gonna make basic sense.

For me, the big hurdles early were Blocks, which seem strange at first but make sense, and some of the metaprogramming stuff which you can definitely ignore to start and be just fine.


This was what I did when I was playing with Rails, but I felt like I was missing a lot about the fundamentals of the language. Especially because Ruby has a very free syntax, and steps far away from other languages in terms of syntax, I was able to copy things and make it work, but it was harder for me to really get the language than with many others.


Oh definitely, but for me I was never gonna be able to learn Ruby in a vacuum. If I had needed a general-purpose scripting language in 2007 I'd have reached for PHP or Perl, both of which I knew from web dev.

But with Rails I had a reason to pick up Ruby in the first place. So I didn't know a damn thing about metaprogramming or duck-typing going in, but I knew Rails was lightning and I wanted to capture it.


Actually, yes. Contrary to received wisdom, most Rails devs learn Rails before or as they learn Ruby.


Short answer, yes.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: