5 ms·

Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine t

by t4nkd 11y ago

Is this just a really polite, introspective take on (Rails|Ruby) is a Ghetto? I can't point out one really valid critique in this entire rant. While I imagine that you've had enough kool-aid to actually believe the things you said, I think you should probably do a few google searches to find out how many shops are hiring Rails devs versus Clojure or Elixir. You can do more experimenting by seeing who else is actually working those jobs, what kind of professional experience they have, and if you're really lucky figure out what they get paid. Rails needs websockets, just like years ago when it needed a better way to handle organizing and deploying assets. The modern application demands it, and if you've ever had the pleasure of trying to build a websocket application in Ruby you'd understand why it's actually really exciting that we're going to get the Rails community to build this for all of us. If you want to be disenchanted about some aspect of Rails then pick the fact that the need for diversity at RailsConf this year has yielded some of the worst presentations I've ever seen (like, literally, the presenter spoke poor/broken english and the Docker oriented talks were about 6 months behind). Rails moves the way it does and absorbs the ideas it does because they become popular. It's much easier to add a feature that everyone wants, instead of inventing a feature that makes a solved problem that much easier/faster/what-have-you. DHH seems to have to explain this every few years, but go back in time when Rails adopted sprockets and you'll see posts not unlike the one you just wrote. Realistically, Ruby and Rails jobs are still among the highest paying in the industry. Startups and other more established companies still choose Rails as their platform, and not just for bullshit brochure sites. Certainly there remains a "best tool for the job" mentality but, right now, the alternatives are to: build it yourself, hop on a less "mature" framework -- Pheonix? I don't even know what you pick when you adopt Elixir as your platform language and need to build an API or front end apps but Pheonix won the google -- or choose from one of the popular technologies like Express.js, Laravel(?), or Django. That part of building technology (and business) didn't change, and there are still hundreds of thousands of Ruby and Rails engineers out there.

kailuowang 11y ago
> the alternatives are The main competitive alternatives to Rails are single page application frontend frameworks combined with light API focused backend frameworks. Not a single web application framework.
- monsterix 11y ago
  So far from what I've seen is that most frontend frameworks go inside one of the directories inside rails. Nice, clean and tight integration. :)
  - kailuowang 11y ago
    Yes, because having Rails serving the single page application front-end makes total sense.
    - monsterix 11y ago
      Is isomorphic such a bad idea?
    - some1else 11y ago
      The static assets are actually served by nginx. In cases where some page data is dynamically generated by Rails, it's nice to keep both pieces of code together in a mono-repo. That said, when I recently extracted a Backbone app from the Rails codebase (retrofitted Grunt.js), I decided to ditch the public/symlink approach and split the app over 2 subdomains. What I find now is that I like the mono-repo approach, and would be fine with cramming both codebases together, while having granular and global deployment scripts.
    - t4nkd 11y ago
      I actually do this: I ended up leveraging sprockets to get some environment interpolation (like API locations) and easy preprocessing languages (e.g. coffeescript). Also, by doing this, I don't have to make everything single-page. I can build one off pages if I want to (not that it happens much, but, still). Also I get some nice bits for logging, metric agents integrate easily, etc. I realize I didn't need it, but, there really wasn't a down side to using it, except for that some views ended up a little fragmented when using angular templates in public/ versus actual views... Even then, it was a decent learning experience and I'd probably do it again just for the interpolation and sprockets asset building.
deleted 11y ago
[deleted]
makeitsuckless 11y ago
> Startups and other more established companies still choose Rails as their platform As far as I can tell, this process has come to a grinding halt in the past few years. I certainly see established companies ditching Ruby, not so much because of the language or framework itself, but because of the community that only seems to be able to solve problems "the Rails way", even if that's far from the most appropriate architectural solution. It's shocking how many Ruby developers are architecturally ignorant about anything not applied by Rails, and it's biting many companies in the ass.
- monsterix 11y ago
  > this process has come to a grinding halt in the past few years. No it has not. In fact there has been more elaborate work done inside of rails (and django/python) than ever before. Actually 'Rails is dying' rant has been going on for years! Almost like cold war propaganda. The only thing that will cease to exist is the war.
