As an individual developer, I don’t know a platform and framework that lets me do more with my time. I used rails recently for a new project to act both as the backend for an iOS app, an auth management system, a asynchronous worker manager, an upload manaager, and BI tool.
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.
I replaced `rails` with `Django` in your statement (and maybe could do the same with Node.js), and it reads the same. Guess it's just about being familiar with a mature ecosystem you already know, and then you can achieve results.
You could also replace it with Laravel, or any other framework. What I've found is that if you want to be productive, stick with what you know. Don't try to solve problems you don't/probably won't have.
Agreed. Although I do Rails and have no experience with Django I know Django is the same.
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.
As someone who's built a few apps in flask that have gotten quite big (but still maintenable), I am curious to get your perspective on how big a difference Rails gives - I have explored ASP.net and Django as options before for projects and immediately (probably out of naivete) concluded that even for simple apps I'll have to start modding the behavior of the components sufficiently enough that it will give me a headache.
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 ?
Coming from Rails, I spent some time with Django and Flask applications in the last few years. There are noticeable differences between the two of them but both are much lower level than Rails. The developer has more choices and can make more mistakes. Projects can look totally different.
On the other side all Rails projects look pretty much the same and this make onboarding much simpler.
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.
basically less available gem/packages for Flask, and when available less quality or less plug and play.
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.
> 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.
From my experience, it really wouldn't read the same with Node.js. Maybe some framework on top of Node could reach a similar level of productivity and maintainability, but for now we're far from that.
I suspect that the JS world being always in a state of flux doesn't help reaching that goal.
Just to share for anyone interested in the Rails gems I'm using.
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.
I know what an async worker and what sidekiq is. But apparently you don't know that in modern stacks you don't need this anymore and it was an oddity because of RoR.
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'm currently working in the JVM and find myself wishing I had Sidekiq. Learn at least two stacks to some degree so you can contrast and know what you are missing when you inevitably have to learn a third and a fourth and a fifth.
Shouting and insulting people is no way to have a discussion. Without moderation or some other mechanism this is what online communities devolve into and it destroys them.
/r/programming used to have lots of great discussion. Now it's mostly a deserted wasteland.
Naah Rails is here to stay - the momentum around the project is still huge and too many companies rely on it. Even if dhh did a Guido and left, there's a big army of contributors that would replace him.
If I need to guess though, in 10 years dhh is still involved with Rails to some degree.
Staying power has less to do with relevance and more to do with legacy apps. There will always be some people working on any given technology. Be it Spring, Smalltalk, Common Lisp or ...some X technology. The question is, is it relevant? In an increasingly Multicore world where you try to extract more performance out of your CPU's Ruby may not cut it and by induction Rails. The future web devs would require writing better multithreaded code probably on the JVM. Clojure, Erlang or Go are the few awesome options that come to my mind.
Disagree with all of those except Javascript (and that only as an execution layer). All of the things that those technologies promised, we now have better ways of achieving.
Yet here we sit in entire thread that’s the perfect place to discuss these “better ways” of doing things and I'm seeing zero consensus about what those better ways might be. Are other people interpreting this thread differently?
I don't know the kind of work you do, but in the work I do, postgresql offers a lot of bang for your buck and works for me in the majority of all my web apps. The fact that I have one backend that can accomplish so much at good performance is a win for me.
The problems I have with postgresql in a web backend context are:
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.
If you have a problem for which relational is a good fit then Postgresql is definitely a better choice. I've yet to actually encounter such a problem though.
Rails needs more opinionated decision on frontend story. Just pick ReactJS instead ? Not a bad idea. Or VueJS ? Neither a bad choice. It's the main reason i don't choose Rails over a universal Node.js stack for the HTML rendering part.
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:
Thanks, it's an almost complete guide. But there's one important missing piece: Universal routing. How about taking the routing config which can be applied for both server and client ?
Having to support a legacy RoR monolith and being happy with it are 2 different things. How many of those companies are now supplementing the monolith with microservices in other stacks and are actively chopping up the monolith? I know at least 2 of those companies are doing just that.
Right, but that's just because those companies have grown to a certain point where it's hard to remain productive with a monolith. If you are starting to have scalability issues it makes sense to rewrite key hot code paths in a language faster than Ruby. That doesn't mean using Rails when they started out was the wrong choice though.
True as far as it goes, but does Rails offer a compelling advantage over higher-performance languages these days, even when starting out? Modern compiled languages have closed the expressiveness gap with Ruby a lot in the last decade or two. E.g. I find I'm just as productive in Scala as in Ruby - if anything more so - so I'd sooner work in Scala/Wicket from day 1 (for use cases where server-side rendering makes sense at all).
(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)
That's quite hard to measure, how do you measure expressiveness? Or easiness to grasp and get into? Take a CS graduate and have them build an app either with Rails or with Scala, in which stack will they be more productive? 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.
> That's quite hard to measure, how do you measure expressiveness?
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.
Rails is a great monolith framework, but a monolith will eventually reach its limits, due to size/complexity of the team or the task at hand. I think providing a better story around how to prepare for or handle that transition would definitely serve Rails a lot better in the long run. But, as long as the main target audience of Rails is Basecamp (a saas tool with 12 developers), I don't see it in the future.
lol good luck with that. the main thing that makes this work is that the company trying micro services most likely grew large and now has a big engineering team. It also moves slower than it used to due the stage it's in. In that case any architecture would work really...you have a huge team of engineers that moves slowly and can troubleshoot whatever issues arise. yay to micro services!
I think the best is to have nicely designed modular monolith application. Sadly this something that Rails backwards conventions makes very hard to achieve.
Popularity of a framework or paradigm seems largely driven by marketing and memes. With "Rails doesn't scale" as the almost-rhyme that sticks in people's minds, an entire tech cycle gets wasted on things that take significantly more developer effort.
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.
> Popularity of a framework or paradigm seems largely driven by marketing and memes.
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.
Young developers (as one myself), tend to be overly focused on what makes them attractive as a developer. Kinda like an overly insecure teenager. So they pounce on any framework or tech that makes them desirable to an employer. Rails isn't hot, so it won't get them a job so they won't learn it.
If you look at the trend for 'rails' it's much more level and googling 'rails' three of the top four results are for the framework. It may be people no longer have to type 'ruby on...'.
I think a lot of developers focus on learning newer technology stacks because they are hot and tend to pay more. But less popular doesn't mean it's not in demand.
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.
I don't like ruby or rails. But I feel not liking it has really hurt my career. The amount of job requests I get for Ruby on rails or ruby is significantly higher than my typcial stack.
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.
Not going to defend choosing what’s popular just because it’s popular but the main argument for using something popular IMO is that most of the sorts of things you want to do is likely to have been done by someone else already and some of those other people will have written about their solution or made libraries etc that you can reuse. Whereas if not many people are using something then the amount of information you can find, even in the official docs, is likely to be lacking. So you can save a lot of time by using something even moderately popular compared to using something that few other people use.
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.
"popular tech is safe because someone will have done what you want to do"
is phrased negatively in this excellent opinion piece:
with a new technology/tool, you don't know what can go wrong.
With boring technology, there's enough community experience around it.
https://mcfunley.com/choose-boring-technology
It also seems like 'boring = popular & old', 'hype = popular & new'.
> the main argument for using something popular IMO is that most of the sorts of things you want to do is likely to have been done by someone else already and some of those other people will have written about their solution or made libraries etc that you can reuse.
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).
Hulu was, and possibly still is, a Rails site. Streaming video is no problem for a Rails based application because the application server just prepares a URL for nginx to stream.
So let's just forget about Basecamp, Github, AirBnb, Hulu, Kickstarter, MyFitnessPal, Twitch and all the other Rails sites and continue to pretend Rails can't scale and won't work for the modern web.
Basecamp is always on the latest or beta version of rails, Rails 6 at the moment. GitHub has recently updated to version 5 and are merging a large mount of their scaling gems for version 6.
There are some podcasts and keynotes where DHH talks about their stacks.
I've never felt as dialed in and as productive in any other tool or framework as I have in Rails. It takes all the unimportant BS, places it off to the side, allows me to focus on what I want to build, and gives me the ability to dig in deeper on the details when I want/need to.
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.
I've tried to work with ActiveAdmin on several consecutive projects, and I do not understand the draw. It's a fussy DSL that requires you work with your data in a way that feels very un-Rails. You basically have to approach building out your UX from the perspective of what the tool is designed to do. This seems a shame, in the context of Rails - a framework that's actually pretty great at getting out of the way in the right places.
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.
I hate ActiveAdmin because of exactly what you say, but tbh it is indeed a very powerful tool and still allows you to very quickly spin up admin pages (to a certain limit, but this limit is pretty high).
I yet have to find something similar.
While it is not a 1:1 replacement for the end-goal of a drop-in admin, I've had some success with datagrid: https://github.com/bogdan/datagrid
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.
Have you tried RailsAdmin? It does a great job of getting you over the line with the basics (though configuring it can be fussy and customising it is pretty miserable).
I have worked with Django a few years and I only use the Django Admin initially, to confirm a couple of things and maybe experiment with a data model. Within a few days I usually remove it. There is no need for a production system to retain the Django Admin, in my opinion, but others may disagree with me here.
Build your app using whatever you're most comfortable with because in the end an existing product is better than no product. Will you enjoy spending an extra hour per day working with this framework over another? That's an hour more of progress.
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.
Java has JPA (Java Persistence API) which is an abstraction layer over various ORMs. However, most people use Hibernate. Hibernate is nice because it also gets out of the way when you need it to, like when you're inserting or selecting a massive amount of data. It also supports the Stream API now, which is super convenient.
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.
I recommend to not use an ORM. Really, with a modern language, an ORM is mostly redundant. If on Spring boot, simply use JDBCTemplate and TransactionTemplate to deal with raw SQL queries and transactionality. Get rid of all the annotation magic around this.
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.
If you're going this way I would still recommend a library like jOOQ.
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.
+1 for jOOQ. I prefer to Just Write Queries than muck about with quirky ORM magic that gets turned into queries. jOOQ lets me do that with safe query building and type checking through to the DB level (with code gen).
I have dynamically generated queries that span over 200 lines. Doing this without a query builder is pure madness. It doesn't matter how modern your language is, manually concatenating SQL shouldn't happen in 2019.
Do those queries need to be that long or is that just a limitation of your ORM tool and the table structure it generated so you can pretend to have an object database? I've simplified quite a few domain models to fit the querying needs and gotten rid of lots of tables, joins, etc. in the process. There's no wrong or right here but my observation with ORM is that it leads to needlessly complicated table designs, which in turn makes querying the database needlessly hard.
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.
100% this. Whenever folks recommend simpler options like JDBI, I have to shake my head. Rolling your own query builder with string templates feels like an SQL injection attack waiting to happen. If you know 100% going into a project that you won't have to modify the structure of your queries based on user input, then it's an acceptable option. But it's quite common, at the very least, to have user input that results in variable number of terms in where clauses.
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.
I'll second the thought on Kotlin, and in fact I just trained a diverse team of PHP, RoR, and Python developers on Kotlin with Spring Boot, and our platform migration project to Kotlin massively reduced our LoC and increased each engineers understanding of the platform. We broke off a couple pieces into microservices which need to scale independently, and it was a great experience. I'm hoping Kotlin continues to grow in adoption.
Really? I'm doing Java contract work for a living (thankfully not only Java) and, while it pays the bills, I'd use almost anything else (except .net which is just Java without the ecosystem). I think the whole Java stack, with its myriad of metaprogramming silos, overreaching build pipelines, outdated HTTP libs and paradigms, absurd class loader configs and layers of module systems, unsound abstractions, and third-party libs, many of which are starting to reach EOL, really stinks and sends you into a world of incidental complexity. It might not be so obvious if you're coding greenfield Spring "microservice" apps or, good forbid, Spring MVC apps in 2019, but believe me it'll hurt you down the road once you need to update your project to newer versions of third-party libs.
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.
I know all too well ); Only three years ago I contracted for an insurance company for JSF, and worse, using portlets under Websfear. Well, it payed the bills.
I use Grails which is very similar to Rails and a lot easier and productive than Spring Boot. Good defaults makes application building a much smoother experience. Grails is still Spring Boot, and you can still code like it was a pure Spring Boot application.
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/
I've had some not-so-great experiences developing web services with Spring Boot, Hibernate, Groovy itself, Grails.
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.
I do understand why you feel like that, I've been there too. No framework is a silver bullet, but over time you will see the value in them.
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.
This article reads to me as more of a "Rails vs Node.js" piece, which seems almost too easy—I would be interested in a more thorough comparison of Rails versus other frameworks. Here I will attempt a comparison, limited in length as this isn't a blog. :)
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.
Elixir and Phenoix absolutely blow away Ruby and Rails in terms of performance and capabilities, and in my opinion, is just as elegant and productive (José was part of the Rails core team, after all). I still appreciate Rails (it allowed me to enter the industry), but just don't see the point of starting a new project with it these days.
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.
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.
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.
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.
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.
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.
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.
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.
A summary of my experience would be: libraries are good, frameworks are bad. (Indeed possibly the best "framework" I ever used was TurboGears which is very deliberately just a collection of dedicated libraries, all of which you can replace piecemeal as and when you need to).
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.
On a broad level, Turbogears is such a thing. (On an even broader level, so is my current preferred stack which is something like: Wicket, Akka-Http, Circe, Hibernate, Liquibase, and Scala's native ways of doing DI). If you're asking about Ruby specifically I'm not current enough to answer.
Isn't that the same with any collection of libraries? If you don't use a framework and just pick your libraries, you'll still need to ensure that their versions work fine together.
If you pick a bunch of standalone libraries you can be fairly confident they're not going to interfere with each other - which version of your web templating engine you use has nothing to do with which version of your ORM you use, and you can upgrade each independently. When they're both part of a big overarching framework it's more likely that a subtle interaction has slipped in and not been noticed.
To be fair, Rails now makes it much easier to swap libraries if you need to, compared to how it was at the beginning. I agree that that's something useful, but personally I still think that having a sane reference combination to start from is much better than having to choose everything yourself.
Especially in the JS world, I could really feel a "library fatigue" when I had to evaluate so many different alternatives.
> I still think that having a sane reference combination to start from is much better than having to choose everything yourself.
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.
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.
With frameworks you need a mental model of how the framework works. With libraries, you need a mental model of how your code works. On the balance of things, I would say that libraries often (not always) have less cognitive load here.
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).
> when creating web applications, starting from scratch or from a minimal base is massively slower
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.
It certainly can be. It doesn't have to be thought. It really depends a lot on your team. I've worked on teams where building large scale, but minimal, well tested systems was their bread and butter. I've also worked on teams where hooking up existing frameworks was what they were comfortable with and any footstep taken outside of that activity was marked with considerable rancour. Not invented here syndrome is also a real thing and sometimes people sit there building "game engines" instead of "games" ;-) On the other hand "Invented here" syndrome is also a real thing and sometimes people completely panic when faced with the thought of writing something novel. You need to go with your team.
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).
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.
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.
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.
nginx transparently proxies using http2 to client and http1 to server. In a standard setup at any scale with a load balancer it doesn't matter that Rails doesn't support all of HTTP2. The client still gets all the benefits of header compression etc.
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.
Something using AWS or GCP LBs, nginx or Apache covers 99.99% of the modern web app hosting scenarios. All support HTTP2 to the client with HTTP1.1 to the server.
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.
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.
> 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.
All the people trying to sell you something else. I heard someone on HN call it "blog driven design". Tech blogs need something to write about, Udemy teachers need something new to sell, startups need some way to differentiate themselves from their competition, so they start talking about how awesome [insert new tech stack here] is. The cycle continues and in 6 months, [new tech stack] is old news and you can't build the modern web with it and it doesn't scale, so here's [even newer tech stack].
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].
Rails is fine but didn't age well, specially the lack of strong functional programming support. Other nag is that it's hard to not do things the rails way - this monoculture reinforces the appearance that is fine because people looking to do something different just don't use rails.
And when you "scale" rails is not really rails that scales as much as it is the architecture - it could be applied to other frameworks.
Still if you are familiar you can write stuff really quickly.
I don't know how to quantify how relevant Rails is today, but I do think it's interesting to explore why Rails isn't as popular as it once was. I remember just eight years ago, Rails was on the HN frontpage almost daily.
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.
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.
> ... it was a stark contrast to the tropes of complexity that came before it like endless XML configuration and IIS.
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.
I love that Rails is flexible enough for me to both agree completely AND be thrilled to not use Trailblazer, because I prefer interactor, state_machines, rolify, pundit and draper. Considering the talk about how heavy Rails is in this thread, I feel like I have all of the options in terms of customization and in a very mature ecosystem that still values developer happiness.
As a former Rails developer, I figured it would be worth mentioning reasons I disagree.
> 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 c...
> 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.
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.
> If you want to go with “battle-hardened and industry-proven”, use the Spring ecosystem.
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. ;-)
My point wasn’t to use Spring, my point is that it’s ludicrous to refer to Rails as “battle-tested” when most people who test it abandon their Rails prototype eventually anyway. My actual advice is probably that every stack sucks, but some stacks at least get out of your way.
> 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've made at least a dozen LOB Rails apps for internal use at companies. I also worked at a bespoke consultancy that made Rails sites for startups, and I've seen dozens of Rails apps "in production," out on the open internet, and making money for their owners. I think there may be some conflation here between "production" and "Twitter- or Facebook-scale production." And I wouldn't trust ANY framework to applications at that scale.
Even for internal use, you have to worry about data integrity a lot of the time.
> 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.
Wha...? Honestly, the presumption on this board sometimes. I was one of the 2 people who maintained the apps on AWS. There were no issues. I guess we've just had VERY different experiences.
I think Rails could go far if DHH et al keep their ears to the ground about the state of web development and adapt accordingly. It still has some killer features that I've yet to see replicated with as high a level of ergonomics and elegance.
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]?)
rails did the opposite of php , and I think its harder for it to pivot in its community.
-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.
Also PHP benefited from Facebook's work and the commmunity actually cared about performance. Zend exists since the early days, now there there is the JIT migration going on.
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.
Quite well. From Rails 5 there’s an API only init flag which removes the view layer and then you can just return JSON from controllers. Chuck nginx in front to proxy backend requests and serve your static front end bundle and you’re golden.
I have this joke that I noticed ruby/rails developers seems to use a lot of their extra time (which they get with the high productivity you seem to get with rail) talking about how great ruby and rails are and how efficient they are with it ^^
264 comments
[ 7.4 ms ] story [ 527 ms ] threadCombined 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/
[2]: https://github.com/ankane/ahoy
[3]: https://github.com/ankane/blazer
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.
Just. Let. Rails. Die. Save the world from some Carbon and don't implode the sun by running that garbage.
Here's a graph displaying some factual and relevant information:
https://trends.google.com/trends/explore?date=all&geo=US&q=R...
/r/programming used to have lots of great discussion. Now it's mostly a deserted wasteland.
Says you! I don't enjoy the flaming, but things have gone too far to the other side where you can't anything online or you get CoC broken over it.
Just like in the real world, some language is appropriate at the library and some is better saved for the bar.
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.
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.
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.
https://stimulusjs.org/
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 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.
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.
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.
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...
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.
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.
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
[2] https://elixir-lang.org/
[3]
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...
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].
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.
> 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 c...
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.
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]?)
[0] https://github.com/ruby-formatter/rufo
-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.
Oh boy, this is in one sentence almost everything that is wrong with Rails...