Hacker News Reader

It's also interesting how people have gone backwards in terms of convention. As far I know, there's no standard convention for JavaScript server layouts (maybe server.js, but I've seen stuff in index.js or main.js). Likewise there's no standard way to plug in servers like Rack. Or a standard ORM in the JS world. I figured conventions would come with maturity but the JS world is getting mature and yet there's not many conventions

Rack is cool, but the modern approach seems to be more decoupled web servers. You rarely see multiple business-logic Rack servers in a single process anyway though; Rack servers outside your primary business logic tend to be used more like Express middlewares in Node (which are very conventional at this point).

And the standard entry point for a NodeJS package is "whatever is defined as the main property in your package.json." Do otherwise at your peril.

I found this to be true when building a SPA. On rails I am already told the best place to put things but on the JS side its just "do whatever you want" so I try something and find out later that it wasn't a great way to do things so I am just wasting my time working out the best way to organize a project. I also have to deal with index files that just import every single component for the frontend when on rails this kind of stuff is auto generated.

I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others.

That's actually good to know (or perhaps be reassured on). While key-value stores have their place, I've wondered if the rise of NoSQL in web dev was triggered in part by the widespread move a few years beforehand to ORMs, which trained a generation of developers to look at databases through the lens of object relations rather than table relations. I'm (re-)learning Rails with the Pragmatic Studio's Rail 6 course currently, and reminded of why I liked it -- but in the last few years I've also come to renew my appreciation of pure SQL.

(I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.)

> I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.

Indeed. I'm currently in the process of porting my companies product from Firebase to Postgres. We're making full use of postgres-specific features where that makes sense. I can't see why we'd ever want to switch.

Yeah, that'd be my main argument here. In practice, I'm not sure switching database back ends happens that often once you're actually in production -- and when it does, it's usually moving between back ends that are so different you're going to be doing a lot of rewriting anyway.

I've seen programs switched out on top of databases more often than I've seen the reverse.

Most DBs are much, much better if you commit to them and actually use their features. I dislike the practice of treating them as interchangeable and think it's rarely a good idea.

This was more relevant when many products were like Confluence and JIRA...they would run on prem with the DBA's DBMS of choice.

> and it can only be coming from people who never got to experience the world that was web development before Rails

As someone with experience from many more backgrounds than "old php", my dislike of rails has nothing to do with what you're claiming. Plenty of frameworks have had convention and structure prior to Rails.

That said, I'll admit it does have some good things going for it, even if it wouldn't be my first choice in most cases.

Just wondering, what don't you like about rails?

Mind you, most of my experience is from the rails 3 days plus some legacy application support.

My biggest gripe is the autoloader; it makes finding where something comes from extremely confusing when ramping up new developers on large, mature projects.

The enforced, common convention is a boon and a curse- consistency across projects is an obvious benefit, though I prefer a different structure myself.

Beyond that my gripes are more related to ruby and the tooling rather than strictly with rails itself. Of course you can tweak and configure rails to behave any number of ways, but the more you do that the more you lose out on the primary benefit, which is the community one-true-way mindset.