- integraton 11y ago
  Frankly, I'm surprised anyone would still make comments like yours after all these years. Comments like this probably peaked in 2008-2009 ("Rails can't scale" was even earlier) after the zed shaw article and there was a bunch of hype about everyone supposedly moving to Django and how Rails was supposedly dead, yet that didn't happen then, or any of the other times. The reality is that lots of companies have been and continue to be created around Rails applications. An AngelList job search focused on server-side technologies currently returns 1267 startup results for "rails" while "node.js" returns 832, "node" returns 854, "django" 434, "python" 1461, "flask" 69, "go" 441, "php" 1192, and "Java" 3163. JavaScript has become bigger, and it hasn't killed Rails on the server. Java remains huge, and it hasn't killed Rails. Python, Django, and Rails have roughly the same relationship as they did back in 2009. A lot of very smart people who have extensive experience with many technologies choose Rails for new projects for very good reasons, this has been the case for the 10 years people like you have been making the same FUD-filled comments, and it will likely continue to the be the case for some time.
  - 11y ago

by t4nkd 11y ago

kailuowang 11y ago

> the alternatives are The main competitive alternatives to Rails are single page application frontend frameworks combined with light API focused backend frameworks. Not a single web application framework.

monsterix 11y ago
So far from what I've seen is that most frontend frameworks go inside one of the directories inside rails. Nice, clean and tight integration. :)
- kailuowang 11y ago
  Yes, because having Rails serving the single page application front-end makes total sense.
  - monsterix 11y ago
    Is isomorphic such a bad idea?
  - some1else 11y ago
    The static assets are actually served by nginx. In cases where some page data is dynamically generated by Rails, it's nice to keep both pieces of code together in a mono-repo. That said, when I recently extracted a Backbone app from the Rails codebase (retrofitted Grunt.js), I decided to ditch the public/symlink approach and split the app over 2 subdomains. What I find now is that I like the mono-repo approach, and would be fine with cramming both codebases together, while having granular and global deployment scripts.
  - t4nkd 11y ago
    I actually do this: I ended up leveraging sprockets to get some environment interpolation (like API locations) and easy preprocessing languages (e.g. coffeescript). Also, by doing this, I don't have to make everything single-page. I can build one off pages if I want to (not that it happens much, but, still). Also I get some nice bits for logging, metric agents integrate easily, etc. I realize I didn't need it, but, there really wasn't a down side to using it, except for that some views ended up a little fragmented when using angular templates in public/ versus actual views... Even then, it was a decent learning experience and I'd probably do it again just for the interpolation and sprockets asset building.

deleted 11y ago

[deleted]

makeitsuckless 11y ago

> Startups and other more established companies still choose Rails as their platform As far as I can tell, this process has come to a grinding halt in the past few years. I certainly see established companies ditching Ruby, not so much because of the language or framework itself, but because of the community that only seems to be able to solve problems "the Rails way", even if that's far from the most appropriate architectural solution. It's shocking how many Ruby developers are architecturally ignorant about anything not applied by Rails, and it's biting many companies in the ass.

monsterix 11y ago
> this process has come to a grinding halt in the past few years. No it has not. In fact there has been more elaborate work done inside of rails (and django/python) than ever before. Actually 'Rails is dying' rant has been going on for years! Almost like cold war propaganda. The only thing that will cease to exist is the war.
integraton 11y ago
Frankly, I'm surprised anyone would still make comments like yours after all these years. Comments like this probably peaked in 2008-2009 ("Rails can't scale" was even earlier) after the zed shaw article and there was a bunch of hype about everyone supposedly moving to Django and how Rails was supposedly dead, yet that didn't happen then, or any of the other times. The reality is that lots of companies have been and continue to be created around Rails applications. An AngelList job search focused on server-side technologies currently returns 1267 startup results for "rails" while "node.js" returns 832, "node" returns 854, "django" 434, "python" 1461, "flask" 69, "go" 441, "php" 1192, and "Java" 3163. JavaScript has become bigger, and it hasn't killed Rails on the server. Java remains huge, and it hasn't killed Rails. Python, Django, and Rails have roughly the same relationship as they did back in 2009. A lot of very smart people who have extensive experience with many technologies choose Rails for new projects for very good reasons, this has been the case for the 10 years people like you have been making the same FUD-filled comments, and it will likely continue to the be the case for some time.
- 11y ago