5 ms·

I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different pr

I work on a Rails system. It's fine. Just like everything else is fine. I have problems, but I have problems with everything else too (sometimes different problems, but not always...). I think my main complaint about Rails is that it's pretty heavy weight. Lately we did a Sinatra app because we didn't really need anything that rails was giving us. Fairly quickly I realised that I didn't need anything that Sinatra was giving us either. Rack was fine. I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning. It's just the nature of the beast. From there it's more of a training issue than anything else. You can hire "Rails developers" (or whatever developers), but you can't hire people who are specifically trained in a system you've built. Depending on the kinds of developers you hire, this may or may not be a problem. Personally, I like writing code and I like small, light systems that are easy to move around in. Usually that means trying to avoid large frameworks. However, not everybody I've worked with is comfortable with that experience, so normally we pick things people have worked with before. Either way it's not a big deal in the end.

_hardwaregeek 8y ago
I've found it kinda weird how Rack isn't emphasized in the Rails tutorials. It's really one of the crown jewels (heh) of the Ruby ecosystem. I suppose Rails wants to abstract away all the nitty gritty request based stuff but it's really powerful if you know how to use it.
- Kalium 8y ago
  You're absolutely right. Rack is incredibly powerful! Might it be possible that there is a subtle catch in "if you know how to use it"? The more powerful a tool is, the more potent a temptation it can present to those who might understand what Rack can do but who could perhaps also stand to possess a greater degree of wisdom in considering what the right tool is. A small number of very experienced, wise, and deeply skilled developers can be trusted to use their tools well - yet this may not describe all possible scenarios. Again, you're completely right. Rack is vastly powerful and immensely useful. Yet perhaps there might be good reasons for not quickly introducing people to all the glory and power of Rack.
danmaz74 8y ago
Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.
- thrownaway954 8y ago
  "more error prone and less safe" right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.
  - sheeshkebab 8y ago
    Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend. In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
  - klodolph 8y ago
    CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default. XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway. This was a big reason to use frameworks in past days, though.
- imtringued 8y ago
  I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.
louiskottmann 8y ago
Well, to take on the other side of the coin: Would you like to work on a custom-built project of someone else, decent-sized, in a language you grasp poorly? Because that's what your "small, light system, out of large frameworks" will look like to someone who dabbles in ruby/rails and looks for a job (most of the force never reaches mastery, let alone wants to).
- pmontra 8y ago
  That's not good even if somebody is very proficient in the language. Custom projects not founded on some fairly common framework are always a nightmare. Business owners should forbid developers to go that route unless they have a permanent in house development team. And still, it should be the exception, not the rule.
gumcreme 8y ago
Well framed and this is what we all learned and moved to: There are new paradigms out that just make so much more sense and which are followed by the majority. When I read the original submission, I mean just the title, I was facepalming in my mind. Rails had its time and there were reasons why people liked it. But when I see that people post that Rails is still great in 2019, I'd like to stress following issue because those people might confuse newcomers who have to decide which ecosystem they gonna join. The problem is that being in a big or biggest and still growing ecosystem makes life much easier. Once an ecosystem is on the decline you get less good libs or libs are not actively maintained anymore and the best people who shape tech are also moving to new ecosystems. I don't want to bash Rails but just an example, I didn't see any proper http/2 support in Rails-land. Now, you could say who needs http/2 (it makes a huge difference btw). But the point is that it arrived in one of the biggest ecosystem just recently and not every lib there supports it out of the box. And that's just one of many examples. People repeat that Rails has so mature 'gems' but I don't see a lot of new stuff or a big variety, tech moved on but without Rails. Just accept it. The real problem behind all these discussions and threads. Imagine there was a time, where Rails-guys were rare and Rails was the biggest thing. I had to pay such guys $200,000/yr (8yrs ago and not in the valley), not because they were outstanding. Actually, there were average, they were ok in Rails but missed a lot of other checkboxes (often devops or SQL). But the market demand forced us to pay such salaries. Rails brought them a good life and imagine demand was declining, so they had to get into other tech, start again at zero or smaller salaries OR went to forums and rant/try to convince people why Rails is so great.
- jashmatthews 8y ago
  > proper http/2 support in Rails-land Between early hints support in Rails 5.2, nginx proxying to HTTP2, and an http2 enabled CDN what's actually missing?
  - gumcreme 8y ago
    ngninx supporting http/2 != Rails supporting http/2 Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.
shay_ker 8y ago
Did you try Rails API? It's usually a good replacement for Sinatra apps.
sergiotapia 8y ago
Which highlights one of the bigger problems with Rails, your app _is_ Rails. In frameworks like Phoenix your application is a separate entity, completely ignorant of whatever UI framework you're using to talk to users.
jakelazaroff 8y ago
> I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning. I agree with this, but I end up at the opposite conclusion. This post about JavaScript frameworks [1] by Tom Dale puts it nicely: > I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code. [1] https://tomdale.net/2015/11/javascript-frameworks-and-mobile-performance/ https://tomdale.net/2015/11/javascript-frameworks-and-mobile...

_hardwaregeek 8y ago

I've found it kinda weird how Rack isn't emphasized in the Rails tutorials. It's really one of the crown jewels (heh) of the Ruby ecosystem. I suppose Rails wants to abstract away all the nitty gritty request based stuff but it's really powerful if you know how to use it.

Kalium 8y ago
You're absolutely right. Rack is incredibly powerful! Might it be possible that there is a subtle catch in "if you know how to use it"? The more powerful a tool is, the more potent a temptation it can present to those who might understand what Rack can do but who could perhaps also stand to possess a greater degree of wisdom in considering what the right tool is. A small number of very experienced, wise, and deeply skilled developers can be trusted to use their tools well - yet this may not describe all possible scenarios. Again, you're completely right. Rack is vastly powerful and immensely useful. Yet perhaps there might be good reasons for not quickly introducing people to all the glory and power of Rack.

danmaz74 8y ago

Having worked with many different languages and frameworks over the years, I have to disagree: when creating web applications, starting from scratch or from a minimal base is massively slower, more error prone and less safe than starting from a well developed and maintained framework, where so many of the things you're going to need have already been solved and battle tested.

thrownaway954 8y ago
"more error prone and less safe" right there... if I could vote you up a thousand times, I would. I can place a bet that most home grown apps have no security measures against CSRF or XSS in place.
- sheeshkebab 8y ago
  Most modern apps use api/json based endpoints where csrf is not needed (cookies are no longer used for auth) and xss is massively simplified since html is rarely returned by backend. In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
- klodolph 8y ago
  CRSF is not an issue for JSON API endpoints, since cross-origin requests are disabled by default. XSS in my experience is best solved by a reasonable templating language. The same way you don't use string concatenation to insert user data into HTML documents, you don't use string concatenation to insert user data into SQL queries. Frameworks don't add anything here that you don't already have, and a lot of frameworks let you choose your templating system anyway. This was a big reason to use frameworks in past days, though.
imtringued 8y ago
I prefer frameworks but sometimes there is a lack of fine grained escape hatches. Feature X covers 99% of the things I need. To get to 100% I have to stop using feature X and do everything myself. The solution to this problem is to make feature X more flexible, not to rip out the rest of the framework too.

louiskottmann 8y ago

Well, to take on the other side of the coin: Would you like to work on a custom-built project of someone else, decent-sized, in a language you grasp poorly? Because that's what your "small, light system, out of large frameworks" will look like to someone who dabbles in ruby/rails and looks for a job (most of the force never reaches mastery, let alone wants to).

pmontra 8y ago
That's not good even if somebody is very proficient in the language. Custom projects not founded on some fairly common framework are always a nightmare. Business owners should forbid developers to go that route unless they have a permanent in house development team. And still, it should be the exception, not the rule.

gumcreme 8y ago

Well framed and this is what we all learned and moved to: There are new paradigms out that just make so much more sense and which are followed by the majority. When I read the original submission, I mean just the title, I was facepalming in my mind. Rails had its time and there were reasons why people liked it. But when I see that people post that Rails is still great in 2019, I'd like to stress following issue because those people might confuse newcomers who have to decide which ecosystem they gonna join. The problem is that being in a big or biggest and still growing ecosystem makes life much easier. Once an ecosystem is on the decline you get less good libs or libs are not actively maintained anymore and the best people who shape tech are also moving to new ecosystems. I don't want to bash Rails but just an example, I didn't see any proper http/2 support in Rails-land. Now, you could say who needs http/2 (it makes a huge difference btw). But the point is that it arrived in one of the biggest ecosystem just recently and not every lib there supports it out of the box. And that's just one of many examples. People repeat that Rails has so mature 'gems' but I don't see a lot of new stuff or a big variety, tech moved on but without Rails. Just accept it. The real problem behind all these discussions and threads. Imagine there was a time, where Rails-guys were rare and Rails was the biggest thing. I had to pay such guys $200,000/yr (8yrs ago and not in the valley), not because they were outstanding. Actually, there were average, they were ok in Rails but missed a lot of other checkboxes (often devops or SQL). But the market demand forced us to pay such salaries. Rails brought them a good life and imagine demand was declining, so they had to get into other tech, start again at zero or smaller salaries OR went to forums and rant/try to convince people why Rails is so great.

jashmatthews 8y ago
> proper http/2 support in Rails-land Between early hints support in Rails 5.2, nginx proxying to HTTP2, and an http2 enabled CDN what's actually missing?
- gumcreme 8y ago
  ngninx supporting http/2 != Rails supporting http/2 Depending on the use case you leave out nginx sometimes, eg. when doing microservices. Not that nginx is bad but with other stacks you very often don't need nginx and/or connect directly to the CDN reducing complexity in a stack.

shay_ker 8y ago

Did you try Rails API? It's usually a good replacement for Sinatra apps.

sergiotapia 8y ago

Which highlights one of the bigger problems with Rails, your app _is_ Rails. In frameworks like Phoenix your application is a separate entity, completely ignorant of whatever UI framework you're using to talk to users.

jakelazaroff 8y ago

> I think especially after your app gets to be a certain size, you are either writing your own framework, or fighting with the framework you chose at the beginning. I agree with this, but I end up at the opposite conclusion. This post about JavaScript frameworks [1] by Tom Dale puts it nicely: > I have heard from many developers who have told me that they accepted the argument that vanilla JavaScript or microlibraries would let them write leaner, meaner, faster apps. After a year or two, however, what they found themselves with was a slower, bigger, less documented and unmaintained in-house framework with no community. As apps grow, you tend to need the abstractions that a framework offers. Either you or the community write the code. [1] https://tomdale.net/2015/11/javascript-frameworks-and-mobile-performance/ https://tomdale.net/2015/11/javascript-frameworks-and-mobile...