4 ms·

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

by aantix 6y ago

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?

generalk 6y ago
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.
skohan 6y ago
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.
- generalk 6y ago
  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!
- eightysixfour 6y ago
  > 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.
  - skohan 6y ago
    > 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.
    - zemptime 6y ago
      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.
- aantix 6y ago
  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.

by aantix 6y ago

generalk 6y ago

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.

skohan 6y ago

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.

generalk 6y ago
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!
eightysixfour 6y ago
> 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.
- skohan 6y ago
  > 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.
  - zemptime 6y ago
    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.
aantix 6y ago
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.