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

Rails really nailed the problems of web development as it was 10 years ago by (rightly) pointing out that 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).

Web dev is in a different place now. Developers don't generally install and maintain application servers from the ground up. Scriptalicious was superceded by jQuery, which in turn was supplanted by vanilla js actually becoming useful. Relational databases are not quite as dead as some people would lead you to believe, but other types of DB are much more common now (key-value stores, search indexes, etc).

Rails was probably one of the last truly open source projects (Most OS these days is to some degree 'owned/developed' by Big Tech) to get big traction and for that it deserves credit. Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.



Rails is good for two things: Fast iterating and fast on-boarding new employees.

If you want to start a startup, and you know Rails, use Rails with Postgres.

Do the complicated shit (data science, video uploads, etc) in your other language if you have complicated shit. Use a different subdomain or get nginx to fork the endpoints for the complex shit if it needs to be public.

I've known plenty of people, myself included, that tried something else because of "reasons" but the real reason was I wanted to try some new language or framework but it gets old fast.

> I'm gunna use Riak!

I said. Then I needed to do some random task that would have been trivial in SQL.

> I'm gunna use Go!

I said. Then I spent hours fiddling with types and boiler plate code and catching errors.

These are not solving problems startups have. These technologies solve problems that huge companies have. My only gripe with Rails is that I think it should be JSON-first, not HTML-first, because almost everyone needs an API these days and many people use front end frameworks for HTML, but whatever. It's not that hard to override that stuff.


Agreed with all of these points.

> I think it should be JSON-first, not HTML-first

Isn't that the case in Rails 5? https://guides.rubyonrails.org/5_0_release_notes.html#api-ap...


Yes, I'd forgotten that that was option I should have addressed. The issue is that I want things like cookies to be supported out of the box for things like Ember, even if I want other API consumers to use locally stored tokens. But you're right. There is some attention going that way.


Check out the Rail API gem. It's default in Rails 5 and makes JSON and HTML the default.


> Just the idea that a Danish web consultant could hack together something that became popular and which then allowed him to literally retire and become a racing driver before he hit 30 should inspire us all.

While being successful in all those aspects, DHH is still very active in the development of the framework. He is currently also the CTO at Basecamp. Not really what I would consider being retired.


Also he didn't get rich at least to begin with off Rails as such, which is free open source but off Basecamp which as he is fond of pointing out charges customers money in the old fashioned way. (As opposed to raising VC.)


I have a vague memory of reading an article by him shortly after he got the investment from Jeff Bezos when he spoke in terms of being "retired" (sadly ungoogleable now because "david heinmeyer hansson retired" just gives lots of hits for motor-racing). Of course things change, and he is definitely working now, although his working life seems to consist of very well paid, powerful, interesting and part-time positions, so I think the point stands :)


You're speaking as if Rails is useless now, when in reality it's still a great tool depending on the job, especially since Rails has an API-only mode that works great with the modern SPA front-end ecosystem (sidenote: not every app needs to be a SPA). I built a company with it that provides a developer API, and that has a modern SPA front-end. Rails is still useful, especially for startups.

(And DHH didn't literally retire--he runs his company, Basecamp, which is built on Rails, which he actively maintains.)


> Web dev is in a different place now.

Yup, but why? This is still true:

> 97.2% of web projects were all about making an application server talk nicely to a relational database and then generating a front end that reflected the data model and that had javascript that Just Worked (everywhere).


> Yup, but why?

Mobile and mobile-first thinking, perhaps. "webdev" is far more js-driven than it was 10-15 years ago. I'm not sure whether that's good or bad, but imo that accounts for much of the difference. 15 years ago I could build entire applications with a minimum of JS, and they were acceptable to clients. That's not really the case any more - there's more demand/need/expectation of js in web projects today.

The need to talk to relational database is, ime, as strong as ever, while the need for supplemental data stores is growing, but is rarely the primary focus for any system already in existence.


> there's more demand/need/expectation of js in web projects today

On the backend too?

There are headless Rails applications. Is that what you are talking about? If I understand it correctly, it's essentially a Rails server that exposes an API that a Javascript client uses.


okay so to achieve a good mobile experience, you need a responsive layout and some sort of pjax rendering. That still doesn't explain the massive weight of current front-end solutions.


> ...jQuery, which in turn was supplanted by vanilla js actually becoming useful.

jQuery is written in vanilla js so vanilla js can do anything jQuery can. I'm always irritated when people claim that vanilla js can't do something X can do.


It's hyperbole, but the point is that vanilla JS couldn't accomplish it easily without a lot of headache.

Handling browser compatibility alone made jQuery extremely useful back when it first emerged.


It could be accomplished just as easily by writing your own function just as jQuery did.

My point is that such wording, as above, gave people the impression that jQuery was not javascript and you could not accomplish things in vanilla js. Such false impressions are still around today.


I dunno - I don't think you're gonna win that battle. When a library is sufficiently advanced it often becomes a distinct entity (linguistically, at least) from whatever it's built upon.

See also: React, Pandas, Numpy, Boost, etc.

It might be confusing to those without the context to understand that e.g. React is built on vanilla JS, but I think it's pretty clear to most people that jQuery is built on JavaScript.

In fact the term "vanilla JS" mostly started in response to jQuery itself, so if anything I would argue that the term "vanilla JS" is to blame for what you're talking about.


> by writing your own function just as jQuery did

Sure, and we could all just design our own chips, hand code our own binary to create our custom programming language we use for everything... But humans have a neat ability to benefit from other humans' work.


An attempt to compare writing JavaScript to designing our own chips is a typical response I see from certain individuals online all the time. No knowledgeable person would ever do such a thing but I see it on reddit, and other amateur forums, all the time.


You're making a large and incorrect assumption.

But don't worry, I see this on Reddit and other amateur forums all the time.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

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

Search: