Why I believe Rails is still relevant in 2019
devbrett.com
devbrett.com
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.
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.
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.
In other words most web frameworks that help with rendering html on the server and writing forms to database are not needed either.
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.
Rails raised the bar for how little custom configuration should be necessary to do a simple, straightforward thing. But it turns out being a framework is not integral to that; modern libraries have been able to adopt the "opinionated" (which seems to be just a fancy term for having sensible defaults) approach of rails without having to grow into all-encompassing frameworks.
Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.
That's why I'm such a fan of TurboGears - it's an easy starting point, but as soon as you want to step up to making your own library choices it's trivial to do so. I think the key insight is that no-one ever wants to go back to upgrading all of their different libraries in lockstep; a "platform" of libraries that are versioned together is a good starting point but at a certain point in the project lifecycle you want to unlock from that and after that trying to go back to the platform is only ever going to be pain.
This isn't the better alternative to frameworks.
The better alternative is using libraries and optionally a bootstrap code generator, which is not at all "starting from scratch".
The major difference is that you tell the libraries how to work together, rather than the framework telling you how to work.
Some frameworks become like a terrible DSL that you could never translate back into idiomatic code.
Doesn't this just become a bunch of decisions and team cognitive load you have to deal with?
The team architect should set up the project structure, not a committew. Most languages have idiomatic conventions for writing framework-less code, so it's not going to look totally unique when they're done.
If you need the best library for the job, you can spend as much time as you like picking one. It's a matter of restraint to simply not spend that effort, and instead just pick a library because it meets your needs (without spending more than a moment evaluating whether it is better or worse than alternatives).
I was specifically answering to the remark from the what was at the time the top comment, saying that starting from Rack is the best approach.
Because every web app is the same CRUD app, right?
Things evolved the last years, I build you any app as fast and create more maintainable code with my stack which consists of small libs than any Rails dev. Don't forget that also a lot of work moved to the front-end, so your daddy's Rails won't help you on that anymore. Web apps are not developed like ten years ago.
I think it was Alan Kay who summed it up best: If your team is capable of building a compiler, you must build a compiler. If your team is not capable of building a compiler, you must not build a compiler. That matches my experience exactly ;-)
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).
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.
Between early hints support in Rails 5.2, nginx proxying to HTTP2, and an http2 enabled CDN what's actually missing?
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.
What is a standard setup in 2019, there is none? There is also no standard in using nginx as front facing entity.
In my prior comment I was friendly and gave an example why some might not have nginx in their stack and BTW the discussion is about Rails lacking http2 and you try to convince me that this is expected and right.
This is pure ignorance paired with incompetence, maybe in your small world things work this way. Let's just stop here and go back to your legacy stack.
This is why nobody is rushing out to rewrite Rack to support HTTP2. Ruby web apps already benefit from almost all of the advantages of HTTP2.
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...
I've seen a Rails app handle Cyber Monday traffic for an ecommerce company just fine, and I've seen JVM-based apps crumple under a fraction of the load.
Rails scales (see, that actually rhymes, so it must be true), Ruby is a really nice language to work in, and those things will remain true regardless of whatever frameworks exist or whatever earworm sayings stick in the minds of the next generation of developers.
I think a whole lot of developers choose technologies because they are popular at the moment for two reasons: they lack the technical knowledge and experience or maybe just confidence and/or they avoid some responsibility this way (since everyone is doing it).
Of course this is most acute in web development because it attracts younger developers.
Also the words performance and scalability attracts developers like moth to a flame.
I know 2 COBOL programmers who are being paid a ton of money because of critical banking systems running it and candidates are hard to find.
Additionally a majority of the remote jobs I've seen have been Ruby as well. So despite it not being hip. It is still very much a requirement.
However, the caveat of course is that if you blindly choose something just because it’s popular, or in spite of your own skepticism towards it because you let the hype get to you, then it is very much possible that you end up using something that is unfit for what you are trying to do and which even though someone else has used it for the same purpose is going to lead you to implement something that has poor performance, is too inflexible and/or has other undesirable properties.
But really, the proper way to choose frameworks and libraries is to look at the docs themselves and benchmarks and make your decision based on that. Not to lazily use popularity as a proxy for estimating suitability/ease of use.
It also seems like 'boring = popular & old', 'hype = popular & new'.
Yes but this holds true for something older that was popular at some other time (like Rails) and is no longer as widely promoted. Those are way safer choices.
Your post is a bit misleading. Rails can scale but to get there is different than with other stacks. Some would say, it's much more challenging or complicated, some would call it just a PITA and if you really, really want to scale, like e.g. a porn site, Rails is the worst choice you could ever take. Or you would just completely rewrite it but what is then the motivation to take a framework? Maybe frameworks are wrong...?
However, I think dev productivity is more important since scaling is a requirement which is very often not needed and introducing it too early is just premature optimization.
Still, I dislike if people spread false information. Rails can scale to a certain (limited) degree but it never was easy, just the deployment then without Docker was a big mess (I didn't know one Rails guys who could deploy anything without Heroku).
There are some podcasts and keynotes where DHH talks about their stacks.
Combined with the mature gem ecosystem and clear mechanics for putting everything together, I was up and running immediately, and was able to continue adding features and refining without issues.
To my knowledge tho, I do believe those are the only 2 framework that offer so many plug-and-play, trustable component for everything, allowing you to be up and running so fast.
I've built similarly large systems both with rails, flask and nodejs. Nodejs environment was definitely the worst, on every front, and I coming back to something like Rails always feels like I have so much more power.
Hence I have generally stuck to using Flask and just quickly building a custom version of any component that doesn't directly cause any security issues. Thoughts? Am I wasting my time ?
To answer your question: you're probably wasting customer's money (unless you're the customer) by implementing your custom components. You should use as many existing components as you can find: they are probably better engineered (dozens of teams at work vs one person - that included bug reports), better documented and maintained and will live longer. Then you have to adapt much like we adapt buying stock cloths, furniture, etc. But it's cheaper, faster to deliver and usually good enough.
The difference is felt especially when doing basic stuff that most web app needs such as auth, routings, request/response parsing/building, etc.
Even for things like user authentication system with session management, etc. in Rails with Devise you add Devise to your gem file (1 loc) then run `rails generate devise:install` and you basically have an auth system with sessions, login, etc. We are talking a few minutes and boom, your app has a fully auth system.
asp.net? I'm asking because I don't know.
I suspect that the JS world being always in a state of flux doesn't help reaching that goal.
something you don't need anymore with a modern stack
> an upload manager, and BI tool
standard stuff every other ecosystem has
> mature gem ecosystem
missing essentials like stable http/2 and full of unmaintained gems
An asynchronous worker manager is helpful for handling cron jobs, mail tasks, and various batch processes that can be loaded into memory (mostly Redis) but processed later.
I use the gem Sidekiq which, as is, provides a UI and API that I rely heavily on. I might just not know the best practices, but I definitely find this valuable.
The BI tools are not something found in most ecosystems. Not to mention dead simple setup. I use two gems, Ahoy and Blazer, which together provide a simple API for event tracking and saving database queries.
[1]: https://sidekiq.org/
I am on mobile and don't have time to write down why, please just go to StackOverflow and ask people why something like Sidekiq is not needed in stack x.
I've since moved to using Elixir and Phoenix, and then even more recently, done some consulting on a Rails project. So the contrasts are on my mind.
My perspective now is that the advantages Ruby/Rails have over Elixir/Phoenix (community size and number of libraries) are circumstantial, and the advantages Elixir/Phoenix have (fault tolerance, concurrency, speed, less requirement for external tools) are inherent in the VM.
Yes, speed of development and maintainability matter. And yes, you can write good or bad code in any language. But if Rails taught us anything, it's that defaults matter. And the default pattern in Rails is to use ActiveRecord and rely heavily on model callbacks, which can get confusing quickly. ActiveRecord also has no way to turn off lazy loading as far I know, and chasing down N+1 queries to improve performance is something I spent far too many hours doing.
My productivity also wasn't helped by the long test run times of Rails applications, or by wasting time trying to optimize view rendering on a heavily-used page.
All of those are either non-issues for me now or at least greatly reduced - Phoenix view rendering is crazy fast, N+1 queries aren't possible with Ecto and it doesn't have callbacks, Elixir test suites are highly concurrent and generally fast (though driving a headless browser is still rather slow).
Performance and concurrency do impact productivity. And I find that "functions in modules" is a great way to structure code and makes it easy to refactor. So does being able to run the entire test suite faster than I can get distracted.
The best ideas of Rails, in my opinion, are present in Phoenix - things like structural conventions, English-like naming, and database migrations. But many of the pain points are missing.
Phoenix and Elixir aren't the One True Way™, aren't the best for every conceivable software problem, etc. And surely they'll be superseded. But in my opinion, Rails already has been.
EDIT: After looking more into your claim that "N+1 queries aren't possible with Ecto", I think I have a better idea for what you might mean. Perhaps you don't want everything eager loaded, but you want an exception to be raised if you try to access an associated record that hasn't been preloaded. I suppose that's a fair point (probably good practice if having any N+1 queries will be a major problem in your project, or if subpar performance really is your biggest threat), and no, I don't know of a way to do that in AR.
Yes, exactly.
> When I need to load/use them along with many parent records, it seems pretty obvious that I'll want to include those associations (eagerly loaded) in my AR query to avoid N+1 queries as you mentioned. Then again, maybe I've just spent too long taking those assumptions for granted where newer devs might not.
You know that and I do too, but legacy Rails apps tend to be full of N+1 queries in my experience, and it's a major cause of slowdowns.
https://semaphoreci.com/blog/2017/08/09/faster-rails-elimina...
https://github.com/flyerhzm/bullet
EDIT: It looks like this was already mentioned in another thread. I guess I don't understand the issue if that doesn't solve your problem.
My higher-level problem is that having lazy-loading on by default allows N+1 queries to creep in to a code base and you need a third-party gem to find them. I've had to spend significant time finding and fixing this after joining teams with large legacy apps.
"Disable lazy loading globally" should be an ActiveRecord setting and it should be on by default IMO; people who need lazy loading should have to turn it on per query, something like `query.allow_lazy_loading(post: :author)`. I suspect that a very small fraction of queries would use this, since many apps don't do server side rendering, many who do SSR don't use Russian doll caching, and even those who do both still execute many queries that should prefetch all the associations they use.
Just an FYI for any Rails dev reading this, the Bullet gem is excellent for pointing out n+1 queries.
I want my cache key to be lean, only fetching one record without its associations, because if the data is cached, I don't need any further queries anyway. If I "fix" my N+1 queries and load all associations, I actually negate the benefits of the nested caching and incur a cost I can avoid.
I know it sounds like I keep beating the same drum, but to me this problem seems like "we have slow views, therefore we need to sprinkle conditional caching logic everywhere, therefore we need to allow lazy loading, therefore we need to watch for N+1 queries."
As I wrote elsewhere (http://nathanmlong.com/2016/11/elixir-and-io-lists-part-2-io...):
> By contrast, by compiling templates to functions, Phoenix automatically and universally applies this simple view caching strategy: the static parts of our template are always cached. The dynamic parts are never cached. The cache is invalidated if the template file changes. The end.
With fast views, no lazy loading is needed and no N+1 queries need to be possible. I don't think this is a problem inherent to Ruby, just to the way ActionView and ActiveRecord currently work.
I always assumed caching is a necessary evil if you want to speed things up.
I certainly feel like rendering views is rails is slower than I'd like it to be (talking about the rendering part alone), especially with partials.
How do you deal with views that pull dynamic data that produce a heavy query however?
I don't think the view rendering itself would ever be a performance issue, but rendering a view is just a function call in Phoenix, so I could take a similar approach there - store it in a GenServer.
I see a lot of Nodejs project struggle and reinvent things that people in Rails community take for granted. Like Nuxt.js for example.
If you don't have to write code to deal with the computer pausing your unix process to run a different one, and you don't have to write code to deal with the VM pausing your code to run garbage collection, why would you have to explicitly write code to deal with a pause for IO?
Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't. Rails and .NET will live longer than us.
I'm not sure why you feel like you need to demean my experience to discuss this. Callbacks are extremely commonly used in Rails apps and not at all the province of Rails newbies. Here's DHH in 2018 telling you about how Basecamp uses callbacks: https://www.youtube.com/watch?v=M3JPTOTqsnE
And even if you don't like callbacks and never use them, at some point you're going to change jobs or consulting clients and land in a code base that's full of them.
> Elixir is hot, but it's hard to learn and will always have a barrier to entry that Rails won't.
Maybe so. I can't predict to what extent it will catch on, but it's paying my bills. If I get to stay in a happy little niche, that will be fine with me.
I think you are missing the forest of the trees, regardless of whether or not the success of rails is circumstantial, the fact remains that Rails is in the lead position because you can build a business on top of it.
It is a solid, battle tested, mature framework that one can use and scale it (up to a certain point) and beyond that, it might get harder but scaling is never easy and I am sure you would agree that Phoenix is not a magic bullet when it comes to scaling.
Again,I don't have to recount the number of services built on rails that thousands of people depend on today: Shopify, Github, Gitlab,..
Us engineers think the only thing that matters is your rendering time.. but it's not , the main thing that execs care about is the bottom line and how fast we can push products to production.
All that being said, I agree that Phoenix is great but let's not kid ourselves, we are here to make cash first and foremost.
To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.
I can understand how you might feel that way. I tried to make clear that I don't think it's the perfect answer to everything forever, but to specify ways in which I've personally seen it as an improvement. And given that the OP is about the continued merits of Rails, don't you expect some commenters to express disagreement?
> the main thing that execs care about is the bottom line and how fast we can push products to production
True. But that matters not just on day 1 but for years to come. Sandi Metz in the Ruby community teaches that point well.
I've seen Rails patterns like ActiveRecord callbacks lead to buggy, confusing code, greatly hindering progress on feature work and requiring significant debugging effort.
Certainly lots of businesses have succeeded with Rails, and I've worked for some of them. Lots of businesses have succeeded with Python, Java, .NET, PHP, and Node, too. That in itself doesn't argue for which one to pick when starting a new project.
After experiencing difficulties with my Ruby tech stack, I started looking around, and Elixir is where I landed. At this point I'm invested and biased, just as the OP is. But bouncing back and forth between the languages recently has confirmed for me that I prefer Elixir for the reasons I gave above.
> To any young devs out there, I strongly encourage you to not pick a framework by its hype but evaluate it based on your system needs / maturity.
I'd suggest young devs pick tools based at least partly on job postings, and on that measure, Rails will win by a landslide. But keep your ear to the ground. When I started as a developer, I was using PHP, but I kept hearing how Rails was better. Learning it and moving to work in it was a great career move for me.
Something will come after Rails. Something will come after Phoenix. There will always be a new something. Don't get too caught up in the hype, but don't get too attached to your current tools, either.
The amount of projects I have seen go bad because someone did a bad job of solving some problem that would have been a non issue in Rails is staggering.
Personally I think Spring Boot with Kotlin is a way better choice today for monoliths that transition well to micro services. But if you're already deep in the RoR world just go with that.
Running into stack or framework-related scaling problems is an honor and a huge accomplishment. Those are good problems and there are many ways to solve them, which will be extremely motivating at that point because people are actually using your thing.
What do you use for an ORM in this case? Is there anything comparable to ActiveAdmin?
I've found Admin interfaces on the same server to turn into liabilities and infosec in bigger orgs usually has strict rules around segregating admin access off into its own subnet with restricted access only to internal traffic.
That said, for simple monololiths I use Jhipster, which auto generates Admin pages for you similar to ActiveAdmin.
Then you need a bare minimum of mapping code. Mostly this boils down to a single line of code to call the relevant constructors while you extract columns from your rows in a type-safe way. Kotlin makes this stupidly easy. I'd argue this type of code is actually easier to maintain than misc annotation cruft all over your codebase. One way or another you end up expressing in some place that column foo is of type Int and goes into some property of a class MyLovelyFoo with a foo field. So MyLovelyFoo(foo=row.getInt("foo")) kind of does that in a really compact way and there's not a lot more to it. Of course Kotlin having default arguments, sane property handling, immutable data classes, etc. helps a lot. Mostly ORM made sense when people were doing JavaBeans on Java.
The problem with many Java persistance frameworks is the amount of magic that happens that leads to hard to understand bugs, sub optimal joins, and other stuff that just isn't worth having. A side effect of using an ORM is also overengineered table structures because people are pretending they are doing OO and thus end up with way to many tables and columns, fragile and more frequent migrations, and a lot of silly joins. This magnifies all of the above problems.
If you know what you are doing, you can actually fix this of course and do it properly even while using an ORM like hibernate. At this point you lose most of the advantages of using an ORM because now you are knee deep into framework complexity and trying to coerce it to do the right thing while spending disproportionate amounts of time inspecting and guiding all the magic it does for you. I've been parachuted in more than a few hibernate projects gone bad. The fix is always pruning back all the copy paste annotation magic propagated by juniors, vastly cutting down on the number of model classes, use of inheritance and the silly hacks that come with that, fixing the transactionality, etc.
It gets out of the way and is very low-level, but it still allows you to build type-safe SQL instead of having to randomly concatenate strings in order to build your query.
This is especially useful if you have dynamic joins and things like that, which can get hairy fast if you're building them manually.
Often long queries with convoluted joins are a good sign something is wrong with your table layout. ORM lets you get away with some bad design but it always catches up with you eventually.
Hibernate is quite powerful and the tooling in IntelliJ (or Eclipse) catches many common mistakes at edit time. Where most folks get themselves into trouble is with all the caching setup. Not surprising, but if you want to just use Hibernate as a cache-less mapper there's always the StatelessSession interface.
I also don't get the oft-repeated notion that ORMs result in bad table design. You can map any tables you can dream up. And if you insist on doing inheritance, Hibernate has 4 different strategies for mapping to classes. Certainly one of those has the performance characteristics you're looking for.
https://github.com/marmelab/react-admin + a GraphQL backend gets really close.
The problem with Spring isn't that it's badly developed (it isn't, and usually gives you good diagnostics, though your stack traces gets spoiled with Spring's ugly-as-sin reflection shite). The problem is that there are people who think Spring has a reason to exist in the first place. Spring Boot is a config framework on top of the Spring framework to make it bearable - that alone should tell you to stay away from it.
Grails has its own ORM called GORM, which can use several different backends like Hibernate/MongoDB
Groovy is a great language, with the best from dynamic languages and yet still very similar to Java. I would say there is no learning curve for Java developers with Groovy.
Grails has also been highly optimized the last few years and runs great on systems with 1 vcpu and 256MB RAM. Grails also has a great and friendly community, come and say hello in our Slack channel https://grails-slack.cfapps.io/
We now stick to plain old Java with no annotations, Ratpack, jOOQ, etc.
In my experience, and opinion: Lack of static typing is a good way to make shooting yourself in the foot easy. Annotation-driven magic sucks. Just Writing Queries causes fewer headaches than using an ORM. Basically, libraries over frameworks. YMMV.
One thing though, with Groovy you can choose between dynamic and static typing. These days everyone agrees that you should use static typing with Groovy as much as possible. Use dynamic typing when static typing becomes hard, for example when working with JSON objects.
And Hibernate is really flexible with how close you get can native queries, the documentation however is not convenient there. But Hibernate developers like Vlad Mihalcea is working hard to document how you can do this and is writing blog posts and answering questions on Stack Overflow. I am really grateful for the effort he puts in helping everyone.
Like any language/framework, it has its warts and its weirdness. There are times when it can be very frustrating to deal with it all. But I've felt that feeling working across multiple paradigms, and I'm convinced it's just a reality of software development.
If you're deep into microservices, Rails can be a tough choice, I'll admit. It really depends on your use case. A small-medium sized startup can get a lot done with just a Rails app if your workload is primarily IO based.
Personally, I feel that the latest trend toward heavy javascript front ends that are more or less detached from the middle tier or back end has led to a wildly overblown, over engineered state of constant technical churn. I quit web development over this. I got involved in a project for a while, but finally decided that if I had to write javascript in these constantly changing frameworks, I didn't want to be a web developer anymore.
Fortunately, I have enough of a math and engineering background and work experience that I was able to move over to writing code for answers more than for applications, though code for answers can be used as a wing of an app. I largely stay out of the framework now.
But I use python, not surprisingly. Ruby is a nice language, and Rails is an excellent framework. I think that rails plus a little bit of javascript is far more productive than the javascript churn, and for a lot of apps, you give up next to nothing in terms of functionality.
But if I got back into web programming, I'd probably do what I described above, but in Python. Ruby, for whatever reason, just isn't a big player in data engineering, data science, scientific programming, machine learning, all that. I haven't programmed in Django before, but much as I enjoyed Rails, I'd probably stick with Python at this point.
Alternatively, if the javascript framework hamster wheel dwellers want to handle that mess and let me write my wing of it in python and integrate it however they please, then, uh, sure. As long as management understands that when they quit, I won't be able to maintain it. A few people tried to get me to use node, but I won't do it. I feel secure enough that the scientific programming community will not be switching over to javascript so that we can keep our programming language consistent with the shit show that is modern web development.
Rails works as advertised and is great at what it does, but I think ultimately the conventions-obsessed nature of the community, that is often so helpful, has settled on some patterns that make the Rails approach more bother than it's worth with other good options out there. Often touted for being able to scale business logic and developer productivity at the expense of runtime performance, I see some serious issues with the claimed strengths.
- The powerful active record pattern and accompanying library makes it easy to pile on coupling between business logic and database access code.
- Ruby doesn't give you a straightforward way to protect against mutation, which leads to some real debugging nightmares at the worst of times.
- Rails conventions openly disregard low hanging fruit best practices of OOP like the SRP, and make it difficult to design code that follow these practices without straying outside the well trodden conventions (hi again Active Record).
- Rails provides configuration-like interfaces that don't feel like you're calling Ruby code. They are convenient, but offload a big cognitive burden in the name of convenience whenever you need to problem solved something that's not a garden-variety bug.
Ultimately I made the time investment to try some other approaches and have been finding that it's possible to get much of the productivity of Rails at the (arguably worthwhile) cost of a bit of extra typing up front. If you know Ruby well already and have some business goals with some urgency behind them, certainly a great move. If you are earlier career and looking to invest in a productive skills set, you may be better served to consider a few different options.
I was a bit sceptical about the praise Elixir was getting, but after working with it for a while... I started noticing a lot of stuff that is lacking or abused in Ruby and Rails.
I think that Elixir is gonna catch up. If you write a project where you need to use a lot of external libraries probably Ruby is better. If you don't need to rely on the external dependencies too much and you want to/have to write your own code(libs), imo, Elixir is a better option. It also depends on a project, lots of external api calls, webhooks, real time chatrooms, etc. I think Elixir is gonna be a better option.
One thing more, because Elixir's code is much easier to deal with, it's easier to fork and fix deprecated lib than in Ruby(Rails).
It's just my opinion.
Of course, the quality disparity exists in part because there is a much wider pool of developers with varying levels of experience in Ruby, similar to Node.js. But I believe Elixir encourages and even enforces a certain level of code quality, without introducing fragile mutable state, security issues, and package incompatibilities. Thus I expect the quality of Elixir libraries will remain high even as the pool of Elixir developers grows.
For example - is it really "better" to say 7.even? rather than isEven(7)? (Strict OO vs multi-paradigm/functional programming).
Or is the article's example of a data model migration really better than a series of alter table sql statements? (Putting OO on top of a relation database using an ORM.)
And why not go for a pure SPA rather than an AJAX-sprinkled compromise between a traditional server-side rendered html app and a SPA?
> For example - is it really "better" to say 7.even? rather
> than isEven(7)?
> Or is the article's example of a data model migration
> really better than a series of alter table sql statements?
> And why not go for a pure SPA rather than an
> AJAX-sprinkled compromise
And I'd love if people asked "is anyone actually doing SPA" beyond what TurboLinks + a Vue frontend on a Rails backend would get you.
I wouldn't even call it a hybrid, nor would I say it's any more complex than anything else. Every SPA needs a backend, and Rails is as good as any.
Not every app needs to be or should be a SPA. IMHO, unless you're creating an actual web application like Pivotal Tracker or Google Docs or etc, then maybe you should go with meat and potatoes server-side rendered html and javascript.
The main issue with Rails (it's the same with other frameworks) is that it discourages from doing proper design. The only design decision you make is where to put a piece of code, which is ridiculous ("Fat models, skinny controllers" is a bad design heuristic.)
Following Rails conventions works for small (simple) applications, but over time you arrive at a point where no one understands the whole thing. At this point someone suggests moving to microservices, and all hell breaks loose.
I went searching but came up pretty empty ... do you literally mean adding an "app/services" directory, is that all? Where you put classes related to external dependencies that aren't ActiveRecord?
Where controllers have simple interactions with models (which represent database structures, and may have logic in them) you let the controller have direct access to the model.
Models can grow to be too complex, this is where having a concept of named "Concerns" can come in handy, even if you won't use them in another model, it can lift some complexity out of your model and put it into a logical group.
Services, in my view, are akin to models. Some of them may use models behind the scenes. More of them actually represent an external service, which might be an external database that lives behind a web service, an API. Or it might be an LDAP service. (Or it might be a command pattern)
I agree with smart models, if the complexity does belong to the model, then why not let it live there. It sounds like the service layer you're describing is a needless ceremony for "managing complexity" – I'll bet it was a concept that was introduced to your group by an architect.
What TFA really appears to be writing about is that doing backend work in nodejs is a subpar experience. I have little trouble believing that. A more interesting comparison would be to Django (my gut feeling is that Rails compares favorably here), Phoenix (a different set of choices about how opinionated to be on the data model, different base language with some significant and relevant advantages), and other frameworks that one would deliberately learn to replace Rails.
That said, I'm not a huge fan of Ruby in general. I'm a Pythonist, and don't see that changing in the near future. Python seems more straight-forward and "shallower" than Ruby to me, and there's less "magic". I'll even contend that Ruby is a more powerful language than Python - but with the caveat that this in fact is its greatest weakness.
The example that comes to mind for me is when I needed to flash multiple alerts to the user using Rails; I re-opened the class Rails used to implement the behavior and modified it to keep an iterable of messages instead of only one. It was easy, sure... but what happens when the Rails class changes in the next version? My changes not only weren't guaranteed to be compatible, they weren't encapsulated from the parent class, and didn't define and verify its behavior. I can totally see a circumstance where my class would appear to work without error, but the underlying implementation might have changed in subtle and unknown ways.
With Python, I'd have subclassed the parent implementation and wired my subclass up to the application. RoR doesn't make this approach easy, and even if it did, it's not idiomatic for that language.
Ruby follows Perl's philosophy of "there is more than one way to do it."
That sounds terrible! When you scale an organization, do you really want everyone doing everything in their own unique way?
Python has a more practical philosophy:
> There should be one-- and preferably only one --obvious way to do it.
While this sounds a little fascist, it enforces consistency. It means that a senior Python programmer will see code from another senior Python programmer and say to themselves "yup, I'd make it exactly this way if I wrote it myself."
Django admin seems pretty unfinished by comparison. Haven't seen anything actually better.
Of course, there are people in this thread who prefer writing Rack endpoints over the thorny complexity of Sinatra. You really can't make everyone happy all of the time.
A good way to think of it is as a drop-in for the index view of many admin modules, which is the filtering, sorting and pagination of tabular data. This is the specific pain I want to be abstracted away... not the entirely conceptual UX of my admin in general.
I've spent the past 20 years primarily working on JVM-based languages. Being told for about 19 of those years that my boring verbose tech stack stack is obsolete, and going away from the business world any day now.
Most recently, that voice comes mainly from the Node.js community. But 10 years ago, it was a mix of Ruby and Python upstarts. I kinda saw those languages and communities as two sides of a coin:
* The Python guys were the upstarts who leaned toward stability and practicality. Wore slacks and polos, or maybe t-shirts and jeans.
* The Ruby guys were more of the "move fast and break things" school, and favored aesthetics over performance. Had numerous tattoos, and shaved with vintage German double-edged safety razors and a badger brush.
It feels like Node took all the oxygen out of the room in terms of racing to be the Java replacement. But how have the shifts affected the identity of the Ruby community? Did they get older, mature, and come to resemble the Python community culturally? Or are there still a lot of young people disrupting things rapidly, and you just don't hear about it as much anymore?
I'm definitely older and more mature now but I'd don't necessarily think that makes it closer to the Python community culturally nor that the two dev communities were ever that far apart to begin with.
Not unless you're purposely trying to make JVM-stack developers look toxic.
But for me these days, there's very little difference between stacks as to "what's better". For me it's mainly "best tool for the job and who are are your carpenters?"
But these days, NodeJS seems to be the right choice for many of these jobs and it's hard to sit here and knock it. Why?
Unfortunately, Rails suffers from what a lot of other Web stacks suffer from -- the browser requires some level of JavaScript marshalling that all the other stacks have transform to. When you can code on the server and on the client in terms of the same language. It just makes the process cleaner and far more manageable. When an object on the server is the same as the one on the client. Your life just becomes a little less stressful.
And I love other stacks. I'm a Python fan.
But It's really hard to not embrace NodeJS when you've got developers who work on the frontend (Maybe in React, Vue, etc.) and server developers who are on NodeJS and they can speak together, moreover, work within each others codebase and not kill each other.
That doesn't mean Ruby is a bad stack, it just means like all the other stacks, you have to move data between the backend and browser and it's "Oh, I need this change on the server, I'll have to wait for..." -- no, you can do that, if you've got the ability to code in JS, and you're a fullstacker, you can do both.
This was the promise of GWT.
It is the culture.
I really find the Rails culture odd or tbh, I utterly dislike it. I mean if met a Go guy, he tells me all good with Go, it gets the job done but it has its warts, the same with Rust, node, React and so on. People of other stacks like their stack but it's not about life and death. Only Rails guys have these issues and would start a flamewar right on the street and try to evangelize, yell at me why Rails is (always) the way to go and imply that I am not just wrong but also an incompetent developer. There were so dogmatic and when reading such posts in 2019, they are still this way.
Edit: as expected I got downvoted and this is what I mean, they take this too serious, Rails is their religion, Rails locked them in. Downvoting doesn't bring your Rails back.
> I guess if you want to know which languages will dominate the industry going forward, just look at what Lambda supports.
> AWS Lambda supports code written in Node.js (JavaScript), Python, Java (Java 8 compatible), and C# (.NET Core) and Go.
Tongue firmly inserted in cheek, aimed directly at our large cohort of Ruby developers, as if to imply that we're mostly irrelevant to the future of the industry, and it shows in Amazon's lack of support for our ecosystems.
Then immediately following that message, Amazon announced they have added support for Ruby... and PHP, and Cobol. And suddenly it's "I guess AWS is out of the choosing business." I'm still salty about this, forgive me please. But the refrain is tiresome, and it continues even today.
(I still have the problem of services growing too large and needing splitting up - though the better isolation of a typed language means that point comes later than it would in Ruby - but it's still nice to be able to split out a module and keep the existing logic implementation rather than having to reimplement entirely)
How much code it takes to express a given idea. I was just talking about my subjective impressions, but I'm sure one could count lines of code.
> That to me will say a lot about a stack's productivity - because quality of documentation, community, stackoverflow questions, 3rd party libraries, general framework architecture etc etc etc..all those things are crucial for productivity.
Depends on what kind of organisation you're in; in the kind of environment I'm working in, how easy it is to get up and running for a quick prototype has surprisingly little to do with longer-term productivity. To the extent that you're actually doing novel programming work, how familiar the syntax is and how available libraries are is actually much less important than how clearly you can think about the problem you're actually solving, and I'd far rather be using a cleaner language with fewer frameworks available. Of course in other cases you're doing things that can mostly be solved by frameworks (indeed that's the original idea behind Rails - it started out as a tool to make stamping out repetitive crud apps easier, and it's very good at that) and in that case the availability of those frameworks is the higher priority.
MySQL & PostgreSQL are still relevant.
Redis is still relevant.
Ruby on Rails is still relevant.
Javascript is still relevant.
- JS has only grown in ubiquity and maturity of the language.
- postgres also seems to be on a comeback now the honeymoon phase of nosql is over.
> JS has only grown in ubiquity and maturity of the
> language.
Limited support for master/master replication (for availability); there are various approaches but none of them is really first-class in terms of driver support etc.
Limited support for async (non-blocking) connection in a lot of languages. Again, it's often an option but not really first-class.
Limited support for working with non-square-table data (even just simple things like having a "column" that holds a collection). Again supported by the server but often not really first-class in the driver etc.
Rarely clear what the performance behaviour of a given query is going to be - you can write a query that looks exactly like an indexed join (fast) but it will silently decay into a table scan (very slow).
Performance is slowed by mandatory transaction functionality that hardly ever makes sense in the context of a web app. You have to have a lot of indexes (otherwise you'll get aforementioned silent slow queries) but Postgresql will insist on updating all of those indexes before it will ever acknowledge a write. The overwhelming majority of the time, what you really want in a web app context is a "deferred index", but Postgresql doesn't have those; your only options are to wait for all index updates to happen or to do a fire-and-forget write without getting an acknowledgement at all.
The design encourages you to run reporting queries/aggregations without any separation from your "live" operational updates. Because of the aforementioned mandatory transaction isolation that you're almost certainly not actually getting any value out of, it's very easy for those reporting queries to block, deadlock, or slow down your live operations. The tooling around tracking and restricting slow queries is very limited, and because of the aforementioned unclear performance it's not always obvious which queries are going to be slow ahead of time.
Aggregation has to be done in a horrible pseudo-English query language where it's impossible to compose more than one query together. Also, even simple key lookups use this language, meaning a lot of time wasted in parsing (I once saw profiling results that something like 3/4 of the time taken to process a simple pkey fetch was spent parsing the query).
A lot of serious engineering effort goes into these systems, but most of it is wasted in a web backend context. (Indeed for a long time the most popular RDBMS for web backends was MySQL, despite it (at the time) having very little support for all the supposedly-important RDBMS features like ACID). If the RDBMS was invented today I don't think anyone would use it for a web backend - it just makes the wrong tradeoffs for that context.
Having said this, it's not all rosy. Rails does buckle under scale, hence LinkedIn and Twitter had to gradually migrate to Scala(I think) based platforms. This is more a problem with Ruby than with Rails. A huge Ruby backend application becomes quite difficult to reason without a good type system. It's not impossible, just more difficult than say Scala or Haskell or Rust, that have very strong static types.
I am sure I am missing a lot in this comment.
It also becomes difficult to refactor if you don't have a very good test suite. From personal experience, refactoring an Elm application is way way easier and more error-free than refactoring a Rails app.
Node.js no longer has a good framework anymore, express is "out of date", it still can't do async/await and Express 5.0 is not actively developed. The MEAN stack is pretty much gone. I wish there is something in the javascript/backend/nodejs field that shines like Django/Flask as a framework.
Recently I went the other way and built something with Flask because I felt I only needed something tiny (plus python and ruby are both friendly to read) and kept hearing the negatives about monoliths. It started out refreshing because I only added in what I needed but eventually this started to get a bit annoying as it grew, I felt I was rewriting the wheel often, and I missed the organization and forced convention of Rails. Not to mention gems seemed to have more support and often were more recently updated compared to flask imports. I now want to convert this over to a Rails application.
I think a lot goes into picking what to use, size of team, size of users being served, verasility, and development productivity. It's not always only performance at massive scale (you may never need to handle the traffic Twitter does and if you do I think you're doing pretty well and can weather that storm).
I’m not saying all languages and projects need static types- but there are several great examples of scripting languages that have successfully added optional support for static types. After working on several large projects with Ruby, type-less Python, and JavaScript - I have a major appreciation for static types. I’m also a fan of compilers. Anyways, that’s my two cents on Ruby these days. I think it’s a cool language and has a neat ecosystem- but I think it could get a huge boost from static types.
> Rails is not the fastest framework in the world… but I will argue that performance is the last thing you should worry about when you want to scale.
> In my experience, NodeJS or projects written in other frameworks start to collapse architecturally after an alarmingly small amount of complexity is added to them.
> More important than how many requests you can serve per second, is how your development team can maintain productivity over time.
This is what we call dismissing the actual concern (performance) and instead going on an unrelated talking point (maintainability). And frankly, legacy Rails apps are not actually that great to live in. The Rails approach, which I can best describe a “precious”, contains a lot of abstractions that don’t actually abstract successfully, breaking down when faced with the real world in ways that require ugly fixes.
> Where should we put files relating to our data model? /app/model!
> Where should we put our config? /config
> Our email code? /app/mailers
> Decision made. Conversation over. Now let’s get back to our desks and write some code!
If your backend consists merely of “data models” (with business logic and behavior bolted on in an inflexible Kingdom of Nouns sense), routes, mailers, jobs, and maybe response templates, Rails is opinionated enough. At least until your business logic is complex enough that you can’t just use active records as your sole method of abstraction. (Also, the active records themselves are poorly conceived, with obvious foot guns that persist to this day, though at least they’re better documented now. But more on that later.)
I usually find that the architecture I get from Rails is neither necessary nor sufficient. Do I really need controller classes just to route endpoints to handler functions? No. Do I need an ORM? No. Do I need HTML templating? Also no. But I’m going to need more sophisticated design patterns than active records. Decoupling data access from business logic is one of the first and most important separations of concerns that exists, and Rails actively discourages that. Another crucial separation is between work that can be done locally (and hence unit tested) and behavior that entails a network dependency, which includes DB access! Rails really leads you down a bad path if you just naively follow the defaults, especially if your app is so monolithic that my mailers and asynchronous jobs are in the same artifact as my response handlers. (I’m not down on monoliths; Rails just does too much for a microservice and not enough for a monolith. Hell, Rails does too much for a macroservice let alone a microservice.)
> Database management is hard. Managing database schemas and migrations is hard.
> Rails provides you with a no-nonsense way of defining your database structures, as well as a full suite of CLI commands for migrating, resetting, seeding, dropping and creating databases across all environments.
> Rails handles databases in a ubiquitous way. There are database drivers for almost every popular database, and schema management and Object Relational Mapping is handled the same way across all data stores.
These are almost all false.
* SQL isn’t hard to use for schema definitions or migrations. The Rails DSL for database schemas is marginally prettier than SQL, at the expense of adding an extra layer of indirection and making you learn yet another precious Ruby DSL when, if you’re worth your salt, you already understand SQL anyway.
* Rails has an inbuilt assumption that your app connects to a single DB instance per environment. Cool, but why on earth would I connect to different RDBMS systems across environments (except maybe in-memory SQLite for “unit tests”, which is already an anti-pattern?). And given this constraint, what exactly does ActiveRecord get me? I can wake up one morning and just port my whole app to Postgres without changing a single line of code? That’s not bloody likely in the real world and we all know it.
* Rails adds even more unnecessary brittleness to common DB access scenarios, which paradoxically means that the “simple” but broken Rails solution has to be augmented or replaced by ugly workarounds. For example, ActiveRecord validations are inherently prone to race conditions that make them both unnecessary and insufficient. From the current Rails guide:
> 2.11 uniqueness
> This helper validates that the attribute's value is unique right before the object gets saved. It does not create a uniqueness constraint in the database, so it may happen that two different database connections create two records with the same value for a column that you intend to be unique. To avoid that, you must create a unique index on that column in your database.
OK, so the uniqueness validation doesn’t guarantee uniqueness if there are concurrent connections to my DB. Also, every real world Rails app is deployed so it runs as multiple processes. So it never guarantees uniqueness. Instead, I create a unique index, and ActiveRecord...sometimes throws an exception that’s distinct to the RDBMS but not distinct to the failure mode, so I still have to string match against my DB’s particular phrasing of “uniqueness constraint got violated” and handle that as an unnecessarily generic Ruby exception. Which is exactly the same amount of work that would exist if uniqueness validation just wasn’t a Rails feature to begin with.
A thoughtful design would realize: at least some validation has to happen in the DB and not in the application code, and it will anyway, so let’s make patterns for living with that. Why don’t my models automatically detect my unique indexes and throw a “not unique” Rails exception when the DB complains? Why does it instead insist on doing a shitty job of trying to guarantee uniqueness itself? It gets worse and worse when you run into scenarios like, “I want to run SQL queries that don’t cleanly map onto ActiveRecord without monkey patching every damned column of the result set onto individual instances of a loosely related ActiveRecord class”.
> Rails (and Ruby) Have a Deep Culture of Code Quality
Hah. I think I’ve already debunked that one. Rails has a deep culture of precious, brittle abstractions that make easy things easier and hard things harder if not impossible.
> Asset Management
If your app is monolithic enough that you’re managing your assets in your Rails app, it’s probably big enough that you’ve run into the problems with Rails I’ve mentioned earlier. If it isn’t that big, odds are you’re in a microservice environment where your assets are most likely deployed in a highly decoupled way—perhaps from a separate repo owned by your front end devs. Maybe the asset pipeline is a perfectly reasonable way of managing a full-stack monorepo, and you can still deploy your Rails assets to a CDN and make it work. But that implies that your web app is a Rails monolith, and Rails monoliths need a lot of thoughtful design decisions above and beyond “put models in app/models”.
> RSpec is quite simply the gold standard for behaviour driven development, and almost single-handedly created the BDD movement that is still raging in the industry today nearly a decade later.
RSpec is nothing special. I actually find Spock a lot more featureful and self-documenting.
> A Smorgasbord of Plugins
The first plugin on the list he links to is activerecord-import, which only exists to work around a problem Rails itself creates in the first place. The rest are either generic things that every other language has and other instances of workarounds for Rails limitations.
Rails (and Ruby in general) isn’t unique in terms of library support. Python has greater breadth, JVM has greater breadth, heck I bet you can still find stuff on CPAN that never made it into a RubyGem.
> Heroku
Works with everything; not a selling point for Rails.
> ActiveAdmin
Admittedly, something like this is one of the few redeeming qualities of an ORM, which is why Django always had this built in. Why not Rails?
The article keeps saying that Rails is “batteries included”. “Your app behaves in a reasonable way without ugly DB-specific exception handling code if you run more than one parallel instance of it” didn’t count as batteries either, though. But I guess HTML templates did. Rails’ design choices would be logical if you treat Rails as a framework for prototyping, but isn’t that when you need admin screens the most?
> Rails is battle-hardened and industry-proven. There is a long list of (very) successful businesses building their product with Rails.
Starting with Twitter, which migrated away from Rails onto a JVM backend as soon as they grew up. If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem. You can even deploy it on Heroku.
What is likely though is that one day you'll want to use a gem providing feature X and because it's based on ActiveRecord, you can use it... whatever the backend is. There may be a few special cases where it really matters, but in general, instead of finding X-mysql-gem while you're using postgres, you'll find X-gem which uses ActiveRecord.
Well, uh, there it is. </Goldblum>
As a Rails fan who was forced to use Java for a web application at a previous job, I've been all over this whole topic, and even ranted about it on this site a couple times. This is the conclusion I came to: some people like to have things done for them by a framework, valuing the tradeoff of time vs. specificity, and some people like to write a lot of extra code themselves, valuing the precision that affords, at the expense of time.
The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rails, with a few dozen more from the generators. (Cocoon is freaking magical.) In Java/Spring/Node.js, it took me 160, and I still wasn't done. I needed repeated classes, controllers, and services in 2 languages in 2 stacks. One of the arguments I see a lot in this field is how people are fans of strict types in the Java world. OK, but it seems to be a requirement to keep Java and Javascript sorted, and is a non-trivial amount of work to keep in sync.
Some people get hung up on, say, race conditions of database validations, or mock database transparency as useless, or argue about which ecosystem has more plugins (Node "wins!"), and some people think it's ridiculous to duplicate 90% of the plumbing, or hate having to deal with migrations manually, or find it inconceivable that there's not one single canonical example of a working Spring/Node CRUD app in a current version of the stack available on the entirety of the internet.
To the last point: THAT is how fragmented the "Spring" world is to learn and apply. THIS is the tradeoff in NOT being opinionated. In nine months of pulling my hair out, I never once found 2 examples that did ANYTHING the same way, and NOTHING was current and complete, not even stuff by Matt Raible. I even contacted him directly, and the best he could do was point me at a GitHub project I had never been able to bubble up with Google, which was 3 versions out of date, and would no longer work the same way with current versions of the stack.
To each their own. Horses for courses. Your milage may vary. Terms and conditions may apply. It's almost like a "right-left" dichotomy of politics.
Anyway, I leveled up my career, and now I get to pick what tools I use. But, yes, I'm still bitter on this topic. ;-)
> The working example I took away from the exercise was that writing a simple edit page with a nested model. It took me 3 lines of code in Rails, with a few dozen more from the generators....
> Some people get hung up on, say, race conditions of database validations
Because those race conditions mean that your cute three-line edit page is eventually going to turn into a hundreds-of-lines monstrosity if you actually try to put it into production. Rails is a great rapid prototyping framework, granted, but once you try and run a Rails app in production, you’re still face-first in all the complexity Rails pretends to handle for you when it’s just localhost:3000.
> I also worked at a bespoke consultancy that made Rails sites for startups
Ah, so didn't have to handle the maintenance burden afterwards. I did. Rails is awesome if you can just dump the maintenance burden on someone else and move on.
Boring languages/frameworks Just Work, and are usually pretty secure.
Minimalist --which is to say, making something as simple as possible, but no simpler-- means fewer moving parts which can break in production.
90% of what my places of employment and clients need is the same old shit, and I like to build it so that when something breaks, I can jump in and hammer out the broken thing and get the process moving again without needing a ton of research.
-php started with no framework , everyone just did super minimal strait to the db and template query stuff, very unorganized but you knew the underlying apis and tech because you were right up against them
-rails started very ridged. separating programmers from the underlying apis and tech
Now php devs had to create the ecosystem of organization but the experience of working with the the server and db was still useful particularly when doing something unique or when one needed special performance
Ruby devs needed to learn to become leaner how to break away from the framework when performance was needed. This was completely new and I feel the community did not support scripting away from ruby. Mostly the community was focused around ease
also at the same time PHP was improving the language. I dont think Ruby had the same improvement and some of the stuff I have heard about ruby makes me cringe.
http://rubylearning.com/blog/2010/09/27/almost-everything-is...
On the other hand JRuby doesn't seem to be having that much adoption, and the new pseudo-JIT via C compilation doesn't seem to be the best way to improve it.
But all things considered, I think TypeScript/react/lambda with VSCode is now a better choice for developer and devops productivity in both the short run and the long run. It’s still a good idea to follow many of the Rails conventions though regardless of the language you use.
My personal favorite up-and-coming framework (and admittedly, my favorite web framework overall) is Phoenix[1], written in Elixir[2], a functional programming language with a focus on concurrency, performance, and developer productivity. In my opinion, Phoenix has almost all of the best parts of Rails without nearly as many of the warts, and adds a plethora of compelling features of its own.
Despite what the author argues, I believe that raw performance and developer performance are equally important, and even intertwined. Why? A slow application results in lost customers and revenue, a fact that is well-documented. A default Rails application is going to be quite slow, requiring intervention. Of course, most larger Rails apps are not necessarily slow in practice—in my experience, this is largely because the code is littered with brittle caching logic and hacks requiring many human-hours to maintain and debug when things go wrong. Thankfully, Ruby is seeing improvement in the performance realm.
Phoenix achieves massive scalability, raw performance, and developer performance, without requiring significant trade-offs and caching logic littered all over your code. It is an absolute joy to write Elixir. Phoenix is famous for consistently achieving microsecond response times without caching, and being capable of holding millions of websocket connections[3]. Granted, Elixir as a language is not computationally fast, but the typical web app is not performing expensive computations, but instead juggling IO, which Elixir handles extremely well. CPU-intensive tasks can be written in a different language if need be.
Importantly, Phoenix is not your application—Phoenix's job is to provide a web interface into your broader Elixir application. Thus, Phoenix is more of a toolkit than a framework, and yet it provides everything you would expect in any web framework, with strong conventions based on the solid foundation of Elixir. You could migrate to a different framework with relative ease. You can easily integrate different interfaces into your application, such as a CLI frontend. This is in contrast to Rails, where Rails is your application unless you actively fight against the framework.
Ruby and Rails are notoriously bad at handling concurrency and real-time features using e.g. websockets. This becomes progressively painful as using all CPU cores becomes increasingly necessary, and as websockets continue their ascension on the web & mobile. In contrast, concurrency and soft real-time communication are Elixir & Phoenix's bread-and-butter.
As I mentioned, Phoenix brings compelling features of its own. The most interesting to me is the upcoming Phoenix Live View[4], which will allow developers to write rich, interactive, real-time applications without being forced to wade into JavaScript hell. Read the linked article for more information. I could be wrong, but I don't see something like Live View making its way into Rails, especially without significant downsides.
One area where Ruby & Rails trounce Elixir & Phoenix is maturity. Although they have gained significant traction, Elixir & Phoenix are still comparatively immature. Thus, you'll have a harder time hiring, finding third-party libraries, and answers to questions. That said, Elixir is based on Erlang, which is extensively battle-tested and has a huge assortment of libraries available. (You can very easily and naturally use Erlang code in Elixir.)
I could go on, but I think this has gotten long enough.
[1] https://phoenixframework.org
[3] https://phoenixframework.org/blog/the-road-to-2-million-webs...
[4] https://dockyard.com/blog/2018/12/12/phoenix-liveview-intera... (Repo: https://github.com/phoenixframework/phoenix_live_view)
Meanwhile Ruby, PHP, Python, and Java are still powering all the sites that are telling you those technologies don't work anymore, and powering the site that takes your money when you buy another Udemy class to learn [even newer tech stack].
For instance, GraphQL in Rails is smooth like butter. You define the types and the fields just resolve like magic based on your models. I wrote an API a while back and it was just stunning at how easy it was to write. Only issue? I wasn't using Rails. I was using all of the niceties of Rails like autoloading, ActiveSupport, ActiveRecord, associations, etc., without the actual, framework of MVC. If Rails could really invest in the API mode and get it working with say, GraphQL, I could see it working amazingly.
Plus, you could take the DSL idea and expand it to GraphQL. GraphQL top level queries and mutations take similar forms (get all of resource, get one of resource, etc). You could easily abstract that into a DSL if you'd like.
Authorization and authentication in GraphQL isn't amazing either. I'd really like to see someone making that simple and on by default.
There's also some generic Ruby tooling things that'd be nice. Types, of course. The standard way would be a mypy/TypeScript esque annotations with erasure at runtime, but I actually feel like Ruby could do something really neat and really true to the language by developing runtime dependent type checking. Autoformatting would be nice (any thoughts on rufo[0]?)
First, CoffeeScript is formally deprecated. Turbolinks sucked, but Turbolinks 5 is an entirely new beast and it rocks. You need to give it a second look. I recommend this talk, sped up to 1.5x:
https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s
Finally, there absolutely is an opinionated client library that is designed to pair beautifully with Turbolinks 5. It's called Stimulus and it rocks.
You can play with all of these frameworks using the --webpack parameter:
rails new future --skip-sprockets --skip-coffee --webpack=stimulus --database=postgresql --skip-test
As a bonus for anyone starting a new Rails project today, you're going to want to bookmark https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81...
Let me know if you have any questions.
One reason I love Stimulus + Turbolinks 5 is that you don't have to think in terms of client-side routing.
If you want it right from the start, you can create an api only rails project: https://guides.rubyonrails.org/api_app.html
I wonder if that “do X in under 20 minutes” can be replicated in modern-day Rails.
[1] https://mobile.twitter.com/dhh/status/492706473936314369?lan...
Some ideas:
I think the most critical trend has been the dissemination of the Ruby ecosystem's most popular and best ideas into every other ecosystem, which I would summarize as a culmination/caricature of a movement that was already in motion thanks to other ecosystems like Perl and Python. Rails was such a massive hit because it was a stark contrast to the tropes of complexity that came before it like endless XML configuration and IIS. I think Rails was a symbol of this whole renaissance, not single-handedly, but because it coincided so well with a critical-mass milestone in our industry and hit so hard with this cult of "fun and easy". And these days were back when https://rack.github.io/ came out and Zed Shaw wrote Mongrel which was Twitter's first web server and one of Ryan Dahl's inspirations for Node.js.
These represented identity-level changes in tech and its crescendo into the mainstream, not ideas that would merely spark and die in the Ruby ecosystem, so it's no surprise that Rails cannot command the same gravity over time.
Another trend has been the popularity explosion of smaller and simpler solutions over monolithic frameworks. For example, trending away from things like GWT and ExtJS and Ember and Meteor. Trending towards things like React and Express. No Rails analogue caught on in Node or Go and nobody cares.
There's also the explosion of Javascript which became such a viable alternative to other dynamically-typed languages (particularly Ruby in this context) that "why should I pick Ruby?" became a harder and harder question for beginners to answer.
Finally, there's the explosion of choice. One back-end application framework just can't dominate HN anymore like it could in 2007. I think React is the modern repeat of Rails in the sense that it popularized a new paradigm of building applications. And I think React will go the way of Rails in the sense that its ideas will become so ubiquitous that React itself won't stand out anymore, like when we see UIKit2 adopt these sorts of unidirectional data flow and FP ideas as a core first-class abstraction. And we'll get so used to it that we'll wonder "so what was the big deal about React again?"
Rails is certainly still amazing software and is clearly still improving. I generated a fresh Rails project half a decade ago after a long hiatus and was blown away when the error page in the browser had an embedded Pry REPL initialized at the error's stack frame iirc. That's some wtf-level polish. And I can only imagine how much better Rails has become since.
Anyhow, definitely peek at https://gist.github.com/andyyou/834e82f5723fec9d2dc021fb7b81... which I consider to be something of a missing manual for the bleeding edge.
I think that most folks would be completely shocked to realize that they can run a command like: rails new future --skip-sprockets --skip-coffee --webpack=react --database=postgresql
Although, I would argue that they should check out StimulusJS instead of defaulting to React... it pairs up beautifully with Turbolinks 5. All preconceived notions about earlier versions of TL need to be discarded because it's actually pretty awesome now.
DHH has stated that he started Rails because of frustrations with the Java web app development ecosystem, and this rings true for me from my own experience. What surprises me about the illustration of the contrast of the two worlds is that, after 12-15 years of Rails, and the success its had in addressing its stated objectives, the Java "world" seems to only be adding to the complexity of their "standard" stack. Sure, you get install JHipster, and generate a boilerplate site now, but that process took FORTY-FIVE MINUTES on my work laptop, and I don't know half of the stuff it installed.
Oh boy, this is in one sentence almost everything that is wrong with Rails...
* According to the author NodeJS fails architecturally when small amounts of complexity is added to it.
=> Same applies to Rails aswell, anything beside a crud app and you start wondering which code goes where.
* Rails is Opinionated...
=> Great if it were 2006, In 2019 rest apis are a norm, and more Nodejs apps get enabled everyday have the same feature. Infact serverless apps to have the same features. In my view firebase or similar apps is the right way to go when you are booting your apps, and then scale or rewrite when you grow.
* Rails has a deep culture of code quality.
=> So does smalltalk, lisp and clojure. Infact ruby community has borrowed many ideas from both Smalltalk and Java communities.
* RSpec ..
=> Rspec isnt the original invention its based on JMock.
* Heroku, ActiveAdmin, Industry Proven ...
=> Straw-man arguments.
I am as opinionated as rails and in my opinion Rails isnt relevant in 2019, they are running out of ideas, the latest "innovation" in rails is an inbuilt Rich Text editor called Trix available as ActionText. Yes you read it correctly a rich text editor is the latest relevant innovation in a web framework. I think for most startups a great way would be to start with a serverless setup like Lambda or Firebase .... and just write the relevant front end bits in Javascript, Coffeescript, Clojurescript or Elm. When the app outgrows such services just write the enough parts of backend service as you need it.