I'm in the process of transferring from being the CTO of one company to CTO in another one and I'm wondering if I should just start with Rails this time. I get a little uneasy given the popularity of the JavaScript ecosystem, and Rails seems a little harder to share code between the web app and mobile apps, but I don't know... It feels extremely productive to work on Rails.
It is. Nothing comes close. It's a shame there's such a stigma around it otherwise.
I do think that we're seeing the pendulum start to swing from microservices/cloud/PaaS everything back towards simple architectures and simple deployments and I'm hoping Rails sees a bit of a renaissance with that.
> Rails seems a little harder to share code between the web app and mobile apps
I've personally never seen this done well, ever. At least not in a way that the amount of code that can actually be usefully shared is worth the effort.
Mostly work with Django but have some expire with Rails: the speed you have with rails is insane compared with JS. Authentification, Routing, management of state, SSR. It's all done for you.
Mobile App. Start with Service Workers and PWA and decide then if you need an app.
I'm mainly a Django dev, and I'm curious how the productivity of Rails compares to Django. Do you have anything conclusions about their relative productivity, given a reasonable competency in both frameworks?
I've worked with both extensively, though my experience with Django is mostly with very old versions. In my opinion Rails is definitively "higher velocity" than Django (recent versions of Rails have an answer to nearly everything you would need for a modern midsize web app), but I admired how simple Django was architecturally. Stack traces in Django were, at least then, easy to digest and you could comprehend most of the routing system by reading a few files, for example.
Whereas with Rails your stack traces are much longer and there's a lot more machinery each request has to go through. Rails has a lot more abstraction in general (you can blame Ruby's powerful reflection capabilities on that), but I found that I have to go delving into Rails' internals very little.
Hey there! I've done a lot more Django than I've done rails, but have had both in my job title at different points in my career. My favorite language is python but my favorite development platform is Rails. They're mostly comparable but Rails wins for me. Rather than type it all out in prose I'll just give a short little blurb about what you get and don't get with one and leave the rest as an exercise to the reader:
What you get with Django but not with Rails:
- An admin panel out of the box
- Python (which is a big win for me personally)
- Authentication out of the box, but still fairly basic
- A robust library of third party packages that benefits from python being used much broader than the web space.
- Class based views (this is the biggest thing I miss, by _far_)
- Better LSP support
- Django REST framework (rails isn't _quite_ as good but you can get kinda close by leveraging resourceful routing and the serializers that ship with rails)
What you get with Rails but not with Django:
- Websocket support out of the box (but not the greatest performance. A third party drop in replacement [Anycable] makes it much better)
- First party API for background jobs (but it requires a third party background job system to wrap, like sidekiq)
- First party integration of a JS solution (import maps)
- Second party integration of a JS bundler (js-bundling, written by rails authors but not included by default)
- Hotwire (although Django trivially integrates w/ a comparable technology, htmx, Hotwire is still pretty dope)
- Rspec and the rest of the Rails testing ecosystem (guard, VCR, factory_bot, capybara). Python has ports of some but not all.
In my mind, Django adopted just two things, I'd be very happy. I'd love to see a better async story in Django that would enable web sockets and stuff. And the second thing I'd love to see is a better story out of the box for playing nice with frontend build chains. And, as a distant third, I'd like to see an html-over-the-wire technology like HTMX favored and some light integration in Django to recognize some headers so it can switch between sending just template segments or if it should send one w/ the layout included. The testing ecosystem I don't think is possible for Django to lift on it's own and I'm prepared to miss it while I'm away. That other stuff, though, is unfairly aging Django imo.
It's a new company, the system is still small and they just lost 80% of their engineering talent. I think what's left of the system doesn't matter that much (but I'll have to check, of course). They are currently on C# + Angular.
Rails isn't any more productive than any other languages. Unless you are talking about dead programming languages in comparison.
What you need to do is figure out what the application is doing. Identify what the best language is for that task and just micro service it.
Move complicated tasks into smaller services. Don't compound the complexity into a monolith whatever you do!
You can get best resource utilization by containerizing an application. Most people say just multithread it Puma ruby whateves... you will go into coherency hell if your app is not designed inherentlt around the idea of puma. Just use unicorn and run it as a container. Right size it for that scale out accordingly.
My admittedly biased view from the other side of the fence is that it may be a lot (little) quicker initially but you run up against code quality/maintainability and performance struggles far sooner.
Granted in a startup worrying about next week is wasted cycles but I don't think rails is so much more productive as to justify switching away from an existing stack (whether Laravel, Django, .NET or whatever. While Rails was a paradigm shift when it was new most all other languages and frameworks have adopted large amounts of the lessons from Rails). I'd urge you to give C# a second chance
I think Angular has a pit of failure for performance problems. It's use of RxJS is highly compromised (Angular "best practices" are often RxJS worst practices) and that infects all of Angular development and fills the entire ecosystem with memory leaks and other performance problems. (I've blogged about some specifics before and I've built/published an open source library to try to compensate as best I can as I currently work in codebases now sunk cost fallacy stuck to Angular.)
I don't think any of React/Vue/Svelte are nearly as compromised and have nearly as big of a pit of failure. I find React a good option with an active ecosystem. React especially isn't ashamed of and doesn't hide its learning curve like Angular tries to, and that learning curve is especially designed to more often than not lead towards pits of success.
can you link that blog post? sounds super interesting! thanks!
so maybe I'm just lazy but even though I've tried to jump on the whole FRP train (back when it was blowing up around ~2012-2013 .. there was a great tutorial about it and I caaaaan't fiiiiiiind it now but I spent hours going down memory lane thanks to HN's upvote history :D), but I don't really use it or feel the need for it. TS and a nice Result type (a la Rust), the standard Angular Input/Output bindings, dependency injection, a nice template language, and ... things are smooth and easy.
Most of the complexity is fiddling with business requirements, validation (the usual mapping backend data to frontend data), somehow performance was never a problem.
And compared to Angular I spent tooo much time fiddling with props in React, fighting with people and their half assed components, their ignorance of TS, and so on :)
Dependency Injection is its own form of "too much time fiddling with props". It's just implicitly handled "magic" and you don't appreciate the time you spend fiddling with it because it seems "automatic" up until that point you need to spend an entire week unmangling a set of NgModules to fix a code-splitting problem. (Or you don't and watch your bundle sizes increase exponentially and assume "that's just the Angular way: huge bundles".) Which is its own performance management headache.
I do wish that there was a larger culture of TS usage in the larger React ecosystem. But also I'm still comfortable writing my @types/ modules in DefinitelyTyped if I absolutely need to and want to contribute that work to others. That's generally a good recommendation, if you find an untyped React component check the DT issue tracker for it and post a request if there's isn't already an open one. A couple of "Hacktoberfests" I've contributed @types for requests on there, and I know there are others that are watching it more than just once every October or so.
Standard Angular Input/Output bindings are some of my problems with Angular. It's a worst of both worlds situation where some things use RxJS and other things use imperative proxies and the performance weirdness of Zone.js and the weird things it does to Promises and RxJS.
I also personally don't like the template language. I think it was a terrible mistake that the template language uses .HTML file extensions. I think that sends too many designers a false sense of security with the template language and I've had to correct so many things.
> somehow performance was never a problem
Everyone has different performance considerations. I still have a tree-shake and keep bundles as small as possible mindset. I also developed a lot of skills doing performance work in RxJS on Cycle.js projects and redux-observable "sagas" on the React side (and RX backends in C#/.NET). So I notice a lot more things to nitpick than the average casual RxJS user. That's a big reason I keep referring to how Angular uses it as a "pit of failure": it sets up casual RxJS users and junior developers to have a bad performance time, and in some cases not realize that they have bad performance. The biggest for instance are very slow memory leaks that will never impact a developer in the middle of an edit/compile/debug cycle because the app never runs for long enough at a time in that cycle (and the developer often has plenty of RAM anyway compared to the average user), but absolutely will drive end users crazy when they have to hard refresh the tab every few hours/minutes and neither the user or the developer will understand why that performance problem exists.
This is my open source library attempting to wrangle some RxJS best practices out of Angular component design and its standard Inputs/Outputs/Template Bindings: https://worldmaker.net/angular-pharkas/
Never had a problem with Angular DI. (Had lots of problems with DI in JVM land - with Scala, had endless problems with module loading in python, and so on.)
For sure, I won't clap for how great modern JS bundle sizes are, but I found that most of the time what dependency we use matters a lot more for bundle size than how I load and what and where.
> I still have a tree-shake and keep bundles as small as possible mindset.
I also aim for this. Though just recently on the current project we're working on reducing downloaded content size happened when I finally went ahead and compressed the unnecessarily large background images, fonts. (Plus edited the CSS to prefer the smaller font file.)
So all in all, I think over the years I positioned myself to work on smaller projects where all the biggest concerns were completely outside the frontend library, and I wanted something with built-in TS, and so Angular became the trusted choice :)
Thanks for the link! (haven't got time to read it yet :D)
Rails + angular works well, might be a compromise for you. You could replace the backend endpoint by endpoint... e.g. (or similar to incrementalize it). I mean -- assuming the C# is not something you want to carry forward.
Isn’t strada a running app? And also the name of Google’s gaming streaming service? And probably 5 other things that have higher search priority on PageRank?
> Strada standardizes the way that web and native parts of a mobile hybrid application talk to each other via HTML bridge attributes. This makes it easy to progressively level-up web interactions with native replacements.
Strada will premiere in 2022
Hotwire is an alternative approach to building modern web applications without using much JavaScript by sending HTML instead of JSON over the wire. This makes for fast first-load pages, keeps template rendering on the server, and allows for a simpler, more productive development experience in any programming language, without sacrificing any of the speed or responsiveness associated with a traditional single-page application.
If you need mobile, consider a Rails backend and React Native/Expo front-end. This is a dream combination for my project which is mobile app first and web site second. I miss some of the rails view magic, but instead we get a single front-end that runs natively on mobile (iOS & Android) and it also runs on web. (It’s not common knowledge that React Native is for web too, it’s just an abstraction on the HTML elements: e.g. View instead of Div).
Yeah, I wanted to try it as well, but I don't think the team can handle such a drastic change right now (from OOP to Functional). But it looks like an awesome platform.
rails is awesome, and with hotwire we can reuse slices of the application and cut down required dev time. It's certainly optimized for developer productivity and happiness! been doing it for 13 years and still love it.
