15 ms·

"Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using

"Sinatra is Ruby with Rails in mind. You will find yourself using more of Rails in your Sinatra application over time and ask yourself why you're not just using Rails." This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. To riff on Greenspun's Tenth Rule, "Any sufficiently complicated $MICRO-FRAMEWORK application contains an ad hoc informally-specified bug-ridden slow implementation of half of Ruby on Rails."

pankajdoharey 8y ago
I take it back.
- andybak 8y ago
  Sorry. Did you just compare a language to a web framework as if one could be substituted for the other?
  - deleted 8y ago
    [deleted]
- z3phyr 8y ago
  Did you just compare a language to a web framework? Yes you did.
deleted 8y ago
[deleted]
aikah 8y ago
> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...
- gravypod 8y ago
  The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think! You also get a uniformity of understanding of your library and a support network.
  - ryanbrunner 8y ago
    Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.
    - jashmatthews 8y ago
      > I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.
      - Doctor_Fegg 8y ago
        And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).
- matthewmacleod 8y ago
  I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose. That’s not always perfect or suitable for every use case, but it’s not a bad thing.
matthewmacleod 8y ago
Every time - every single time - I have started building an application using Sinatra I have regretted not building it in Rails from the start. I totally understand the desire for a minimal and clean codebase. If I’m not going to use 80% of Rails, why would include it, right? But in practice, I have found there is basically zero cost to using Rails instead.
- rubyfan 8y ago
  I agree, totally true even with some small trivial apps. The few places a Sinatra app have worked for me are highly specialized, single method and generally have been for performance reasons and could have been in any other framework due to them loading as SSI or AJAX call.
- rm_-rf_slash 8y ago
  It’s been a few years since I’ve used Rails, but when I did, it always felt like within a year or two a new version of Rails would come out and I’d basically have to rewrite the site from scratch if I wanted to update. I don’t know if the codebase has stabilized but the transition between 2.x to 3.x to 4.x was pretty rocky from my recollection. Hopefully it’s better, since Rails is probably the best framework to get a site up and running quickly.
  - websitescenes 8y ago
    Since v3 I’ve had no issues upgrading apps to the latest. As soon as a new release is available, I upgrade. V2 to v3 was pretty painful though..
    - rapind 8y ago
      Specifically the change in the default to escape strings and having to specify when you want to pass it through unsafely (html_safe / raw). Broke a lot of v2 apps, but ultimately I think it was definitely the right call. Same thing again when strong_params become the default. So mostly due to security improvements. v2 -> v3 also was the merb merging and a pretty significant rewrite, so it's pretty impressive that we didn't have even more trouble IMO.
