I've a bunch of small Rails apps running on Heroku and I've to say that I'm impressed by the relevance of the new features in the latest Rails releases. Action Text, Active Storage and Action Cable are solving common and painful issues in any web app.
I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box.
The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers.
I've been trying to use NodeJS after using Rails for years and it's just such a terrible experience. I don't want to install every basic package by hand and generate every model and view and controller by hand. This is basic boilerplate nonsense that made Rails so popular 15 years ago, and NodeJS throws away every lesson we learned from Rails.
React is okay as a front-end but without a full stack framework, the current state of Javascript is like stepping back into 20 year old PHP development, where everyone just hacks together anything they can find with no structure, no convention, and no security.
Like others have mentioned, this is an apple vs orange comparison. Ruby & Rails is not the same as NodeJS. A popular framework which you probably used with NodeJS is Express, that as its documentation states tries to be a minimal framework for creating NodeJS servers. I agree that something like Rails has its own benefits, but I can't really take seriously this type of complaining when it's directed at the wrong thing. You're complaining about frameworks, not NodeJS the runtime. And NodeJS is not fixed to some specific framework that forces you to do things in one way. And thank god for that.
There was some initial burden I admit with NodeJS but I have at least got to the productive plateau (with TypeScript). Once you figure out the pattern that works for you, it gets simpler. The inventing part is what drives most developers crazy, and it did for me too. It's perhaps too non-restrictive but well, hopefully there's somebody in your company showing you the right way. And you don't want to install every basic package by hand? But have them already included? You understand that adds quite a bit of bloat to projects that have no need for eg CORS or body-parser. And "code hacked together" is only a problem with bad programmers, you can get working and secure code with NodeJS, it just needs thought put into it. And yes, Rails has advantage with this but I think you made that argument clear.
Instead of making the argument "NodeJS is bad" you should aim that at the frameworks of NodeJS. SailJS was a good attempt at Rails but it's way too restrictive with its patterns (and sadly the documentation is not good). Deno looks promising and I hope people will be building better frameworks on top of that.
I think the point is more that a Rails style framework does not exist in Node. There are a few projects that have attempted to be like Rails, but none that appear to have succeeded in any real way.
In the Ruby ecosystem, Rails will get you very far. In Python, Django will do the same. PHP –> Laravel. Scala –> Play.
JS does not have an equivalent, and the community seems to actively dislike the approach. That's fine, a monolithic framework approach isn't always the best option, but in the Node ecosystem it's not even an option on the table.
Well your argument is a lot more nuanced than the original comment I responded to. And I agree, it is burdensome especially for people not familiar with NodeJS that there isn't a one-size-fits-all framework. I don't really know the main causes why it happened, but I guess people felt satisfied with Express & Koa though it left, and still leaves, a lot for programmers to do by themselves.
Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say SailJS to make it work. Nevertheless my experience with ORMs or scaffold generators has been that I always feel they are one custom use case away from turning from time-savers to time-sinks. When you write your own SQL and implement your own models/services or whatever abstraction you decide to use, you get a much deeper understanding of what is going on than just trusting your framework to do it for you. And is that good or bad? That is certainly a topic for debate.
> Perhaps because Express & Koa were "good enough" there never was a large enough momentum behind say...
This is interesting to me, because Ruby has Sinatra (and others) that compare well to Express/Koa. Python has Flask which is very popular, as well as a number of fantastic alternatives. These ecosystems have very mature, well designed, small web frameworks, but still people choose the larger frameworks in these ecosystems, and all of the frameworks get good maintenance.
I wonder if it's a cultural thing in the JS ecosystem. Maybe the ease of publishing a package creates a race to the bottom in terms of package scope, which makes it so difficult to sustain larger more all-encompassing packages.
I've worked with Ruby+Rails/Sinatra/Cuba, Python+Flask/Django/Bottle/Sanic, and Node+Express, and when I was in the Node ecosystem I sometimes really wanted that Rails/Django equivalent – not always, but the lack of it would cause me to avoid Node for large backend projects.
I am a big fan of Knex for just this reason. It's not an ORM, just a migration manager and query builder. It makes easy stuff easy, and for complex stuff it gets out of your way.
If you need complex relationship models, ObjectionJS sits on top and will auto-manage relationship tables and all that nasty stuff for you.
Express is not a framework. It's a library that just lets you set up routes, and a pretty minimal one at that. Calling express a framework would be like calling the routes.rb file in Rails a framework - it's not. It's a small part of a framework. NodeJS the runtime is great (although the number of deprecated functions in core is depressing). Node the ecosystem is a nightmare.
I'd echo the sentiments of the other developers here. Building a backend or full-stack app in Node is painful at every step of the journey. You're writing basically everything by hand, while using sub-standard orms and route handlers.
I've decided I like React enough to continue using it. But I'll be sticking to Rails for the backend.
This totally misses the point which is that there is no equivalent option in the node ecosystem. Ruby would be some toy project for enthusiasts if Rails hadn't come along and given huge numbers of developers a compelling case to put it in production.
It's not clear to me why people make this choice with node when after you choose it you are left to solve solved problems from scratch. Chosing node is the explicit choice to enter an ecosystem that does not have good cohesive solutions to basic problems. To do things that could be done easily with a framework like rails the very hard way.
Yes I totally agree with you, it's not a fair comparaison.
My point was indeed that there is no real Rails equivalent in the Node ecosystem. Something mature which is supported by a large community over many years. Django, Spring Boot, Laravel, Phoenix play such a role in each of their language.
In Node you have to come with your own set of libraries, structure and convention, which is not the most efficient way to start and maintain a project. I agree that more senior programmers might avoid most of the common mistakes, but still you might spend time discussing little details such as structure and conventions. Frameworks such as Rails make at least some of those discussions irrelevant and allow you to quickly move on.
Well I just replied to a comment before you, but we are definitely on the same page here. It's a mess when you start your first NodeJS backend, especially if there's nobody to help you. You'll probably make some terrible mistakes in your design that have to be later refactored. It's a downside but hopefully things get better. Maybe Deno will give us a fresh start.
You're right, it's not a fair comparison. Because there is no fair comparison. That's the entire point. There is no fair comparison between Ruby on Rails and anything in the NodeJS world because nothing like Rails exists in the NodeJS world.
This right here. This is my main beef with node. I love js and the ecosystem can be amazing, but just give me something that I can use to focus on the business problems.
In the end I think Rails and Node have different purposes. I would still use Node for proxy-style servers. Something with a small and focused scope which has to scale.
For business intensive apps with a large scope, Rails-like frameworks are still way more productive and robust even if they are less trendy for the moment.
The current frontend state is another story indeed. Frameworks like Ember tried to bring the same Rails-like structure to the frontend world but it isn't as popular and trendy as React for whatever reason. I think it's very costly for frontend teams to reinvent a coherent structure, convention etc for every new project. At least React has brought the same way of thinking in the frontend industry.
I'm new to the Rails ecosystem but from what I've seen and also with many years using Django (which is very similar), I would agree with your assessment regarding Rails. The complex monolith that speeds up development very much has its place, especially at the beginning of a project. You can always cut it apart later as needed.
Regarding Node.js, however, I would say the pain is not worth it. For the same purpose I would now reach for Go (for networking stuff) or Rust (for high performance). This is after several years in a Node shop.
It’s exactly what I find so great about Ember (beyond just preferring a true templating language for front ends)
React bringing the “same way of thinking” in the front end industry may be true now, but it definitely was not the case for many years. I saw three or four react projects and they were architected very differently, with different routing, different state patterns, different approaches to updating backend state, different build systems, etc.
That's because React is a UI library, not a monolithic batteries-included framework. Amazing to me how often this is misunderstood. React's relatively narrow focus is one of its strengths.
I think this is also a weakness as mentioned in the previous comment. React is dead simple and has a limited scope... but now what happens when I went to pull in external data, use react as a router, or manage complex data? Well, now authors have to decide which libraries to use in conjunction React, which can vary wildly from project to project. This is something that Rails and Ember has tried to avoid.
Agreed; of course there are tradeoffs! "What happens.." is that you can use Mobx instead of redux bc it's easier to reason about. You can have some preferred way of doing things, and let React be a component-level implementation detail. Pros and cons abound in choosing a bells-and-whistles, batteries-included framework vs taking on the overhead -- and upside -- of composing a set of preferred libraries or tools. I never said "React is always a better choice than X." I said "it's not apples:apples to compare them directly". For which I got downvoted? sigh
No worries! I didn't mean to imply you'd downvoted me. :)
meta: I won't mind _this_ comment being downvoted since we're so far afield from the OP, but it's worth it to me to clarify intent in responding to a friendly peer.
I doubt that you can run Netflix on any single server no matter of the webframework.
Besides that Netflix itself is a Rails user for many applications (most of them for internal purposes).
It seems the bottleneck with netflix would be storage requirements and number of PCIe lanes for extra NICs. I really don't see how, "This framework couldn't run a site that accounts for up to 40% of internet traffic at peak hours on one server; clearly it's terrible!" I like scaling as much as the next guy, but Pareto dictates (as does experice) that most stuff is simple business logic with an interface.
Definitely agree with this. I have been switching from developing in ruby into Node 2 years ago as I thought this was "the new thing" for web apps. Now I just want to move away from Node. Large scale Node applications looks like 20 years ago, copy and paste all over the place, cheap libraries, no developer happiness, you have to reinvent the wheels, etc.
It's very easy to build small things with (small API servers, proxies, tools for example), development of those things is quick, the development feedback cycle is extremely rapid, JS is a bit of a lingua franca (for better or for worse), it is extremely easy to get set up (again, for simple things). In turn this created a huge community, which in turn triggered a virtuous (?) circle, and gave easily-installable libraries for almost anything you can think of. It also should be said that it is good at what it does. The reactor pattern works well in specific use cases and is easy to understand -- which I guess is the main cause of it being used as a general purpose hammer. Yes, it has glaring issues, but the "silly JS programmers with their toy language wanted to write backend servers" meme is a bit annoying.
Because there are an awful lot of JavaScript programmers out there, and Node let them apply the skills they already had on the server side for the first time [1].
[1] Technically, Node didn't invent server-side JavaScript; Netscape's application servers supported a version of the same idea in the '90s, back when Netscape was still a thing. But there was a long period where JS was effectively ghettoized as a language for browser scripting only, and Node is what broke it back out of that.
I believe for small projects it can be interesting, you can have an instance up using 50 MB ram. Also the language is widely used. JS is used in the frontend so they believe it's great for the backend also because you "reuse" the code. In my experience close no code is reused from frontend to the backend and vice versa.
Laziness I think. People wanted to use the same language for the backend as the frontend rather than picking their tools based on what does the job the best.
Agreed that picking the right tool for the job is essential. But you might want to revisit your assumptions about the benefits of baking in such a hard separation of "frontend" and "backend". See Gatsby for example.
I know this might be an unpopular opinion but I personally think a hard separation is required because the frontend and backend development solve different problems. Sure they're related but it's like the distinction between SQL and backend web service code. Sure there are tools like ORMs however they never compare well to well written SQL from engineers who understand databases. Likewise understanding the distinction of requirements on the frontend vs backend is just as important.
It's funny because many frontend web developers are keen to point out the distinction between Javascript, HTML and CSS and the importance of why HTML and CSS are distinctly different mark ups. Yet will then discuss frontend and backend code as if it's the same beast.
Maybe this opinion is an age related thing though. I've been publishing websites since the 1990s ('93 I think my first site went live). So I've always seen frontend and backend as separate entities - as they were for most of the web's evolution.
I think you misunderstood me, or we're talking past each other a bit here; I've been at it professionally since about 1998, so any difference in perspective is unlikely to be age-related -- at least in the sense of depth of experience with the tradition.
"The right tool for the job", yes, of course -- but why would you insist that a particular set of traditional architectural constraints must needs be permanently enforced at the level of language and runtime? Being locked into a "3-tier architecture, server-side" perspective is a common trap for many senior developers. As is dismissing the real (and amazing) progress and expansion of possibilities inherent in the accelerating changes in front-end technology. Of course there are ignorant juniors. Of course the signal:noise ratio in the world of modern web and mobile dev is suboptimal; there's so much churn and noise and froth. But also progress, evolution, improvement. To write it all off, clinging to comforting notions that what we mastered a decade or more ago is the best -- let alone only -- way to do it?
"The difficulty lies not in grasping the new ideas, but letting go of the old."
I don't disagree that Javascript has evolved into a first class language now but it hasn't always been. Your rhetoric - while lacking a lot of technical content - are valid for the current state of play but not the question being asked. Back in the early days of Node it was complete garbage but people stuck with it because they wanted a single language to rule them all and browsers wouldn't support anything beyond JS (despite how crappy JS was back then). So the reasons node gained any momentum in the early days was simply because:
1. it was too difficult to get any other language first class support for browser scripting (the reasons for that are obvious)
2. frontend developers wanted to reuse the same language for front and back (often because they simply didn't want to learn another language).
Let's also circle back to my point about the right tools for the job. Javascript has always made some sense for frontend development - it might not be the best designed language from an academic perspective but it suited browser scripting well enough to get the job done. Plus in the early days we didn't need anything particularly pretty anyway. But JS definitely did not suite backend development when Node was first being deployed. In fact I'm pretty sure Node was just a hobby project where some guys thought "Chrome's JS VM can run headless - lets see where this takes us." (this part may be incorrect but I have a vague recollection of that being the case). However without tools like Docker nor any decent way of running parallel execution stacks (nor a first class web server supporting Node ala mod_perl / mod_php / phpfpm / et al) it meant Javascript was simply not a good language for backend development for a relatively long time because the tooling wasn't there and the language lacked the primitives to compensate (like how Python, Perl and Ruby could all self host their own threaded web server).
These days Javascript still doesn't support threading but it does have other primitives that do a reasonable job of compensating. Plus with tools like Docker, you can always scale sideways when your application failed to scale upwards. The tooling around JS has improves, the language itself has improved and the way we host web sites has also evolved (eg cloud environments running containers vs VMs or even bare metal servers running web servers written in C++ which spawn language VMs as separate processes). The whole landscape of backend development had to change as well as Javascript itself before it really because a first class backend language.
So to summarise, yes you're right to and extent. But you answer a subtly different question: "why is node still popular?" rather than the question I was answering: "why did it become popular?"
Ironically it was the popularity that gave node the momentum to improve; rather than node initially being good that gave it popularity (though obviously node improving would have had a snowball effect on node's popularity as well).
Definitely a fair point about addressing the original question. IME, node _became_ popular in part because it allowed web developers to start solving problems themselves, directly, using a language they already knew [albeit a kind of terrible/problematic language at the time], to do things like CLI scripting for automation of tedious FE dev workflow tasks (a la Grunt and bower), or standing up dirt-simple web servers. At that point the floodgates had opened. With the concomitant (and ongoing) shift in architectures toward executing more and more of the application on the client side (with hugely popular services like gmail and google maps demonstrating the power of "Ajax"), the rest became almost inevitable. With Node, like Javascript in general, the quality followed the popularity, as world-class engineers set to fixing and improving what was available to work with, to shape it into something better-suited to the task. The process might even be ~akin to selective adaptation in biological evolution.
I agree, but from my observation bad code is more significantly more widespread in Node. The tooling is just incomplete by default, you have to setup yourself. Further the projects structure is completely different on every project (and typically not nicely done).
Speaking of PHP, I'm really enjoying using Laravel as of late. I'm not super experienced in web development, but the Laravel experience is my favorite so far. The Laracasts tutorial series is also top-notch. I really wish other projects had official video tutorials like them.
Other comments listed npm modules with Rails equivalents, so I won't repeat.
The one thing I got out of nodejs is becoming reacquainted with working closer to the metal. Minimalism for some HTTP endpoints (what the kids call REST) can be fun.
Rails, PHP, nodejs et al, J2EE, etc. I've got no dog in this fight. Each is uniquely terrible. I hate them all.
I'm currently working with it for a project atm, I can not recommend it, it's ORM is pretty bad, cutting corners wherever possible, but the worst thing about it is its documentation it is badly redacted and relies a lot on examples rather than laying out the possibilities of what you can do with a certain part of sails, issues also go unattended for a long while and there's not much of a community surrounding it.
Just my two cents, I would be happy to hear some success stories from it though.
I worked with sails about three years ago. It was a decent experience, but Sails 1.0 has been years underway and seems like a major rewrite of the whole thing. I don't really think a great many people use Sails anymore, and I don't think I would recommend it either.
I worked with node for 5 years and never came across anyone using sails. That might be a symptom of the node community but last I saw it still wasn’t very good.
I basically agree, but there are some people fighting the good fight against Node's awful ecosystem.
- Parcel is like if Webpack were a build system and not a programming language to create a build system with.
- Vue has good set of solutions. Nuxt is a nice version of "here's what you're probably going to want, already glued together."
- If Deno ever becomes a thing, it will be cool.
It feels like maybe if we're lucky, in five years, there will be an ecosystem for modern JS that doesn't suck.
It's too bad that Node.JS is mostly used as a scaffolding and glue language for web frameworks, while where it really shines is as a replacement for a systems language. You sacrifice 4x performance to get better safety, less development time, easier code, easier deployment, and a more open and friendly ecosystem.
Replacement for a systems language? How are dynamically-typed callbacks, as in Node's fs library, in any way comparable with, say, go routines or good old procedural C++? Async is the worst programming model for building systems.
The Node.JS libraries also have Sync (not async) alternatives. But everything is async by default. JS/Node is single threaded, but supports multi process concurrency with message passing and sharing of sockets.
I personally prefer callback convention, but it's not the only paradigm. Primises/Futures, and async/await is also very popular.
Node.JS makes you think async, which has a learning curve, but I prefer that over multi threading locks and data races.
Go is also great. But I think JavaScript is much easier.
"Nobody uses just React+Express w/o TS for something serious." Hardly. Just search for "(react.js or reactjs) (nodejs or node.js)" on indeed.co.uk. 441 results. Now append "-typescript" to the same search. 378 results. It appears Typescript hasn't yet taken over the world.
Most companies using typescript don’t advertise for typescript developers and will simply look for JS decelopers, because the belief is that anyone should be able to transition from JS to TS so why limit your scope.
>You're comparing a runtime environment to a framework
Yup. Because there is no Rails-like framework in NodeJS.
>Use Angular on the client and something server side
That "something server side" is the entire problem. In 2006 if you're writing a web app, the answer was Ruby on Rails. In 2019 the answer is "Angular or React or Vue on the front end and something server side". No generators, no scaffolds, no auto-generated migrations, no opinions, no ORM, no standardized way of doing anything, no naming scheme, no guidance. Just "something server side".
If I said "use Ruby to create a web app" you'd load up Rails. If I said "use Python" you'd load up Django. If I said "use NodeJS", you'd just... list all your NPM packages?
Yeah, you're right. I don't know why that is.
You can properly engineer stuff in Node but there are no "rails" to guide you so I get that more projects will be a mess as compared to Rails or Django.
To be honest I wouldn't suggest Node as a solution for your backend which is probably why I said "something server side" because when I think Node I just think of a thin API wrapper that uses an RPC to call your Java services or what-have-you. The only reason you even do that is to give the FE people something to mesh data together from services for their clients while you can keep backend APIs generic. Luckily graphql will start to replace that convention.
Makes me want to build such a framework in TS... but why would I do that when I can just use Spring. :)
If you just use TS without really understanding how it can help you and your particular problems you're solving, it can be more of a burden to refactoring than a saviour. Type systems are not a panacea for refactoring difficulties.
I agree that TypeScript is great, but I've seen it used to establish its own kind of technical debt is what I'm trying to say. If you establish types for your poorly designed application it will only entrench bad design deeper. So, throwing a type system at that problem isn't actually helpful at all in cases like that.
I agree though that using TS and not worrying about actually defining types can be great. I do think you can run into sort of wandering inference bugs or cases where other peoples' types can be poorly defined, but that's a rare problem in my experience and well worth the benefits you get otherwise.
Anyway, I'm definitely not trashing TypeScript or suggesting no one should use it or anything. I almost always start new projects with it.
From what I've seen of Loopback's verbosity I think the best comparison would be with Spring. For some reason every time the corporates get their hands on a dynamically-typed language they try their best to turn it into Java/C#. Facebook did it with PHP and now Microsoft are at it with Javascript.
The main pain with Node, if you come from outside, is being able to know which modules are well supported, and will be for the years coming.
As an example, I spent quite a long time investigating ORM libraries for relational DBs, and the projects that were half dead were the majority.
Knex was suggested by everyone, but at that time the project leadership was changing so the future was uncertain. I settled on Sequelize, which had most of the functionality, but several points did not make sense:
- the documentation is hard to search
- I had to create a PR for sequelize-cli (separate module, that is not recommended for production!) to get the same functionality of `rails db:create`
- the syntax was changed to use Op instead of strings for security, in a minor version
- the way associations are defined is weird at best
- no support for ES6 in the cli, so all migrations are ES5
Etc.
And this is just for an API server. I looked into the frontend part and it was so much work.
I am still using Node for server processes when I have to, but I wouldn't recommend it over Rails. The way you can generate a simple app that does something useful, configure it and deploy it to Heroku in few hours is unchallenged.
> know which modules are well supported, and will be for the years coming
Doesn't matter if you're coming from outside or not, no one can predict the future.
For example winston was probably the most recommended logging library (14k stars) and was a good recommendation at one point. But then they decided to do a rewrite for v3 which introduced a ton of bugs and incompatibilities. I spent several days trying to get it to log in the old format and failed and ended up downgrading back to v2.
This is a recurring theme in the js ecosystem (another example is react-router which is just a huge piece of shit and no one should depend on it despite its 37k stars).
Totally agree on the ecosystem being problem number one. A ton of modules that depend on a ton of other modules, poorly coded, not maintained, not tested.
Put on top the fact that NPM doesn't want to deal with version conflicts and installs 173 versions of the same package and you get a huge directory full of security warts.
These replies to this question say it all for me. Routing should not be some library research task for the developer. How do I have time to review these packages and all of their million dependencies for security issues or just bad design.
No one does, they just throw it in production and hope whatever way they figure out how to get the thing they need done at that moment doesn't burn them later.
I would have said reach-router, as it seems fairly well thought through, is constrained, and was originally an attempt to correct deficiencies in react-router. But it's being merged into the next version of RR.
What anm89 says is on point. All solutions available are awful in their own special ways. If a router solution _is_ needed, and there's no chance you can't just rely on the browser history API, imo stick with RR despite it's major downsides, because at least there is the major benefit of vast community support; all solutions seem fairly shit otherwise (just cross your fingers you don't need to do any React Native work that needs a routing/navigation library cos hoo boy it's a shitshow)
I had this issue recently where I wanted to revive an old side project I worked on a few years ago. The front-end was written with React + Redux + Webpack, which I assumed I would still be able to get running today, but it ended up turning into dependency hell (even though there were version numbers in the package.json, npm doesn't lock to those versions?!?).
The backend was written in Go, and I just ran go build and it worked without problems. The fact that it just worked without me having to change anything shows how important backwards compatibility is to that community.
The past few weeks I've been working on a backend Typescript project, and the number of packages I've seen that don't use semver or any similar versioning system makes me cringe. I even saw one that wore this as a badge of honour in their README :s If you release a library and you don't have a sensible versioning system, you are just making life harder for your users. (I'd argue for a CHANGELOG too - the GitHub releases section doesn't count)
NPM added the automatic lock file feature only after Yarn came up with it. I remember using Rails before Bundler was created. Man I don't wanna go through that ever again. Never use a package manager that doesn't cache versions!
Node's main problem is that the only real dominant framework is express, a Sinatra like framework. Other than that there's so many redundant libraries and frameworks, that it's hard not to suffer from the paradox of choice, which eats up a lot of time. It's a bit easier though if you limit yourself to using Typescript based frameworks; less choices.
Everybody is aware of this. The point is why would you choose the node ecosystem for any complex task when it forces you to manually solve all of the things Rails does for free. It's insane for a project of any complexity except for very specialized cases.
Put another way, you're exactly right, it is apples to oranges, or a better analogy might be a Porsche to a Pontiac. Why would you ever choose the thing which is inferior in almost every way?
From the comments it does not look like necessary everyone is aware of this.
You should have a look at things like adonisjs.com to get a better comparison. I am not saying node-based tech is better or worse, but to dismiss all nodejs server side and say Rails is better at everything is not a healthy attitude, especially regarding the shaky history of the Ruby language itself (eg. The whole RubySpec thing).
And; how can node be inferior in every way when it isn't even the same kind of entity? It seems you are barking up the wrong tree.
It is a testament to how successful Rails is when it is hard to distinguish it from the programming language it runs on. Congrats to them.
There’a an architectural lesson to be learned/recalled here for “hardcore” developers.
I didn’t realize that Github ran mostly on Rails until this article and was kind of surprised given the scale of the site and Rails reputation for performance.
It’s a great reminder of architecture/design truism: if your site is not inherently performance bottlenecked, then you problably shouldn’t let language or framework performance be the sole deciding factor in choosing or whether to migrate to a platform. Unless we’re talking about >= order of magnitude difference, or a site whose user experience is being limited by performance. Perf and scalability are just one factor.
Pragmatism across many factors with perf/scale being one, and making yourself as blind as possible to technology religion, biases, personal investments, and digging beyond simplistic conventional wisdom (rails has perf issues), looks to remain a core ability for making arch decisions.
Experience can actually be a
negative: I wouldn’t have a problem developing efficiently in node or coming up with an alternative to migrations for
example.
But what I can or
cannot ramp up on quickly the fastest is likely irrelevant and maybe detrimental when considering what’s best for a project as a whole.
Seeing comments here about productively gains from specific Rails features, and another comment saying they can’t imagine living without migrations as a built in feature, just seem like great reminders of how important it is to try and avoid making decisions relative to the experience or needs of only one or a few people.
It seems like good tech arch decisions need to consider DX issues enough to seem very similar to good UX decisions, the primary contrast being the users have very different stories and requirement scenarios.
As someone who did their first "serious" web development with Node, but has worked for the last year at a Rails shop, I still love Node for my personal projects, but much prefer Rails for anything that requires collaboration.
Ryan Dahl has a speech about his regrets with Node, and most of them center around the way code is managed.
IME, the sloppiness to how code is managed in Node, combined with the lack of conventions/dominant Rails-esque framework in the Javascript ecosystem, leads to codebases where no one is sure how or why something is set up the way it is.
As annoyed as I sometimes get with Rails' forced conventions or auto-magic abstractions, the beauty is that they are consistent. With a team full of experienced Rails engineers, you can pretty much guarantee that multiple people on your team can explain the "why" behind something quickly. This is a massive productivity save, especially when you're ramping up.
My two cents is the sweet spot for node is as an auxiliarily tool rather than a whole web app framework. For instance adding some realtime functionality to an existing app, as a server renderer for SPAs or some microservice glue. The community has resisted large rails-like frameworks from the beginning and I think it just shouldn't be used this way.
Well, I don't believe rich text editing and websockets are that common to be included in Rails by default. I can't find any excuse for not distributing those features as separate gems.
It's not that hard to add "gem actiontext" to the Gemfile and run "bundle install" if you're one of that 1-2% who needs WYSIWYG.
I don't have any numbers to back it up but I believe you're wildly underestimating the number of Rails projects that need WYSIWYG editing. The state of WYSIWYG editors in Rails is so unacceptably poor that I'm glad they're bundling it out of the box. It's kind of like Microsoft making their own laptops, because every other Windows laptop of the time was undeniably junk.
It looks like a decent WYSIWYG editor was one of the headline features of this 6.0 release. Its straight from Basecamp so you know its polished to the hilt.
Yeah, I am extremely excited about this - small sample size but I've worked on a handful of rails apps and I seem to always need a WYSIWYG editor and could never find one I really liked - glad to see it better incorporated!
> the state of WYSIWYG editors in Rails is so unacceptably poor
Rails is a web framework. Why does it have anything to do with a WYSIWYG editor on the frontend? There's a giant vast offering of WYSIWYG editors to choose from that POST data back to your web backend just like any other form. I don't want rails to have any opinion or "state" of WYSIWYG selection for my application.
I kinda feel like Rails had it's heyday around 3.2 or 4.0 and since then has been creating problems to solve instead of solving actual popular use cases.
>There's a giant vast offering of WYSIWYG editors to choose from
As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works.
>Why does it have anything to do with a WYSIWYG editor on the frontend?
Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
> As someone who has tried them all, I can definitively say this is not true. Trix/ActionText is the only one that works.
That's an obviously false statement. There's like a dozen react based ones alone and at least as many vanilla JS ones all over the web. I've implemented several in Rails before with image upload support. Works no differently than any other web backend.
> Because Rails is a full stack web framework. It includes its own front-end for tons of stuff. It's opinionated and wants people to do things The Rails Way.
No, Rails explicitly does not have opinions on everything. It doesn't even come with built in authentication handling, which is a pretty major web framework component. I like that it has strong opinions about things like handling the HTTP request/response, configuration, code layout, ORM, etc but leaves a lot to the user to implement. In the past they've even culled features off into their own gem when they decided it wasn't relevant enough. A WYSIWYG text editor doesn't seem all that much like core functionality to me.
You don't need to use action text if you want to go with an own solution. Action Text is so well integrated that inserting (and uploading) images via drag and drop works out of the box.
Of all the Rails projects I've been working on in the the last 15 years (all of them) probably only two needed rich text editing. One of them is the only Rails project I'm working on now. We're not changing the editor (ckeditor) but I could start a new project with the new default. I wouldn't mind installing it as a separate gem.
You're right about Node, but I think it's a bit apples to oranges because they're suited to different use-cases. Rails is great for mostly static sites. Node is great for mostly dynamic sites. It's almost as simple as that.
Whilst Node and Rails certainly have different niches the distinction between static and dynamic sites is lost on me. Both are written in dynamically-typed languages and both produce HTTP responses dynamically. What's the basis of your Rails = static sites assertion?
I didn't literally mean static sites ️
By static I mean I site like Github, Craigslist, Wikipedia. Stuff doesn't change often. Uses forms for submitting data.
By dynamic I mean sites that make heavy use of ajax, you want real-time anything, high levels of interactivity in the interface. These are often apps.
Rails has an --api option and most of the Rails roles offered by recruiters these days are a combination of Rails and React, Vue or Angular. Rails assets are served with webpack and there are options for React, Vue and Angular when creating a new Rails app.
Yes but Rails is still optimized for REST CRUD apps. It's great at those apps. I use it to develop those kinds of apps. But when you want something super reactive and customized and interactive and dynamic and real-time, I reach for Node.
If I wanted something super reactive, truly concurrent and real-time there are many better options than Node - Elixir, Golang and Clojure to name a few. I just don't get the Node hype - it's not the best tool for anything other than allowing JS devs to pass themselves off as back-end experts.
I don't want to start a flame war here, but I think Rails (and gem ecosystem in general) is a better choice than Django, at least for SaaS apps.
These are all my personal opinions, take it with a grain of salt. Having said that, here we go:
* Authentication - it is a pain if you'd like to deviate from the standard Django User model (using username to login instead of an email). I don't like Devise either.
* Asset pipeline, even though it is not updated anymore (sprockets) and partially replaced by the webpacker, is still better in Rails
* Configuration spread across multiple files, by environment, instead of a single config.py file
* Sidekiq has a better API compared to Celery. Also, Celery's default broker is RabbitMQ, not Redis. It is really hard to find managed RabbitMQ hosting, for Redis there are plenty
* Mailer previews, small but quite useful utility
* Better security by default: Rails comes pre-configured with a bunch of security headers[0].
* Testing - Minitest and Capybara is just a joy to work with.
* I prefer ActiveRecord over Django ORM
* Rails isn't afraid to deprecate things and move forward. This isn't the case with Django, which is big on backwards compatibility. I don't like it, since it puts into a disadvantage folks who are starting new projects. Different strokes for different folks, I suppose
I could go on and on, but I remember struggling a lot with Django/Celery when building a SaaS app. I decided to switch to Rails and haven't looked back (Rails has its warts as well). YMMV
I can't argue about your preferences here, but these seem to be subjective preferences or complaints about warts.
In terms of feature and ecosystem surface, there is one area where I think Django is a clear winner: Django Admin. It is a very mature part of the framework and there is a large ecosystem around it. Compared to how useful that is for standing up an MVP SaaS (especially in anything remotely enterprisey), I would find it difficult to consider Rails if I ever envisioned needing admin.
For what it's worth though, I think that Django and Rails are both exceptional choices and in terms of ergonomics, best in class. I wouldn't have complaints about the framework to coming into a project using either one.
I don't do webdev, but have primarily used Python for 10+ years. I've dabbled in both Rails and Django and agree with the parent's points. I would have stated them myself, but it was probably 5 years ago and it sounds like not much has changed. The arguments might be subjective, but they all ring true to me.
I thought Django Admin was cool when I first set it up, but as soon as I hit a few of the issues the parent mentioned, Admin broke or became irrelevant.
I agree that having admin baked in is very convenient for simple CRUD, which saves the time to query the database. For every other criticism of Django compared to Rails I agree with whoever posted them. Still, to address another debated technology, Django is far better than any JavaScript backend I saw.
The only comparison I can do is that Django Admin is built-in out of the box, so I use it on every Django project. Rails/Active Admin is not built-in out of the box so I've never used it and always built my own admin page.
It's super weird because Rails is known for convention over configuration and includes default packages for basically everything you might need EXCEPT auth and admin. Meanwhile Django removes a lot of the magic of Rails and lets you do it yourself, except for bundling auth and admin into the core product.
I used ActiveAdmin a lot when I started and it always gave me a headache. From what I have seen of Django Admin (admittedly not a lot) it looks very similar?
I have found that at least for my users, admin type functionality and views generally require a lot of custom work that is not easily turned into convention. About 4 years ago I stopped using Active Admin completely and just started using Ransack + Kaminari gems on their own. I have been a much happier with the way that pattern has worked out.
It really depends on the specific use case. It's possible to arrive at a point where you'd get more mileage out of using something like react-admin and custom API views. But, until you arrive at that point, something like Django Admin or Active Admin can get you quite far.
I've used Active Admin in previous projects, but eventually got tired of it. As of late I've been using administrate with pretty good success: https://github.com/thoughtbot/administrate
ActiveRecord is the best ORM I've ever used, in any language, and I don't know of an engineer I've worked with who disagrees, regardless of their preferred stack. Using `merge` on two queries still blows my mind. I've been using SQLAlchemy lately and it's a daily reminder of just how many things AR got right.
Rails has its downsides (helloooooo memory usage!) but for getting up and running fast and having a full toolkit available to get the basics done, it's a pretty amazing project.
SQLAlchemy is far superior to ActiveRecord if you already know SQL and write fairly complex queries. Once you get past a certain point, figuring out how to write or optimize a query in AR (or, to be fair, most other ORMs) tends to involve hunting down some obscure Rails-specific incantations, whereas SA maps pretty nicely onto SQL and doesn't try to offer as high of a level of abstraction. I've also found that it's easier to shoot yourself in the foot with ActiveRecord, performance-wise (though this has gotten much better over time).
The downside of SQLAlchemy is that it's less pleasant to use for simpler queries/tasks, so which ORM is better depends on the project. I've worked on codebases that never crossed that threshold, and ActiveRecord gave a consistently great developer experience. YMMV.
In fairness I haven't used ActiveRecord in a few years, but I really love the Sequel ORM for ruby over my previous experience with ActiveRecord. I feel like ActiveRecord can be a bit too magic for some of the more complicated things I have to do with my models.
+1 for Sequel. I've decided to try Sequel instead of AR for new project 3 years ago. Never looked back, feels like a breath of fresh air. Hope it will gain more recognition in the Ruby community.
I love ecto as well. I love pure SQL and interfacing closer to raw data. Phoenix/Ecto is where I'd gravitate starting a new project (we used it in production at our startup) for many reasons including the simplicity of deployments.
For people getting started with engineering, AR is a nice wrapping/mapping of SQL => object oriented models. There's a mix of productivity, approachability, and feature set that puts AR ahead, for me, as a general use ORM.
I would agree, though, with a strong and experienced engineering team Ecto and Elixir are quite nice.
It's been a few years since I've been involved in Ruby and Rails, but back then, there was a lot of controvery over AR. Not because of the quality, which has generally been excellent, but over the pattern itself; see the pushback against "fat models" and towards "service objects" for this kind of debate.
> ActiveRecord is the best ORM I've ever used, in any language, and I don't know of an engineer I've worked with who disagrees
Maybe it's morphed into a more general ORM in the 10+ years since I've touched it, but the active record pattern breaks down very quickly once you get beyond basic CRUD apps.
I have worked extensively in both frameworks and would add to this:
* Django has comparatively limited I18n and localization faculties compared to Rails (with Django’s i18n built atop gettext, which I always found kind of brittle with .po files/string-based keys)
* No intelligent/efficient class reloading in development. The whole development server just restarts when you make changes
* No reloader for the shell (horrible for developer ergonomics - you can't just type "reload!", you have to restart the shell to pull in any change)
* Caching faculties in Django are much more limited - no template digests (to make template fragment caching much more robust)
* ActiveSupport has also always been a god-send for productivity. It may seem small but things like “Array#to_sentence” and the time functions (i.e. 1.day.ago) are incredibly useful.
* No default assumption of multiple environments (no default development/testing/production configuration files, environment detection, etc). This is pretty ridiculous for a web application framework.
* No built in credential encryption (makes keeping a team in-sync with keys for integrations a comparative pain)
* Dependency management is much more challenging in Python. The de-facto virtualenv + requirements.txt combo is lossy (no dependency graph) and awkward compared to bundler. There are other solutions here but something so foundational shouldn’t be so hard.
Django was the first web application framework I learned and I still work with it professionally from time to time (as recently as ~2 months ago). I am just a bit stunned by how much it has fallen behind in terms of its broad state of maturity, community/ecosystem, productivity, etc.
For once a fair criticism of Django by someone who seems to know the framework well.
I don't quite share the same experience with i18n though. I always found Django statical code analysis to extract translation keys to be superior in many ways to other translation systems. It is giving useful context that are stored in the PO files and good translation tools use them. I also never had any issue with string based keys. You can chose an english based key or an abstract whatever you prefer.
Some of the annoyance you mentioned, that I agree completely, are more of a language issue like: reloader, or dependency management.
For multiple environments there is a very simple pattern you can put in place using an environment variable and conditional imports. something like:
from settings.base import *
if env == 'prod':
from settings.prod import *
A bit funny (sad) about the dependencies - zope, the early web application server - brought much to python (eg: eggs) - and essentially worked more like bundler + Gemfile/Gemfile.lock - with its zc.buildout dep (and more) manager. And like with ruby/rails, it could be difficult to get it to converge on "known good sets" of dependencies.
Take a look at this dated doc for zope 4 - anyone who's had to fight with bundler should see some similarities - good and bad i think:
I recently got up to speed with a rails app remarkably quickly and I agree with all of these points. I found testing wasn't really a joy, but it was less painful than any experience I've had in the python or PHP world. Mailer previews are actually very cool, too. It's not a game changer but I liked having it and it came in handy.
ActiveRecord was also surprisingly slick. I'd previously mostly used Doctrine and over the years I've mostly come to dislike it. AR was fine though and had some features I liked quite a bit. Scopes are really neat. Like any ORM though there are plenty of double edged swords all over.
I'm actually keen to work with Ruby more since working on that project. Rails is really nice, even if it's a lot different from how I'm used to working. It felt very productive.
Rails is a business tool. It allows developers to move quickly to build and iterate rapidly on the business vision.
This means a lot of interesting engineering work and optimizations are out of your hands. Some people think that's a bad thing, I think it's a great thing. Depends on your goals.
For me, I prefer Django, but I haven't used Rails in a number of years. In general I prefer Python over Ruby because it's more explicit and less magic, but Ruby definitely has its conveniences.
That being said, I am not a Ruby developer, I am a Python developer, so I'll try to address these points as best I can from the other side of the equation.
* Authentication - this is fairly simple to address. It's a fairly easy-to-use pluggable backend. It's not very hard to write a system to replace the default which would let you log in using other credentials. Also, a few years ago you couldn't replace the default User model - that has since been changed.
* Asset pipeline - fair point, but I prefer to keep my assets separate from the backend if possible - my current work project has a backend API in django with a separate frontend repo with all the JS/CSS
* Configuration - the best solution for this I've found is django-environ[0]. Alternatively, the built-in `DJANGO_SETTINGS_FILE` environment variable lets you specify a different base config file.
* Sidekiq/Celery - The API, I'll give you, however it's fairly easy to configure Celery to use Redis
* Mailer previews - I've used mailhog[1] before. This gives you a local mailbox to test with and will be closer to your final configuration anyway.
* Better security - possibly by default, but I haven't had any issues with django-rest-framework in the past
* Testing - pytest with pytest-django is also great to work with.
* Django ORM vs ActiveRecord - I don't have a ton of experience with ActiveRecord but I like the Django ORM. There's also SQLAlchemy, but it's a bit odd to rip that out of django if you don't need to.
I like Django because it's solid out of the box, but still provides a way to extend the core to be as flexible as you want. I assume it's possible to do this with Rails, but that's not my area of expertise.
I do appreciate you outlining things you like better as opposed to just saying "Django is terrible". I'll definitely have to try Rails again and see what I think of it now.
Is rails really that good? I feel so confused and paralyzed trying to find a modern backend framework. I've almost settled to Python+Django because it enforces good practices,has great tools like Django Rest Framework and Python is a language with huge application field. On the other hand, laravel and rails have so strong communities and feel more modern (for example, integration with front end frameworks). Django just seems left behind. So the question boils down to this: Should I invest my time learning django in 2019?
rather than the framework (which largely have parity, as far as i can tell), the big decision factor in my mind is between (1) how joyful it is to code in ruby vs (2) the power of statistical/machine learning libraries in python.
if you don't have complicated statistical/machine learning needs, i'd recommend ruby on rails every time. it's so fast to get started and productive. and the language is performant enough to get you to initial success (at which point you can choose to spend money to attain greater performance).
If you do not know Ruby, it is neither easy nor fast. You have to learn a brand new language and Ruby is quite a departure from C-like languages that most people are familiar with. Then you have to learn Rails and its conventions.
It is a huge mountain of work you have ahead yourself if you are a newbie in both domains.
Sure you might be able to slap together a simple CRUD app following a tutorial but truly knowing what you are doing will take months, if not years. It is a huge investment.
rails is a good technology that is more mature and boringish now. it's a solid choice to choose to learn. you can also go down the javascript route that changes faster than a more mature technology. realistically a lot of the concepts from any of them will be fairly transferable.
Rails is really that good. I'm a dinosaur in web development (I think). I've used everything popular for a decent swath of time: Microsoft's MVC, Java Apps Framework at Google, Django, Drupal & Joomla in PHP, Elixir/Phoenix, Express, and Rails.
When I first came across Ruby -- and particular Rails -- I loathed it. Ruby's syntax allows you to get pretty creative, and jumping into Rails + Rspec is like jumping into a Perl repo that's been managed by 3 different people over ten years. There's all kind of things that -- because the syntax is so loose -- it's not clear what's going on. It doesn't help (in my opinion) that Ruby's own style guide almost encourages this: dropping the "()" from functions that take no arguments; Eiminating "{}" around certain hashes passed into functions; The "!" marker having a seemingly different meaning in almost every library, etc...
When you're new to Rails and Rspec, it's easy to have no idea what's going on.
That being said, you can prototype an entire business in a few days Rails. It is that easy. It's incredibly polished. It's opinionated in mostly right ways, and all of its libraries are, too -- which means you don't often find people doing crazy shit (except Devise, everyone is always doing something crazy with Devise).
As much as I hated Rspec with a passion, I do feel like it's the best testing frameworks I've ever come across. It lets you be SUPER expressive about what you're testing.
I go against the Ruby & Rspec style guides on a few things, but I feel like no other combination let's you write code that's so expressive.
And, finally, anything you want to do in Rails has a library built in that does it very well. And unlike in -- say JavaScript for example -- there aren't ten libraries to pick from. There is a clear winner, and I think that's good for the community.
Also, almost every major API you can imagine has a Rails Gem so that it plays nicely with the framework.
Don't get me wrong, I loved Django and I still think it's a great framework. My love for Python, Elixir, and Kotlin are strong.
Ruby & Rails are by no means perfect, but I do feel like it's a very clear winner if you're starting a new web business. The number of companies I've seen flounder because they wanted an App + a website + (obviously) backend business logic... and all of that in one language, in one code base -- it's impressive. I've seen a lot of Rails businesses fail. But despite what people warn about scaling, I've never seen a Rails-based company fail because of Rails. Plenty have flourished -- Shoppify, GitHub, AirBNB, etc...
I could go on and on about the advantages WRT hiring, too. Don't even get me started...
It kind of depends on what you need. If you need to deliver working code in a hurry and either agree with or can live with the opinions assumed by Rails, go for it. I find a lot of what is in Rails somewhat overweight and unnecessary, and I’ve never see a Rails app age well. But in that respect I’m comparing Rails more to something like Flask than Django.
Seems like this describes any app in any language I’ve ever worked on. Certainly Rails apps are more prone to this phenomenon because of the low barrier entry. Having worked with apps that have grown from Rails 2 through 5 (and soon 6) it’s quite possible to build Rails apps that “age well”.
Case in point for a Rails app that can age well is GitHub. When they launched in 2008 they were probably using Rails 2.0.2 (best guess based on release notes).
To be fair, I've never seen GitHub's codebase. In fact, I'm not entirely sure if it's even still the same "Rails app", or if they've moved to a microservice architecture or something.
Agreed, any application regardless of language or framework can age poorly. I've seen some pretty solid "long running" Rails applications that were just maintained well.
I am only familiar with Django and Rails, can't comment about Laravel.
If you are building a basic CRUD app, definitely stick with Rails. If you are doing some kind of CMS or need machine learning pipeline, go with Python.
A warning about Ruby/Rails: some folks have moved on to shinier languages/frameworks and as a result there are lots of unmaintained gems (gems are 3rd party libraries in the Ruby world) out there. For instance, I needed a curl wrapper written in Ruby. Nothing worked for me so I ended up forking Ethon [0]. I am hesitant to send PRs, since I doubt that they will get merged. Now I am maintaining two codebases at once. I will probably rewrite it from scratch at some time.
A warning about Python/Django: dependency management is kind of a mess [1]. See linked discussions [2][3][4][5].
Faraday is a wrapper around several libraries, no? I needed more features that these libraries could offer, namely HTTP/2 support, brotli compression, timings for the requests (namelookup time, tls handshake time, connect time, etc..). Faraday and Net:HTTP is fine if you're doing simple HTTP requests.
Go's static typing is a bit old school. If you want a statically typed (yet flexible and powerful), native-fast, easily deployed environment, I would go for Rust. As of today it brings everything to the table that you need for reliable web services. The performance and memory safety are the biggest selling points for me.
I'm curious why it took a few hours to swap out the base user model? Unless I'm missing something, it's fairly simple to extend the AbstractUser class with a custom user model, and then assign `Settings.AUTH_USER_MODEL = 'CustomUser`.
That said, everything is easy once you know how to do it. If this was the first time you've done this or there was research involved, it definitely makes sense that it would take longer!
I'm mostly asking bc I'm curious if you came upon a level of complexity that I simply haven't encountered.
We made some heavy modifications to the user model to allow for authentication with a few different types of identifiers, including composite keys. Django expects you to set a single USERNAME_FIELD but we had to support more than one and that required changes to the auth system. By default it also didn't work with UUIDs as usernames so that took a bit of time to fix.
I don't see how your points were proven. The 'defaults' you're talking about take a grand total of ~10 minutes tops to change, and actually can come by 'default' if you use one of the available Django templates that are popular.
Your complaints are valid from a subjective perspective, but if your bar for something being "a pain" is really "took longer than 10 minutes", I can't imagine how you function as a software engineer as even in Rails there are many things that will take longer to do.
How about "I was struggling for days with Django which lead to a minor burn-out and as a result I lost several weeks of my time"?
That's when I decided to pick up Rails tutorial and it was probably one of the best tech-related decisions I made in my businesses.
I shouldn't use cookiecutter templates, plugins, scripts to make working with the software tolerable. It should just work and get out of my way. Well, at least when doing a greenfield development.
It took me about 5 seconds of googling to find a Django tutorial that describes how to change the user auth model and make the change in less than 10 minutes.
In comparison, I too could waste my entire weekend tinkering with something in Rails, but I instead choose to do things the right way and look up a tutorial to explain how to do it easily, which it sounds like you did with Rails. Why you didn't do this with Django instead of wasting weeks, I dunno.
Again, if you prefer rails for subjective reasons that's fine. But blaming Django for being "too much of a pain" just because it sounds like you chose to do things the difficult way is pretty unfair.
If you were struggling for days with Django, I really wonder how you'd handle writing line of business logic for paying customers, which is orders of magnitude more difficult than picking one framework among several that have feature parity. This could be a place for you to improve as an engineer rather than being proof of a framework being bad or "burning" you.
The defaults in Django work fine for most people. I've used rails before and it's a great framework but python has a much better ecosystem, especially if you're doing anything machine learning ralated.
Why does every thread about Rails on HN devolve into a thread bashing Django? Do Rails users have some kind of "little brother complex" compared to Django?
Every Django thread on HN usually involves a healthy amount of discussion about the pros/cons of Django, and it's really helpful. You would expect that Rails threads have a discussion about the pros/cons of Rails, right? Except instead, every Rails thread also turns into a discussion about the pros/cons of Django.
If Rails is so good then why do its users feel they have to constantly defend itself against non-existent attackers?
I don't know why you think the author was trying to defend Django or "attack" Rails? It seems to me that they were simply trying to point out the ridiculousness of Rails threads always devolving into "Rails vs Django" flame wars.
Totally, and that would make a ton of sense on a "I think Rails is better than Django" article or something like that, but on an article purely about Rails, this whole thread about Django reads like a non-sequitur. I was surprised to see this as the top comment, because it seemed totally unrelated to anything in the article. If you go to the article and ctrl-f for "django" you come up empty. So the pushback seemed reasonable to me.
Maybe I'm missing something, but I don't see the comment you're responding to as an "attack" at all. They're pointing out that the OP is "civilly discussing something" that's irrelevant to the topic of the thread, and that this seems to happen in every thread about Rails (which I have also noticed).
Because I've got burnt by Django in the past. If you do some search on the HN and elsewhere on the difference between two, the common answer that you'll find is that they are similar and it doesn't matter which one do you pick (given that you are not proficient with any of them). I don't agree with that premise and decided to make a case here.
So if you are ever in a position to pick between Django and Rails for CRUD-y SaaS app, go with Rails. You can't go wrong with that.
Because I too followed the common advice and started with Django (I only knew Python back then). Well, I hated it and got burnt out as a result. So, despite the conventional wisdom, I decided to change my stack from Django/Python/Celery to Rails/Ruby/Sidekiq and I am very glad I made the leap.
I have seen both sides of it, that's why I decided to vent it out.
P.S. Don't get me wrong, I have tons of respect for people doing open source and don't want to badmouth Django folks. But in my limited experience, it just wasn't a great experience.
This is all fair enough - you're entitled to your opinions developed through your experiences - but it's just not relevant to this article. Just because you got burned by Django does not mean it makes sense to pop into any thread about Rails and talk about how you got burned by Django. That's not what this article is about!
Because Rails and Django are two competing web frameworks which are majorly directly comparable, and it's good to know the pros and cons between each one.
Not everybody is an expert on both, so it's nice to see concrete lists like the one posted above.
Unless there's more you didn't explain, you weren't burned by Django -- at most you were lightly singed by your own expectations. Everything you've described is more a matter of "I liked this one more than that one" -- things that are so minor or inconsequential to the actual hard work in building a SaaS app so as to be rounding errors. On the other hand, you haven't described a single area where feature parity is lacking, so it comes down to a matter of opinion and taste.
He's not wrong, but you have a point. imo the reason I don't like Django as much is that there's not one way to do one thing like with python ie it's not convention over configuration. That said, it's still a good, mature framework and unlike Rails, upgrades aren't going to break your app (even though migration in Rails is easy as long as you do it often). Also it's nice to have a dominant framework in Python. Just wish it had the same philosophy as Python.
I've got my complaints about Devise, but I'll take those pains any day of the week over the alternative nightmare of "built in-house" authentication.
At this point, if somebody doesn't want to use Devise in a project I'm working on, they better have a _really_ good explanation. To me, it's like suggesting setting the building on fire.
I've found the "out of the box one stop auth" packages rarely deliver the experience that product managers / UX people have planned for. You're usually stuck with whatever workflow the library decides for things like forgot password, password expiration policies, 2fa, login methods, etc.
There are very legitimate reasons why your SaaS app might want a nuanced workflow for these things.
> I've found the "out of the box one stop auth" packages rarely deliver the experience that product managers / UX people have planned for. You're usually stuck with whatever workflow the library decides for things like forgot password, password expiration policies, 2fa, login methods, etc.
It's pretty effortless to override and/or completely rewrite the views/flow with something like Devise.
Overriding is simple when it's changing a view. I've found the exact opposite to be true if it's anything regarding the actual workflow. If you're trying to change the workflow, you're probably already in an edge case and you're usually dealing with documentation that isn't terribly comprehensive or updated and rarely relates to the change you are trying to make. You're usually stuck reading the library internals carefully and scouring Stack Overflow for other people who have attempted to make the same change (often only to find unanswered question).
Every time I've ended up in this scenario I've wished that I had just built from scratch in the first place.
Here's a good example of something I worked on recently that I highly doubt is simple to implement with an out of the box solution. I could be wrong - I have no idea if Devise can do it or how hard it would be (it wasn't considered because the auth handling was already implemented):
You have a multi-tenant SaaS application that needs to support the following:
* Accounts may have different password, lockout, and expiration policies.
* There's a generic "login" button on the marketing site that 50%+ of our users use. This generic login page must implement all account specific constraints (probably via a 2-step login form)
* Some customers have SSO. For some customers, using SSO is optional. For others, it is required.
* Owners of accounts have a limited impersonation feature that allows them to see only certain parts of information in eyes of one of their account members
* Accounts may have different password, lockout, and expiration policies.
I've had to do that with Devise. It was easy enough to fork the `devise-security` plugin and modify the configuration settings to handle lambdas. The lambdas were then set to pull the config values from the user's account configuration.
* There's a generic "login" button on the marketing site that 50%+ of our users use. This generic login page must implement all account specific constraints (probably via a 2-step login form)
That's super easy.
* Some customers have SSO. For some customers, using SSO is optional. For others, it is required.
I'm in the process of adding exactly this to my project's Devise configuration right now. It's a little tricky, but only because our previous attempt at SSO was very strangely done (and I now understand why so many users complained about not being able to log in).
* Owners of accounts have a limited impersonation feature that allows them to see only certain parts of information in eyes of one of their account members
User permissions are outside the scope of Devise, since it just handles authentication. But the Pretender plugin makes user impersonation dead simple.
>I've found the "out of the box one stop auth" packages rarely deliver the experience that product managers / UX people have planned for.
I’d love to see more pushback from devs on this. So many products nowadays provide an “experience” for auth which makes things unnecessarily difficult. Not showing login and password fields on a single page, ambiguous 3rd party auth rules, weird account linking logic, etc.
Custom built auth isn't as scary as you make it to be. I have done it myself and would do it in the future. You just have to be cognizant of what you're doing (i.e. simply copying Hartl's or Railscasts' tutorial won't suffice; see session fixation attacks).
If I were to bring in 3rd party gem for auth, I'd have gone with Sorcery rather than Devise.
I would have phrased it differently, but I see the parent's point.
You don't roll your own security. You just don't do it. There are far too many variables that you can screw up, and anything you come up with isn't realistically going to go through nearly as much battle-testing as a ready-made solution (either upfront or on an ongoing basis).
> Custom built auth isn't as scary as you make it to be
Custom-built auth should be scary. Anyone who's worked on the security story for a popular framework will tell you that.
If you're not scared by it I'd have to assume you're either not seeing large swathes of the problem space or you're a genius.
But everyone rolls their own security. Security isn't a feature of the application, it's a characteristic of every piece of code, workflow, and practice your dev team implements. I know this sounds like a platitude, but if you treat security like something that you should only let the experts handle, you may end up not paying attention to the security properties that end up in your control.
Don't write your own crypto. That's great advice. The idea that everyone's auth needs are so standard they fit for every app just hasn't been realistic in my experience.
Yes, you don't roll your own security. You use powerful primitives provided by Ruby and Rails, such as bcrypt, has_secure_password/has_secure_token, encrypted sessions, secure httponly cookies with prefixes + samesite attrbiute all served over TLS 1.2+, with HSTS and CSP
I'd argue that Auth itself isn't hard per se, but it involves hard things that you shouldn't roll your own, notably cryptography and session handling.
But those are things that people normally delegate to either libraries (crypto) or the framework itself (session handling).
Of course, there's lots of places one can screw up, such as sending non-expirable password reset tokens, revealing private information and membership status via F2A/reset tokens. But those are the kinds of screw-ups that can happen in other parts of the website too.
That said, Devise is one of the few things that I don't completely dislike about Rails.
> * Authentication - it is a pain if you'd like to deviate from the standard Django User model (using username to login instead of an email).
It's not so hard, you just define a custom user class -- plenty of SO snippets if you're lazy. Though I agree that it would be better if common user schemes like email login were supported out of the box.
>* Better security by default: Rails comes pre-configured with a bunch of security headers[0].
> * Sidekiq has a better API compared to Celery. Also, Celery's default broker is RabbitMQ, not Redis. It is really hard to find managed RabbitMQ hosting, for Redis there are plenty
There are several on Heroku, including with free plans. https://elements.heroku.com/addons/cloudamqp .
I agree that Celery has a bit of a learning curve (e.g. heartbeat, concurrency, etc.). The project is improving, and python overall is getting better at async.
> Django, which is big on backwards compatibility.
Version 2.0 breaks code from 1.11, which happened in 2017.
> I decided to switch to Rails and haven't looked back
Maybe Django improved since you last looked, and could merit another try :).
> I don't want to start a flame war
Nor do I. Both cake and pie are good. The ability to weave in the rest of the python ecosystem (e.g. pandas, keras) makes Django attractive to me for many projects.
No, I don't think many application security people would agree with you that Rails is more secure out of the box or in common configurations than Django. I don't think it matters much; the differences are probably marginal.
(I've shipped Rails applications and would probably not myself ever pick Django for a new project. Obviously, I do more security work than application development work).
If you wanted to avoid a flame war, you wouldn't have posted in the first place. Why bring up Django when the linked post is about upgrading a Rails code base to 6.0?
Job payloads are certainly not code; they're exposed to the developer as basically blobs of JSON, and the code lives in a "job handler" which is certainly itself not serialized.
> Your job payload should be pure data but Rails ensures that it is code.
Doesn't sound right to me. ActiveJob just serializes the arguments to the job. The job runners spins up the rails environment (i.e. the code) and deserialize the arguments before executing the job.
There is no code serialization as far as I can tell.
Every time a Rails link appears on the home page it's filled with a bunch of technical reasons on why Rails is good and then there's a bunch of posts about how other frameworks might be better. These are healthy discussions IMO.
But I think a lot of people overlook that one of the main reasons why Rails is so good / popular is that you get to see posts like the one we're looking at: Running GitHub on Rails 6.0
There's not too many other frameworks where there's a really strong track record of it running really popular sites (github, shopify, basecamp, airbnb). Not only are they popular, but they are well done sites that are pretty tech friendly. It just gives a sense of confidence that it will work for your small / large app and you don't get that with most other frameworks.
Knowing that billions of page views have been through the framework irons out so many edge cases. Both bugs and performance issues, and you often get that perk on day 1 when a new release is out because it's already been running on basecamp for months (and maybe other big sites too).
I mean check out this quote from the article:
> GitHub engineers sent over 100 pull requests to Rails 6.0 to improve documentation, fix bugs, add features, and speed up performance.
Combine that with the Rails approach of batteries included and you know that the core of your app is in good hands. You can't really go too wrong by using it along with a few well maintained gems.
Currently I'm looking into AWS Amplify, which tries to be the Rails of serverless. Building a serverless app as you would build a monolithic app sounds intriguing to me.
Perhaps an unpopular take, but what is described in the first paragraph as "smoother, easier and faster" than ever seems to refer to an upgrade process that has been going on for over a year.
> As soon as we finished the Rails 5.2 upgrade last year, we started upgrading our application to Rails 6.0.
> Instead of waiting for the final release, we’d upgrade every week by pulling in the latest changes from Rails master and run all of our tests against that new version. This allowed us to find regressions quickly and early—often finding regressions in Rails master just hours after they were introduced. Upgrading weekly made it easy to find where these regressions were introduced since we were bisecting Rails with only a week’s worth of commits instead of more than a year of commits. Once our build for Rails 6.0 was green, we’d merge the pull request to master, and all new code that went into GitHub would need to pass in Rails 5.2 and the newest master build of Rails.
Realistically how many hours of work went into this upgrade process then?
Edit: I should add I think it really is wonderful that Github contributed so much to the new release and was so involved. I'm just not sure that it is realistic or even ideal for the average Rails consumer to upgrade in this manner.
> Realistically how many hours of work went into this upgrade process then?
Rails 6 is not a month old yet. What this describes is co-development, over the last year, of Rails 6 to ensure that it meets the needs of a big, influential user of this OSS project:
> We were able to achieve this level of stability for the upgrade because we were heavily involved with its development.
This is not representative of a traditional upgrade.
That's a good question, but I also appreciate that a company with an older Rails install took the trouble to upgrade to the latest version under development and contribute and help Rails along the way. Maybe they should have said they could have waited but if one has the developer resources, it's better to be proactive instead of waiting for an official release and all of the sudden try to upgrade and run into a lot of unforeseen issues.
Agreed. The problem happens with convincing your clients to pay you to do so.
I have a client that I've been telling for 2+ years to upgrade from Rails 4.2.3 (and Ember 2.8), but they only now funded it. So I'm having to do 3+ years of upgrades and it's a huge headache.
And at the end of it, if I've done my job correctly, the app will look identical.
Rails at least has upgrade guides and a script that allows you to upgrade the app. It helps to go from one point relase to the next. I also find the Railsdiff web app helpful in comparing changes from one release to another. It's definitely not perfect or pain free though. I also hope you have a good test suite :). Good luck.
I just did an upgrade from 4.2 to 6.0 and the process was definitely much smoother than previous Rails upgrades, suspiciously so. Glad people are working on improving the upgrade path because it used to be rather painful.
While they were upgrading, Github added a lot of their own core features into Rails itself. Like multiple databases supported by default, parallel tests for a much faster test suite. Github didnt just upgrade their Rails version, they upgraded Rails itself partly.
It's probably not realistic for the average Rails consumer to constantly run tests against master. Indeed, that's probably true for every framework, not just Rails. But it's definitely excellent for some sites to test against their framework's master branch. If nothing else, that greatly reduces the likelihood of painful upgrade paths (these often happen because of gratuitous API changes that ignore the needs of current users). You should have a test suite anyway, so modifying your CI to also run against the master of a key upstream may not be as bad as you think.
Alongside the excellent recommendations for GoRails in the other comments, also look into the host's other Rails projects: Jumpstart Pro [0] as a template and Hatchbox for easy deployment. This corner of the Rails ecosystem is really nice, positive, and easy.
Every successful project is going to get hate from somebody; if anything else, those who don't like some of the choices of said new successful project will be worried to be forced into them, and some will react finding any possible reason to stop the momentum.
Rails 6 really is a well-rounded update. It seems the new trend goes towards "bare-bones" http servers, but I'm insanely productive in a Rails app, even if it's one I have not worked on before.
I've seen quite a lot of "Rails-hate" over the last view years, and it can only be coming from people who never got to experience the world that was web development before Rails: Every project had it's own, usually quite creative, structure. There'd be configuration values in `config.inc.php`, but also in `configuration.php3` and `config.old.inc`, and `index.php` and so on. Just by establishing a standard folder structure, DHH probably made web devs everywhere twice as productive.
I also think its reputation of being too restricting isn't entirely deserved.
As but one example: I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others.
So here' to hoping for another 6 good releases at least!
It's also interesting how people have gone backwards in terms of convention. As far I know, there's no standard convention for JavaScript server layouts (maybe server.js, but I've seen stuff in index.js or main.js). Likewise there's no standard way to plug in servers like Rack. Or a standard ORM in the JS world. I figured conventions would come with maturity but the JS world is getting mature and yet there's not many conventions
I found this to be true when building a SPA. On rails I am already told the best place to put things but on the JS side its just "do whatever you want" so I try something and find out later that it wasn't a great way to do things so I am just wasting my time working out the best way to organize a project. I also have to deal with index files that just import every single component for the frontend when on rails this kind of stuff is auto generated.
Rack is cool, but the modern approach seems to be more decoupled web servers. You rarely see multiple business-logic Rack servers in a single process anyway though; Rack servers outside your primary business logic tend to be used more like Express middlewares in Node (which are very conventional at this point).
And the standard entry point for a NodeJS package is "whatever is defined as the main property in your package.json." Do otherwise at your peril.
I often opt to use SQL instead of the canonical query builder, especially for queries that do not return individual models but aggregate values or the like. You can even mix-and-match to your liking, i. e. writing individual clauses of the query (select/where/join/having/count) in SQL and using the ORM for the others.
That's actually good to know (or perhaps be reassured on). While key-value stores have their place, I've wondered if the rise of NoSQL in web dev was triggered in part by the widespread move a few years beforehand to ORMs, which trained a generation of developers to look at databases through the lens of object relations rather than table relations. I'm (re-)learning Rails with the Pragmatic Studio's Rail 6 course currently, and reminded of why I liked it -- but in the last few years I've also come to renew my appreciation of pure SQL.
(I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.)
> I also suspect that the tradeoff of abstraction layers -- in exchange for having little to no database-specific functionality, we give up any and all specific to the database we're using -- may not be a good one, but that's a different argument.
Indeed. I'm currently in the process of porting my companies product from Firebase to Postgres. We're making full use of postgres-specific features where that makes sense. I can't see why we'd ever want to switch.
Yeah, that'd be my main argument here. In practice, I'm not sure switching database back ends happens that often once you're actually in production -- and when it does, it's usually moving between back ends that are so different you're going to be doing a lot of rewriting anyway.
I've seen programs switched out on top of databases more often than I've seen the reverse.
Most DBs are much, much better if you commit to them and actually use their features. I dislike the practice of treating them as interchangeable and think it's rarely a good idea.
> and it can only be coming from people who never got to experience the world that was web development before Rails
As someone with experience from many more backgrounds than "old php", my dislike of rails has nothing to do with what you're claiming. Plenty of frameworks have had convention and structure prior to Rails.
That said, I'll admit it does have some good things going for it, even if it wouldn't be my first choice in most cases.
Mind you, most of my experience is from the rails 3 days plus some legacy application support.
My biggest gripe is the autoloader; it makes finding where something comes from extremely confusing when ramping up new developers on large, mature projects.
The enforced, common convention is a boon and a curse- consistency across projects is an obvious benefit, though I prefer a different structure myself.
Beyond that my gripes are more related to ruby and the tooling rather than strictly with rails itself. Of course you can tweak and configure rails to behave any number of ways, but the more you do that the more you lose out on the primary benefit, which is the community one-true-way mindset.
I wish they would be so keen on migrating to MySQL 8.0 as well :-)
Their (amazing) tool Gh-ost is broken on MySQL 8.0, which suggests that they're still based on 5.7.
It's a big issue for my company (and I guess for any mid-sized company), since at mid-sized companies the schema is likely big enough to have slow migrations, but not big enough to have fancy replication topologies. For such cases, there's nothing like Gh-ost :-)
So far I haven't seen many people switching to MySQL 8... almost every example and app I've seen in the wild is on 5.6 or 5.7, or switched to MariaDB (or more infrequently, Postgres).
Well, if we put it this way, the same could be said of Rails 6. I understand their plans of course, and that's why I expressed it as wish.
Regarding MariaDB or PostgreSQL, can you enumerate/detail the app you've seen switching? Is it the, say, 1/2% area of all the projects? 5%?
Probably, in the low one-digit percentage, there are switches toward anything. I'm somewhat skeptical any non-trivial projects undertaking this kind of change. GitLab (to mention a large one) didn't really switch, as they were supporting both.
When you install 'mysql'/'mysqld' in Debian or RHEL7+-based distros, you get MariaDB... So staying with MySQL and not "switching" to MariaDB is a lot more effort. (MariaDB is a fork of MySQL and the binaries and everything even have mysql in the name so everything just works. I'd assume there might be some divergence in newer features, but I haven't noticed anything in that regard.)
Running two production applications on 5.1.5. It works swimmingly and I rarely need to touch it except for some additional feature requests or tweaks.
Is it worth the headache of upgrading to 6.0? I'm looking at the change log and deprecations and nothing stands out as an issue but I think I still need to do 5.1.5 to 5.2 then to 6.0. Not to mention I'm not going to utilize any of the new upgrades.
I'd say it's worth doing, unless you intend to spin down the app entirely in a couple of years, just for the sake of security updates. You don't want to be in a situation where there's a vulnerability announced, and you can't pick up a fix without updating 6 versions, with all of the headaches that brings. It's worth devoting a few % of time here and there to bumping everything to the latest version and fixing any issues that come up, and maybe trying to move things that had been using external gems to any new internal processes that cover the same tasks.
Good point. It's an app that's got a life left to it. Not much in the way of changes but it's a pretty critical piece of software. Cloned a copy, moving it to 5.2 and 6.0. Had to update ruby to 2.5.1. Looks like postgresql (which I use heavily) is also making comments about migrating data. This is not seamless. Lots of issues not to mention `rails app:update` basically wipes out the files, you go back in replace with needed info via diff, more errors. I thought that was supposed to alleviate that.
If this works I'm hoping at least pushing to Heroku will handle that part. Heroku notes the gem file and makes the required updates.
Keeping your app up to date if you have any significant quantity of third party gems, is really nice. Meaning, if you need to upgrade, it's easier to stay on top of it than it is to pull an app from say, 4.2 to 6.0. This becomes particularly problematic a few years down the road, for security updates.
That's the other concern, right now all the gems play nice together without issue. It's possible that some of the older gems are supported under 5.x and haven't made the required changes for 6.0.
I would say the answer to that for _any_ software that isn't under active development (you hardly ever touch it, you aren't adding new features) and _nearly_ any dependency upgrade is -- no, of course it's not worth it.
EXCEPT that by not upgrading you are building technical debt, because eventually your dependencies will be unsupported, and have a severe security vulnerability, and nobody will be providing a patch. And they'll be hard to get running on modern OS's, etc. Or some _other_ dependency will have a severe security vulnerability, and will release a fix ... in a version that only works in Rails 6.0+.
In fact, Rails 5.1 is _already_ out of support in the Rails maintenance policy, they do not commit to even releasing patches for severe security vulnerabilities in Rails 5.1. (They forgot to update the exact versions given as examples in the Maintenance Policy Guide, so you won't see it in the "released" Guide for Rails 6.0, but you can see it in the "edge" guide https://edgeguides.rubyonrails.org/maintenance_policy.html. And next time there's a Rails release, it'll be updated on guides.rubyonrails.org.)
But will it make your software faster or more reliable to upgrade to Rails 6.0? Probably not. But this is how software works now, you build up technical debt just by standing still.
Also, the 5.1 series will not receive any future security fixes now that 6.0 is out.
So you could consider upgrading to 5.2 instead of 6.0. This is just one minor version step so should be less daunting. And 5.2 will receive security updates for a while yet.
Always. At the very least simply because the headaches that accompany those upgrade paths will be significantly bigger once you skip a version or two and finally want to jump to 7.0 or 8.0. Instead upgrade while it's relatively painless.
A front page Rails-related post that doesn’t have a single comment about rails scaling issues, 8 entire hours after submission?! It’s a good time to be alive!!
This is very interesting. In my bubble I thought the trend was going away from full fledged batteries included frameworks and more towards “hand pick your few specific libraries” with Go, Java and what not.
Looking into the comments here, I guess I as wrong.
It’s refreshing to see a big company writing about Rails
I've actually been having some trouble upgrading from 5.2 to 6.0. I initially tried upgrading to 6.rc1 but hit a few road blocks, then tried 6.rc2 and just had too many odd errors and I eventually put that on the back burner. Maybe I'll go back and revisit, but I had tests failing that I wouldn't initially expect to fail, such as random unicode errors, broken mailers, and some odd 404s. I may try to upgrade to 6.0, but also kind of feel like waiting until 6.1 is out may be a better option.
(I don't think GitHub talking about their 'smooth update' is fair, given they've essentially been upgrading to 6.0 since 5.2 released.)
Wow, didn't know a company this recognizable was still using (and embracing!) Rails. Pretty cool. Also helps explain the fact that they've stuck with a mostly server-side-rendered app, despite it being a fairly complex tool.
The perceived performance of Github as I use it as good as any site I use and better than most, so to the extent that's a consideration in client vs server rendered (and it probably should be a big one), it seems to be working.
The new sites with their own implemented loading bars are just super annoying to use. Sometimes they just stall and look stupid. State is bad! Stateless page loads work! Dont use SPAs unless you do something that looks like a desktop app! Please!
They should sponsor also the proper JIT in Ruby, will improve the speed drastically. Not the current generation of C code then compiling it with GCC, this is a joke.
How I dream of more serious sponsorship in the ruby community.
I think people underestimate how much python shops are suffering right now over the V2 to V3 transition. I recently turned down a gig that was basically just going to be upgrading python services for the next several months.
I've personally preferred much of ruby's tooling and package management to Python's, and I've always hoped that bigger money would come into the community. That said, Ruby has done incredible, not knocking the accomplishments of the community in any way.
No idea, but nothing really planned out as far as I’m aware.
It’s great to see companies like Github, Stripe and Shopify make major contributions to the community, but having a relationship like Google and Guido have would’ve elevated the community to another level.
It's very easy to criticize and very hard to do better within the same constraints. Vladimir Makarov from the GCC team built the prototype. This was not the result of inexperience but a pragmatic choice.
As a side note, JRuby has had a production ready JIT since 2015.
I find Rails projects often grow larger than the formalisms available in Ruby provide for, and I tend to find myself missing types even in fairly tiny projects.
I look forward to Ruby 3 type annotations, and to the continuation of a long history of Rails setting the developer-experience standard for projects in other ecosystems.
I haven't gotten a chance yet, no. My recent projects have been tiny things in PHP, or large ancient things in Java. Looking forward to an opportunity to try it out, though.
I have some: memory usage, CPU usage, raw performance, language safety, transparency. I think in the era of Elixir/Phoenix, Rust/Actix, Clojure/Luminus it is really hard to argue for Rails. Don't get me wrong, I have spent many years on it, but simply there are better alternatives, based what sort of requirements you got.
The main issue I see with these frameworks is that they cannot match Rails' support ecosystem. The framework has around for a really long while and rails developers have made - and documented - every error, kink and detour it is possible to make when writing code. I have often been pleasantly surprised to google an esoteric problem I imagined could only arise from my own unique brand of kludginess, and find that the community had encountered and solved same in the past.
This is of massive value especially to new developers.
I am pretty sure. If you developing the next Basecamp these are essential. However, I rarely see Rails succeeding in other aspects of web development. I spent some time on trying to make Rails work for use cases that are not the perfect match for this ecosystem and failed. Yet, it is quite possible that there are millions on web applications out there, running on Rails happily. It is just not a great fit for things I do.
Basecamp's problems seem particularly well suited to a batteries included CRUD framework. There are plenty of problems out there that aren't CRUD-centric
- providing API for warehouse fulfilment for online retailers (peak load is 100x of base load, latency goes out of the roof before Rails just crashes with OOM)
- real estate indexing with huge amount of data (we could not make the full text search work reliably with Rails)
These were pre 6.0 and I am pretty sure many things changed since, I am just saying it is easy to run into these situations. The bigger your framework the more assumptions are built in that are hard to come by. It is good for Basecamp startups not good for non-Basecamp startups.
Image processing:
Spin up sidekiq workers and do your image processing in parallel in background processes.
Providing API for warehouse fulfilment with peak load 100x greater than base:
Run your Rails APP in any number of possible auto-scaling configurations.
Real Estate Full Text Indexing:
Use ElasticSearch alongside Rails to provide highly performant full text indexing/searching
I might be wrong but aren't real-time areas like WebSockets not really strong points in Rails? I do see that Action Cable appears to have improved, and I don't know at what point performance issues would get in the way, and I also probably don't know about some potential solutions. Should one choose Rails for an application with significant real-time / reactive functionality?
It depends on what you need. If you're building chat and want presence features so you can see who's online (and with how many and what type of devices), Elixir + Phoenix gives it to you out of the box.
I agree with your point about a sparser number of libraries, and sometimes that slows me down. That said, Elixir's ergonomics and documentation is fantastic.
There’s kind of a middle ground where Rails is widely-used enough that it has this advantage over stuff like Elixir, but by the same token the Python, Java, and probably .Net ecosystems have the same advantage over Rails.
The place where Ruby really wins is speed of development. Despite massive ecosystems and many libraries, Python, .Net and especially Java all lag Ruby in terms of how long it takes to build a web app.
I'd say part of the reason is expressiveness of the language (since it's very easy to make DSLs with Ruby and Rails benefits greatly from them), but another part is cultural. Python, .Net and especially Java communities tend to suffer (and benefit!) from a strong emphasis on correctness and purity over speed and developer experience.
Having a cute API and leaving the parentheses out of your function calls isn't a DSL, it's just a cute API where you leave the parentheses off. I know Ruby people call them "DSLs" all the time, but they aren't.
Python doesn't have an idiomatic equivalent to block arguments, but you could probably write an equally usable routing API. It just wouldn't look as cute because there would still be parentheses.
What you end up doing in e.g. Flask is decorating your controlle method with the path that routes to it. Turbogears controllers serve routes based on class and method names without the extra wiring that Rails has. Django has a Rails-style "URLconf" (https://docs.djangoproject.com/en/2.2/topics/http/urls/) that actually seems a lot more intuitive and explicit to me.
Not a Rails dev myself, but curious: let's say Rails gives you 80-90% of the simple CRUD screens you might need for a project with minimum effort, but you need a couple of high performance services for, say processing images or accessing a data warehouse. Would it be possible to just write these services using e.g. Go or Elixir, and access these APIs through your Rails app?
The real question is: if you already writing the services in Go or Elixir why would you want a Rails app on the top? You could very well implement it in Go or Elixir. Theoretically it is possible though.
I think the point here is that Rails is a very productive platform for building CRUD workflows - much more so than, for example, Go (perhaps less so for Phoenix/Elixir). So you can build the vanilla CRUD screens in Rails in minimum time (and therefore minimum cost), where performance is not going to make much of a difference either way, then use Go microservices for those parts of your platform where performance is essential. So use each tool where it is best suited for the job - Rails for productivity and Go for performance.
As somebody pointed out there are millions of applications that can use Rails because scale is not a problem for them. If all those millions of applications do 1 req/s then you have 1M req/s served with Rails instead of something that is more reasonable. The CO2 production of these low scale Rails web app quickly add up.
I use .net core by day and rails by night (side business) and I can honestly say .net core MVC is kind of influenced by rails (not a lot but like 30%). After more than a year using both I found more joy with rails.
I find Rails gems and ecosystem to be more mature also ORM is friendlier since I felt more comfortable using active model than EF
All of the above could be a personal preference since I worked on rails for a longer time. At the end of the day I got to an end product with both
However I use .net core with MSSQL and on a Windows machine.
I've used rails back in the 3.2 days and after 7-8 years I still can't find the simplicity of rails in .net core and I really wish it was the case. I'll bet getting a rails 6.0 project from first scaffold to fully working site with admin interface and login system would take just one night of work without really remembering anything. With .net core, no idea how long. I saw some code generation commands for the most recent versions, so maybe there is some hope for .net core.
.net core works fine with postgres. Though I tend to use Dapper rather than Entity framework. I just use .net core as a REST backend / host for a vue front end.
There's always a bunch of pros and cons to comparing languages and frameworks, I'll just say neither are really going to hold you back from doing anything.
More similar than different in a lot of ways, but I suspect the differences come out of their background. Rails was originally developed by a consulting company for both client work and their own apps, so it really emphasizes rapid development -- it pushes convention over configuration very hard, had database migrations from its first version (Django didn't get those for years, etc.). Django came out of a newspaper (the Lawrence-World Journal), and seems really optimized for building custom CMSes -- there's nothing I've found in any other system that's truly like Django's admin console, for instance. (Another sign of its newspaper heritage: it's the only template language I've ever seen whose date filter has extensions to match Associated Press style!)
I used Rails for 4 years, then Django for 2 years, then back to Rails (now for another year).
Programming with Ruby and Rails is like a breath of fresh air compared to Django. Working with Django was just so painful and awkward (especially if you are trying to write tests for things). I used to have a laundry list of a couple of pages worth of things that I hated about Python and Django when compared to Ruby and Rails, but I can't seem to find it right now.
Ruby has unconstrained lambdas for a start and a much more composable, expressive syntax facilitating the creation of elegant DSLs. Rails, Chef and other Ruby projects lean on this feature. The goals of Ruby's creator, Matz, were more idealistic and artistic than those of Python's creator, Guido, whose values are more pragmatic and math-focused. Matz took inspiration from Perl, Smalltalk and Lisp whereas Guido set out to solve a much more local, project-based problem when he created Python.
Different philosophies. I think the biggest difference is that Rails has a much bigger ecosystem and more developers than Django does. There are gem's out there that support almost everything you want to do and if there's not there are resources from people who have had to solve similar problems.
And by the same token, outside the context of "web stuff," Python generally has wider set of domain-specific packages (e.g. ML) you can easily incorporate into your web app.
As suggested, encapsulate your prediction model in a web service, then calling it from Rails would be a good way to go.
An other way is to use something like Faktory (https://contribsys.com/faktory/) on top of Redis. You push jobs from Rails and then you pull them from Python to execute. Then Python can enqueue another job with the result which gets consumed by Rails (async callback).
Using a client to connect to a prediction HTTP service would be my choice (Flask app?). Otherwise if you want to you can do something with the backticks, which will run a shell process from Ruby and get the return value:
`python3 predict.py <input>`
You deploy the Python model to a backend service and expose a simple HTTP-based API, maybe using Flask? You should preferably keep the web part and heavy lifting separate.
Like you connect anything to anything else. You use a myriad of Inter-process communication techniques from memory maps to named pipes to socket protocols to databases.
unpopular opinion, but the reason people chose node.js is because for some dense folks like me it's easier to reason about and understand how everything works. the tooling is abysmal compared to rails, django & laravel. but at least I know how my app works from top to bottom. you take a productivity hit in your first node.js project but after that you would've collected / curated your own personal tools/libraries. and hell yeah spinning an api that does whatever you want is easy as hell. much respect to dhh though
I’m not sure your opinion is unpopular, but I have a hard time following your logic. Isn’t part of why a solid and curated framework makes perfect sense (and make you more productive) exactly that you don’t have to understand everything that’s going on?
I have a decent understanding of what lies beneath linq in C# for instance, but that’s because I’m curious by nature and not because I had to know it to utilise it. I mean, I guess you could argue that people should know what’s going on, but the truth is that 90% of software development doesn’t require you to, if you pick the right tools.
I think this is a primary reason node.js never really picked up. No one wants to spend time building and maintain the wheel when you can get a trusted entity to do it for you. You may find the part about node not picking up odd, but if I look at job-listings for my entire country there is almost zero postings for a node backend.
If that's your concern, you can learn how the internals of rails (or django) work. Not being forced to do that doesn't mean you can't do it regardless :)
Sounds like they upgraded directly from a custom fork of 3.2 to 6.0, but if you read the article, they upgraded from 5.2 to 6.0. Not as insane as 3->6, but 3->5 is still pretty insane.
I've never tracking upstream releases of core dependencies so closely. How does it compare in terms of cost versus doing a big bang upgrade every once in a while?
I have had to take over multiple projects that were years out of date on multiple platforms/os/languages. It's a nightmare that one does not wish on anybody, it's possible but as the other poster notes, one has to have extensive testing suite to verify functionality before and after - or one has to make one to have any hope of succeeding (making a final product up to date and functioning correctly unless one just wants to make something just run.) It's never as easy as just changing the lib/imports since active languages/libraries are living things, to say nothing of dead libraries that one has to update or replace.
I agree 100% with this. I once had a project that was versions behind the current platform. I couldn't upgrade because the tools to upgrade were gone and I was constantly having to fire off questions to the lead contributor who was around for that version in order to get stuff done.
Upgrade as soon as a stable build of the major version is released and pay the engineering costs or be left with something worse than legacy.
I also update the npm packages for a small website weekly. It's much easier fixing a few occasional breaking changes than waiting for a year and then having a massive headache since nothing will compile/work anymore.
Incremental updates may require more time to complete, as an API may be refactored multiple times over many versions. However, the confidence in moving incrementally is well worth it IMHO. If you don't have an extensive enough test suite or poor/missing QA process (or both!), doing a big bang upgrade is going to both be extremely painful and very error prone.
It's worthwhile to keep up to date. It's probably not worthwhile to upgrade ASAP after a release, but you don't want to wait too long.
I tell you what, say what you will about having plenty of warning, but right now I'm big-bang-ishly updating an app to 5.2 and I'm mired in quicksand due to the death of both bourbon/neat (removal of the most interesting functionality) and paperclip.
I agree that conflicts/integrations between dependencies tend to give more upgrade pain than conflicts with local code and a single dependency.
I think probably exactly how often to upgrade all your dependencies on what schedule... depends on the particular product and organization and resource-richness. What Github's did, upgrading Rails _daily_ to the latest non-release master... sounds really attractive if you can do it, but I suspect most people can't.
A step on the way would be just `bundle update`ing daily and making sure to keep up with always having that passing and deployed. (Although in Github's case I don't think the actually deployed with dependency on unrelased master).
I don't actually really even do that, def haven't automated it (although it occurs to me it would be simple to automate on travis or probably equivalent).
Considering MacOS share of developers is around ~30%, most developers can't cmd-click :) Seriously though, there's whole camps of developers who don't use an IDE. Some people are just more productive keeping a model in their head and relying on other tools (test, linters, repl experiments) to safeguard against their own misunderstandings.
Some IDEs like rubymine allow this. On vscode if I can't work out what a function does from the name I just do a full code search for 'def method_name` and it usually brings up the function I need.
> I just do a full code search for 'def method_name` and it usually brings up the function I need.
Not in Rails. Too much metaprogramming-generated never-defined stuff going on. Often makes diving into inherited Rails codebases pretty unpleasant. Especially if they don't have a solid test suite, which IME most in the wild do not (not Rails' fault, that's true of most code ecosystems).
Definitely not sure why this is being downvoted — full text search failing to find anything about the definition of a symbol in rails codebase is super super common ... rails obsession with lack of explicit includes is the stupidest thing I’ve ever encountered in a dynamic programming system ...
Maybe you can get away with a module system that works that way in something like ocaml where it’s always possible to tell what is being referred to statically — but in a dynamic language - the level of obfuscation this induces is absolutely nuts
Because (good) ruby is elegant enough to be self-documenting and informative on its own without needing go look somewhere else to figure out what it does.
I think you get those command-click references via static analysis for ruby in, uh, RubyMine?
Some people swear by it. For just that reason.
I have never used it. I am willing to consider that maybe if I did, I'd come to like it so much I'd never want to do without it. (There was a point I didn't think I needed syntax highlighting, now I know I read/understand code so much quicker with it, at least in ruby).
Does VB Studio maybe give you it for free too? Not sure. Not sure how good these features are. Can't say why I and I think the majority of ruby devs don't try em.
As people mentioned here Rubymine closed the gap, autocomplete works as well as a java ide 95% of the time it's almost a non issue.
Yes for meta programming it won't work as well but A) it's rare B) Rubymine might solve that as well at some point (for example clicking on a meta programmed method will lead you to the method that created the method, with good enough documentation it's all you need).
No idea why you’re being downvoted grey on a legit question. I’ve seen at least one project where it’s unreasonably hard to introspect rails code even using IDE tooling.
I'm going to stick my neck out as someone who has refused to even consider Rails over a span of many years, for one simple reason: it permits session fixation. If a client's cookie says "I am session token 'abc123'", it will create that session id out of thin air. As in, it will create that session id without it having had to be generated previously. Your memcached/redis does not have an entry for session 'abc123', but Rails will happily create it.
The developers who allowed this situation to occur should not be permitted to be employed in our industry. Yes, it's that bad and I am that serious. You can, not kidding, set your cookie's value to ANY VALUE YOU WANT, and the codebase is entirely willing to unconditionally create that session with whatever value the attacker chooses.
Hint: if a client sends session id "abc123", then you should check for the existence of that session id. If the key is not set, you either a) show an error page, or b) create a completely new session id, ignoring the client's requested session id. It is NEVER, EVER, EVER... I am saying __NEVER__, __EVER__ acceptable to create a session id based on client-provided data. And yet, this is what Rails does out of the box.
Edit: Downvote me more, I don't care. The fact is that Rails' developers are amateurs. Rails is insecure out of the box. That is a fact.
Cookies in Rails are encrypted and signed, and as far as I am aware, simply setting your session hash cookie to a bunch of random gibberish is not, in fact, going to just create a new session. (Also, "creating a new random session" is not what a session fixation attack is, but let's leave that aside for now.) Given this encryption, how do you propose to execute this attack? I don't usually like to be the "[citation needed]" guy, but: citation needed.
Why is that an opt-in option? No codebase should ever be willing to create a session id (any db/cache id/key) based on request details. The fact you have to opt in to a very basic security measure is, once again, a joke. Let's be clear: by default, Rails is willing to assign a client any session id based on its own request?!?!
Based on the other reply to my comment... no I'm not OK. I am not OK with Rails' pathetic attempts at the most basic level of security. Rails' developers are fucking amateurs. I'm sorry, but that's pure fact. Rails' developers don't know the first thing about the HTTP protocol.
NOBODY EVER CREATES A DB/CACHE KEY BASED ON THE VALUE OF A CLIENT-PROVIDED COOKIE (or unvalidated GET/POST). Anyone who argues against this should be permanently banned from IT/Technology. Just... fuck off... you have no clue.
It's good for defense in depth, but you have to pwned the user in another way to set the cookie in the first place right? If you're using httpOnly cookies you should be fine?
I've recently built a web app with Node and the time we spent solving problems which have already been solved a thousand times is astonishing. Things like picking an ORM, having a proper database migration system, running a test suite. It's actually quite depressing when you come from Rails where everything is working coherently out of the box.
The fact that there is no standards in the Node ecosystem make it a bit more painful. You have to carefully choose between many different libraries to solve your problem. Some of them are in TypeScript, other still use callbacks, etc. We basically had to glue together many libraries to get something working. All those hours could have been spent building the actual product and delivering value to our customers.
Hope they will ship many more releases!