4 ms·

Rails 6 really is a well-rounded update. It seems the new trend goes towards "bare-bones" http servers, but I'm insanely productive in a Rails app, even if it's

Rails 6 really is a well-rounded update. It seems the new trend goes towards "bare-bones" http servers, but I'm insanely productive in a Rails app, even if it's one I have not worked on before. I've seen quite a lot of "Rails-hate" over the last view years, and it can only be coming from people who never got to experience the world that was web development before Rails: Every project had it's own, usually quite creative, structure. There'd be configuration values in `config.inc.php`, but also in `configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by establishing a standard folder structure, DHH probably made web devs everywhere twice as productive. I also think its reputation of being too restricting isn't entirely deserved. As but one example: 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. So here' to hoping for another 6 good releases at least!

_hardwaregeek 7y ago
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
- eropple 7y ago
  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.
- baroffoos 7y ago
  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.
chipotle_coyote 7y ago
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.)
- nicoburns 7y ago
  > 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.
  - chipotle_coyote 7y ago
    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.
    - shantly 7y ago
      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.
zdragnar 7y ago
> 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.
- theworld572 7y ago
  Just wondering, what don't you like about rails?
  - zdragnar 7y ago
    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.

_hardwaregeek 7y ago

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

eropple 7y ago
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.
baroffoos 7y ago
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.

chipotle_coyote 7y ago

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

nicoburns 7y ago
> 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.
- chipotle_coyote 7y ago
  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.
  - shantly 7y ago
    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.

zdragnar 7y ago

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

theworld572 7y ago
Just wondering, what don't you like about rails?
- zdragnar 7y ago
  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.