onli 8y ago
I think that's totally valid. As web applications grow you run more and more into the need for new features and the need for common solutions, things that Rails already give you. For example, when I wanted to try out jRuby for an application of mine, one point that made that impossible was the existing usage of the sqlite gem. Had I used activerecord I could have moved it over to the jdbc api with a simple added gem, Rails would have set me up for that solution. Or locales: The construction I added into my software basically re-implements how a Rails gem is used. But that's also the value in it: After you constructed a big enough Sinatra application you understand why and how Rails is doing the things it does. I think that's very useful.
sametmax 8y ago
Same with flask and django. And the worst is that the flask version is often riddle with security holes (not flask's fault) that would have been prevented for free. I actually always say that despite the apparent easiness of the micro framwork hello world, you have to actually be very skilled to use them correctly to do anything beyong a few pages. While a full feature framework will make a beginer produce a decent work by default.
- linux2647 8y ago
  What sort of security holes in Flask are you referring to?
  - deleted 8y ago
    [deleted]
  - type0 8y ago
    Maybe that it doesn't sanitize the user input, but calling that security hole is a bit of a stretch. Sure you have the freedom to use some insecure libraries with flask but the same could be said about any framework.
    - sametmax 8y ago
      Django protect you out of the box of xss, csrf, and click jacking while providing you with a proven robust extensible auth mechanism. When using flask, you have to be able to make decisions about those. Many devs are not able to. I'm ok with it: not everybody has to be an expert to be a great element in a company. But flask gives those profile a false sense of easiness.
      - flasker11 8y ago
        Have you ever written a flask app yourself? It provides identical protections against xss etc. that you mentioned, as well as an auth plugin and tutorials on doing auth right... I think it's unfair to spread a negative opinion of Flask because you had to work on an app that used it badly.
spsoto 8y ago
I completely agree! I worked with Rails 2+ years and it was really comfortable that everything I needed was at hand at the moment of scaling the application with new features or requirements. After that, I needed to make some microservices orchestration and NodeJS (using Koa as the HTTP server wrapper) was a better tool to deal with all these asynchronous tasks. But: Routing? Parsing JSON? Storing files in S3? Dealing with databases? Serve some static assets (e.g. Swagger)? Up to you! And good luck finding the up-to-date and standard library for your needs. Overall, using workers, doing asynchronous tasks (e.g. starting a thread after hitting an endpoint) and coding orchestration endpoints (e.g. GraphQL) was a enjoyable experience where you have almost full control of what you were doing, but I still miss those days working with Rails where the community was so helpful in finding a friendly path to dealing with some common problems. My impression is that it feels less fragmented overall. I haven't found myself an ORM as good and expressive as ActiveRecord or Sequel. Overall I think it has to do with all the metaprogramming tools you have available on Ruby. That's something amazing to deal with cookie-cutter problems, but also a problem when you need to do more granular control or get out of the typical CRUD problems.
danpalmer 8y ago
My rule of thumb... ORM, sessions, auth, administration, form validation, template rendering, API infrastructure, static file management, RSS feeds, ... If you think your service will ever need more that 2 of these, use a framework. These will integrate well with each other and save time.
vorpalhex 8y ago
I have worked on a lot of ugly rails apps that would of been infinitely less painful as a thin Sinatra app. Use the solution to fit your problem. Microframeworks for small composable problems. For some reason rails devs see it as the hammer for every nail, screw, bolt, pipe fitting and joint.
jrs95 8y ago
Rails might not be perfect, but there's a 95% chance it'll be better than the custom framework you end up building on Node.
pbreit 8y ago
Is the holy grail of minimal enough to stay out of your way but maximal enough to handle all the common app needs really that difficult to reach?
eropple 8y ago
> If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. I have developed very nontrivial applications with Modern, which can be thought of as Sinatra-like, without regretting the choice or without implementing a bunch of Rails things. The web application is an immutable spec and defined as such; state is offloaded to dependent services pushed into your HTTP action handlers. Done. But, then, in 2018 (or 2016 when I started its predecessor), "an application" no longer required bashing into it ERB templates or the like, so I'll grant that it's a little easier. https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby That said, in the Node world I do use Hapi over Express, as it conforms better to the way I think about things.

pankajdoharey 8y ago

I take it back.

andybak 8y ago
Sorry. Did you just compare a language to a web framework as if one could be substituted for the other?
- deleted 8y ago
  [deleted]
z3phyr 8y ago
Did you just compare a language to a web framework? Yes you did.

deleted 8y ago

[deleted]

aikah 8y ago

> This is an important point. If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. Not really. You want an ORM? choose an ORM library. You want templates, choose a templating library. You want to send mails, choose a mailing library. I don't see how big frameworks like Rails make all these things better, especially when they don't give you the choice as to what tool to use. If you ever developed a non trivial application, you also know that your first concern will be to avoid unnecessary bloat and complexity and only bring in libraries that are strictly required. And as we are moving from traditional html rendered server apps, big frameworks lost even more value since there is no need for a templating libraries, html form libraries,...

gravypod 8y ago
The improvement comes from someone else making all of those decision for you and as long as you completely ignore your design requirements and force your problems into the framework's mold then you're golden! You never actually need to think! You also get a uniformity of understanding of your library and a support network.
- ryanbrunner 8y ago
  Rails is tailored to a particular type of web application, and if your application strays far from this model it's probably not going to be a great fit. I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. The sweet spot that Rails covers, however, is a pretty common sort of web application - one in which you're primarily doing CRUD on different sorts of objects. If you treat every single application as a unique snowflake that needs a 100% bespoke collection of libraries to solve, you'll end up wasting a whole lot of time on architecture and library selection and not a lot of time on solving actual problems.
  - jashmatthews 8y ago
    > I don't think even the biggest Rails zealot would advocate building Google Maps in Rails. Rails excels at being the web layer in this situation. All the heavy lifting is done by the DB to spit back feature structures or do routing and native libraries to do image composition.
    - Doctor_Fegg 8y ago
      And indeed, openstreetmap.org is a Rails site (though key parts of the API have been rewritten in C++ for performance).
matthewmacleod 8y ago
I actually consider Rails in its 3.x+ versions to be a pre-selected combination of smaller libraries - because it really is. Don’t need mail? Remove actionmailer. Don’t need a database? Remove ActiveRecord. The benefit is that when you do need those tools, they are there, they work together, and you don’t have to choose. That’s not always perfect or suitable for every use case, but it’s not a bad thing.

matthewmacleod 8y ago

Every time - every single time - I have started building an application using Sinatra I have regretted not building it in Rails from the start. I totally understand the desire for a minimal and clean codebase. If I’m not going to use 80% of Rails, why would include it, right? But in practice, I have found there is basically zero cost to using Rails instead.

rubyfan 8y ago
I agree, totally true even with some small trivial apps. The few places a Sinatra app have worked for me are highly specialized, single method and generally have been for performance reasons and could have been in any other framework due to them loading as SSI or AJAX call.
rm_-rf_slash 8y ago
It’s been a few years since I’ve used Rails, but when I did, it always felt like within a year or two a new version of Rails would come out and I’d basically have to rewrite the site from scratch if I wanted to update. I don’t know if the codebase has stabilized but the transition between 2.x to 3.x to 4.x was pretty rocky from my recollection. Hopefully it’s better, since Rails is probably the best framework to get a site up and running quickly.
- websitescenes 8y ago
  Since v3 I’ve had no issues upgrading apps to the latest. As soon as a new release is available, I upgrade. V2 to v3 was pretty painful though..
  - rapind 8y ago
    Specifically the change in the default to escape strings and having to specify when you want to pass it through unsafely (html_safe / raw). Broke a lot of v2 apps, but ultimately I think it was definitely the right call. Same thing again when strong_params become the default. So mostly due to security improvements. v2 -> v3 also was the merb merging and a pretty significant rewrite, so it's pretty impressive that we didn't have even more trouble IMO.

onli 8y ago

I think that's totally valid. As web applications grow you run more and more into the need for new features and the need for common solutions, things that Rails already give you. For example, when I wanted to try out jRuby for an application of mine, one point that made that impossible was the existing usage of the sqlite gem. Had I used activerecord I could have moved it over to the jdbc api with a simple added gem, Rails would have set me up for that solution. Or locales: The construction I added into my software basically re-implements how a Rails gem is used. But that's also the value in it: After you constructed a big enough Sinatra application you understand why and how Rails is doing the things it does. I think that's very useful.

sametmax 8y ago

Same with flask and django. And the worst is that the flask version is often riddle with security holes (not flask's fault) that would have been prevented for free. I actually always say that despite the apparent easiness of the micro framwork hello world, you have to actually be very skilled to use them correctly to do anything beyong a few pages. While a full feature framework will make a beginer produce a decent work by default.

linux2647 8y ago
What sort of security holes in Flask are you referring to?
- deleted 8y ago
  [deleted]
- type0 8y ago
  Maybe that it doesn't sanitize the user input, but calling that security hole is a bit of a stretch. Sure you have the freedom to use some insecure libraries with flask but the same could be said about any framework.
  - sametmax 8y ago
    Django protect you out of the box of xss, csrf, and click jacking while providing you with a proven robust extensible auth mechanism. When using flask, you have to be able to make decisions about those. Many devs are not able to. I'm ok with it: not everybody has to be an expert to be a great element in a company. But flask gives those profile a false sense of easiness.
    - flasker11 8y ago
      Have you ever written a flask app yourself? It provides identical protections against xss etc. that you mentioned, as well as an auth plugin and tutorials on doing auth right... I think it's unfair to spread a negative opinion of Flask because you had to work on an app that used it badly.

spsoto 8y ago

I completely agree! I worked with Rails 2+ years and it was really comfortable that everything I needed was at hand at the moment of scaling the application with new features or requirements. After that, I needed to make some microservices orchestration and NodeJS (using Koa as the HTTP server wrapper) was a better tool to deal with all these asynchronous tasks. But: Routing? Parsing JSON? Storing files in S3? Dealing with databases? Serve some static assets (e.g. Swagger)? Up to you! And good luck finding the up-to-date and standard library for your needs. Overall, using workers, doing asynchronous tasks (e.g. starting a thread after hitting an endpoint) and coding orchestration endpoints (e.g. GraphQL) was a enjoyable experience where you have almost full control of what you were doing, but I still miss those days working with Rails where the community was so helpful in finding a friendly path to dealing with some common problems. My impression is that it feels less fragmented overall. I haven't found myself an ORM as good and expressive as ActiveRecord or Sequel. Overall I think it has to do with all the metaprogramming tools you have available on Ruby. That's something amazing to deal with cookie-cutter problems, but also a problem when you need to do more granular control or get out of the typical CRUD problems.

danpalmer 8y ago

My rule of thumb... ORM, sessions, auth, administration, form validation, template rendering, API infrastructure, static file management, RSS feeds, ... If you think your service will ever need more that 2 of these, use a framework. These will integrate well with each other and save time.

vorpalhex 8y ago

I have worked on a lot of ugly rails apps that would of been infinitely less painful as a thin Sinatra app. Use the solution to fit your problem. Microframeworks for small composable problems. For some reason rails devs see it as the hammer for every nail, screw, bolt, pipe fitting and joint.

jrs95 8y ago

Rails might not be perfect, but there's a 95% chance it'll be better than the custom framework you end up building on Node.

pbreit 8y ago

Is the holy grail of minimal enough to stay out of your way but maximal enough to handle all the common app needs really that difficult to reach?

eropple 8y ago

> If you've ever developed a non-trivial application using Sinatra, Express or any other "micro" or "non-opinionated" framework, you'll have hit this wall quickly. I have developed very nontrivial applications with Modern, which can be thought of as Sinatra-like, without regretting the choice or without implementing a bunch of Rails things. The web application is an immutable spec and defined as such; state is offloaded to dependent services pushed into your HTTP action handlers. Done. But, then, in 2018 (or 2016 when I started its predecessor), "an application" no longer required bashing into it ERB templates or the like, so I'll grant that it's a little easier. https://github.com/modern-project/modern-ruby https://github.com/modern-project/modern-ruby That said, in the Node world I do use Hapi over Express, as it conforms better to the way I think about things.