Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to accomplish the same objective with less googling.
I used to write Rails professionally for many years
This comparison isn't a good one. Rails is an all-encompasing framework.
If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have.
---
EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node:
Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead.
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
What I've gathered, over the years, is that the people who dislike Rails because it makes a lot of decisions for them think they're just too cool for that. It insults their programming ability. OK, I can see that. So, go ahead; have it your way. But while you're still writing thousands of lines of boilerplate in both the front and back ends, and getting your types sorted out, I'm done with my app, and moving on to the next one.
I think the author is trying to compare what it takes to create an MVP web-app with all modern features versus creating it in the JS ecosystem.
Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that easily.
I think Rails lost popularity when the front-end JS framework movement started. Rails didn't have a response to that; people had to create the Rails app, remove the Views and use a JS framework to create the one-page app experience.
Now, if you are already spending that much time using JS for the front-end, why not use JS for the backend? But then things got too complex in the JS due to the lack of conventions.
This article really resonates with me but not because I've been down the same path. Back in 2011 I learned Ruby as a hobby language and from the beginning I fell in love. Probably because of my OOP background as a programming hobbyist since the 80s. A few years later I did a career pivot away from Ux into programming and after a brief stint in Java, my research just naturally funneled me to the Javascript ecosystem and full-stack development. Thanks Ryan Dahl!
But I wasn't happy in Javascript. It wasn't because I was stuck in my OOP brain. I didn't fight it. It just took a long time to embrace declarative programming. In 2018 I attended a bootcamp (Dev Mountain) and learned a single stack that, while opinionated, didn't bring me any fulfillment as a programmer. Mainly for the reasons you described. Too many choices. Not enough opinion. Too much flavor (fatigue) of the month. But mainly, I don't have a lot of joy like I felt when I was doing Ruby.
Fast forward to 2022. My company (a small 3 man development team) has been working on a greenfield project for three years. A massively complex project for such a small team, but finally we are done. Yay. But boy has the journey been wild in terms of our stack evolution. The thought of building a side project in the JS stack I am comfortable with just doesn't sound fun. I long for the warm fuzzies of Ruby. This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you.
For anyone that is interested, my current stack is React (Tailwind CSS)/GraphQL (Apollo and Postgraphile)/Express/PostgreSQL with docker CI/CD and AWS lambdas.
Working in a Rails based startup that took the same approach as OP, then at one point understood that we need React in the frontend, and a few years later the development process is a pain:
* Weird pockets of react everywhere (data-something-something) with tons of JSON just being interpolated into attributes.
* Webpacker and other rails magic is required for building the frontend
* Frontend and backend are tightly coupled. Default error handling is the Rails error view which certainly isn't user friendly.
* snake_case_for_data_from_ruby in frontend code
* The app feels more sluggish than if it were a SPA.
What I've learned from all this is that sometimes it's better to take the less opinionated road (SPA in this case), so you can be more specific later.
If you can easily switch to a framework like Rails from a SPA, it's probably a sign your app shouldn't have been a SPA. There's too much "defaultism" in our industry.
I've settled with Svelte (SvelteKit and Sapper), after having spent lots of time with React and Vue.
Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes.
I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails or raw HTML!
For handling data, it's either Supabase or Airtable's API, hands down. Tailwind for design system.
I've tried Rails before, but as a newbie to Ruby, I couldn't even figure out how to write for loops. To me, that was too foreign, and too much thinking involved. And with Rails, you need to run a server too right? That's even more not-mentioned work.
I enjoy building SPAs, but I often wonder if my joy comes from having built something, or is it just seeing the little virtual ball make it's way to the end of the overly-complex Rube Goldberg-like contraption of cloud services, NPM packages, bundlers and frameworks my product is built upon.
I don't understand the comparisons presented in the article. Comparing a full stack MVC framework to a front end library is as apples to oranges as it gets. IMHO frameworks such as NestJS and Adonis are more comparable to Ruby on Rails.
Rails and Ruby bake in a lot of really nice, ergonomic features for every day programming, not just larger architectural decisions. For instance I am working on a React Native app in my spare time and so much of Javascript seems tedious. Example is dealing with date ranges.
Contrived example:
import { isWithinInterval, subDays, addDays } from 'date-fns';
const today = new Date();
let range = {
start: subDays(today, 1),
end: addDays(today, 1)
}
isWithinInterval(today, range)
The functions for this kind of calculation has to be imported into any file I want to use them? There seems like a lot of copy pasting of this kind of stuff everywhere in a robust javascript app. I think it's reasonably easy to read and understand, so I don't fault that, it just seems tedious to use tons of libraries that you have to explicitly import everywhere to accomplish simple things. Feels like death by a thousand cuts.
Meanwhile in Ruby (with Rails) this is functionally equivalent and is usable everywhere in the code:
I started my career with Rails, then some frontend, and now work a full-time job in Node. Agree with most or all of these points - full-stack javascript is kind of a mess and hasn't really progressed despite individual tools having done so. I think https://sailsjs.com set out to solve a lot of these issues many years ago, by trying to be a JavaScript version of Rails. I'm not sure if they ever reached "feature-parity" though.
This resonates a lot! I've always considered myself a general software engineer (mostly doing algorithms and ML in uni), but then moved to industry and for every project needed to get into web. Over last 10 years I went through php, Java and Node on the backend and jquery/angular/react on the frontend. I understand and appreciate why and how these technologies developed, but it still felt I had to do a lot of re-learning to catch-up with the latest stack and build the similar thing all over again.
It is apples and oranges, but I think that's kind of the point.
Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
I built my last company with Go, Vue.js, gRPC, and Kubernetes. And, wow was it a slog. It was hard for new developers to jump in, we had separate engineers for frontend + backend, and there were things we never even touched - such as real-time/websockets or end-to-end testing.
I recently started a new project in the same stack [1], and partway through paused because it was taking so long to deliver customer value. I jumped back into Rails, inspired by their new Hotwired framework [2]. And, holy shit - the speed of development became insanely quick. Not only that, but I've been able to achieve a higher level of polish than I would have with a single-page JS app. Specifically - building in real-time updates only took a few lines of code. It was possible to achieve this level of polish with an SPA, but realistically it would have taken me so much time that I would have never prioritized it.
I hadn't touched Rails in over a decade. As a junior developer, I felt overwhelmed because Rails had solutions for so many problems I had not yet encountered. But, returning to Rails with some more experience - I appreciate its "omakase" [4] approach so much more. So many best practices are built in or easy-to-install. Queues, cron, async jobs, audit logs, email click tracking, end-to-end testing, real-time updates, caching, sessions, URL slug "friendly IDs", image resizing, rate limiting, admin interfaces, rich text fields, S3 integrations, sitemaps - they all just work!
With the new Version 7, Rails is truly a "One Person Framework" [5].
Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.
I think it all goes down to the explosion of popularity of javascript, it is a bunch of tools made by a relatively new to tech people, for relatively new to tech people, still trying to understand/learn how to do things properly , it is not an attack, it is just an opinion, many new technology at their dawn have had the same issue
I've been trying hard to make the migration from Django to Javascript for my dev work (95% of the time, I am building internal tools in a hurry) and it's been a major slog. I can write JS just fine, but spend all of my time trying to build a functional environment with the correct set of libraries and dependencies.
For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server.
Great post. This is one reason I love using Rails, the fact that it makes so many decisions for you—and with good defaults. Before Rails I had the exhausting experience of spending weeks making tech decisions just to start a project. (I’m also a huge JavaScript fan but for different reasons.)
Small nit about one point in the post:
> As far as I know, serverless platforms don't support WebSockets
I’ve spent the last couple weeks deep-diving on Cloudflare Workers. They have good support for WebSockets. And if you need your WebSocket to maintain state long-term, the server side can use a Durable Object.
We're launching our next startup in less than a month and were faced with the same decision.
Ultimately went with Rails. As said in the article: so, so much comes out of the box or from a very well maintained ecosystem.
Real-time dashboards (action cable), background jobs (active jobs, sidekiq), auth, tooling, etc. was each less than a day's work which allows us to launch so freaking fast.
Only real downside in my eyes is the hiring for our location (central Europe) and future UI complexity, where my solution will probably be to just drop in a Vue app where it makes sense.
I strongly prefer the explicit nature of JS programming, where you don't have to know a bunch of Rails-y magic to know where a certain symbol is coming from, it's just defined in the file you're working in (to pick one example). But I completely agree that the time from Start to CRUD in Rails is a killer app.
I keep kicking up new projects in my spare time, and for every one of them, I'd have to set up the application scaffolding, linting, set up a layout and basic design rules, figure out user management, and if I was getting serious, set up subscription management, team management, etc. Rather than rewrite it every time, I figured I could make an actual library out of it so I have a decent base to work from, and then turn it into a product, because I can't be the only one who has these similar issues.
Also, Nodewood isn't alone out there - there are all kinds of Rails-ey bootstraps or starter kits out there for all kinds of languages. Now, the fact that everyone thinks "Ruby" and immediately thinks "Rails", but they don't think "Node" and immediately think "and a starter kit" means Rails has performed some amazing marketing mojo, but that doesn't make it fair to compare JavaScript to Rails, the author should be comparing JavaScript to Ruby, or Rails to a Rails-ey bootstrap.
There must be an internet law whereby the moment you criticise something about JS there’ll be a reply saying “x does this” where x is something you’ve never heard of before
I think this is more a revolt against unnecessary complexity, which I think is a discussion to be had. I am not solving drastically more difficult problems than I did twenty years ago, yet the amount of complexity, maintenance, and overhead is staggering. Why? Oh, because "that's how they do it at the FAANG".
I agree with the author's core assertion that throwing too many decisions at a project right away makes it difficult to even get started. It increases the risk of hitting analysis paralysis right away. I've rarely worked with Rails, but when I did, I really enjoyed its approach to sensible defaults, easily overridden if needed. I hope that's still available, and I think other frameworks benefit from following that approach.
It has been >7 years since I used RoR for a complex web app. The problem is not configuration vs convention. The problem I had was when I needed dynamic front end functionality for the user (drag and drop, no-refresh edits, etc.) I ended up needing to use another framework/library on the front end too (at that time it was Backbone).
Has that been changed/improved? Or RoR is still primarily used to build server side rendering (SSR) web apps?
The lack of opinions in JavaScript frameworks (esp. React) is what keeps me away and using old boring things like Django. I am not a full-time web developer, and don't have time to follow the latest states of the galaxy of tools needed to build a web application. I am hoping that SvelteKit is the next boring tool that will offer an alternate way forward that is worth my time learning (once it stabilizes a bit).
It's true that there are many more choices to make for a JS SPA compared to RoR but isn't this just a fixed cost? Pick once and then stick to it. Use the same things for your next project. Done.
I'd venture to guess that for a RoR newbie, it takes just as much time to understand the 'glue' (I've heard people refer to it as 'magic') that makes it all work together behind the scenes.
Choosing something and making a decision is not as difficult as it seems. You don't have to when someone comes along and tells you "we should use pnpm because it's much faster". Before using any tool, you take a brief look at how it works and what it does, and decide accordingly. I don't understand why you see having more than one option as a problem.
We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end.
But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects.
This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that.
This article resonated with me, but the main reason I moved from RoR apps to JS/SPA was hosting costs and scalability. I can build a SPA and host the bulk of it on Amazon S3 and pay significantly less monthly costs AND have scalability built in. If you've figured out a way to do something remotely similar with Rails, I'd be back in a heartbeat.
I've been wondering about when to use something like a SPA and when to use something like Rails recently. My understanding is that the two are getting closer, with React getting stuff like Next with server-side rendering, backend functions and stuff like that, while Rails is getting Hotwire to make richer interfaces easier.
My question is, how do you know when to choose which one? For example, I'm looking to build something that's in the "unbundling Excel" vein. The application will have lots of input from the users, and lots of graphs. It's supposed to be pretty interactive (once again to mimick Excel). And I'd like to build a SaaS out of it. What would you pick, and why? From what I understand a SPA would be better at the "heavy user interactions" part, and a regular MVC framework would be better at everything else. Maybe a combination of the two? But with limited development times, it seems like it would be slower to do that.
For the past two weeks I've been evaluating Blazor. (C#) It's real nice. It comes in two flavors: Server-side that controls the browser via a websocket, or client-side that compiles C# into WASM. Server-side has the advantage that you don't have to wrap up all your APIs into contracts; client-side is a bit more "normal."
The Razor templating system is very nice. It's not like mustache where you have to learn a completely new syntax; it's very minor bits of C# and regular HTML.
I'm not sure I'd pick Blazor in a complete greenfield situation; but given that I'm working in a C# shop, it's a great way for C# developers to be full-stack while keeping the learning curve simple.
The title refers to SPAs, a frontend technology. But most of the identified pain points are not about SPAs at all. Well okay maybe the first two or three, but they’re very superficial.
Instead, this is more about serverless vs. “classic backend”.
This is exactly the problem I am facing now!
I thought picking up and building things with Vue should be a breeze but boy what a nightmare its turning out to be.
There is so much room for improvement in the JS ecosystem.
I think the author went too deep into details here, as this crowd is full of people who are going to be able to rip pieces of this article to shreds. But doing so both misses the larger point and in the process proves it - Rails gave them a set of answers that are good enough so they don't need to delve deeper and can just focus on their app.
Rails is not the only choice that does so. And people with broader skill sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs).
SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects and companies.
SPAs are not designed for developer productivity, they are designed by BigCo that can spend 0.01% of their revenue to hire multiple teams/ICs to squeeze out a +0.1% increase in revenue. It's comparable to doing microarchitecture-specific optimizations for your clientside website code. Totally irrelevant to your side project or startup.
Pick a productive stack/framework and build out your product with a solid foundation. You can always bolt on websocket-based features as required. Maybe rewrite your frontend in a SPA framework once you hit $100mm revenue.
Some comments were deferred for faster rendering.
MakerSam|4 years ago
[1] https://trends.google.com/trends/explore?cat=31&date=today%2...
gavinray|4 years ago
This comparison isn't a good one. Rails is an all-encompasing framework.
If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have.
---
EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node:
https://nestjs.com/
Not to be confused with Next.js, which is a framework for building SSR React apps.
tapvt|4 years ago
Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
TheRealDunkirk|4 years ago
designium|4 years ago
Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that easily.
I think Rails lost popularity when the front-end JS framework movement started. Rails didn't have a response to that; people had to create the Rails app, remove the Views and use a JS framework to create the one-page app experience.
Now, if you are already spending that much time using JS for the front-end, why not use JS for the backend? But then things got too complex in the JS due to the lack of conventions.
Unbeliever69|4 years ago
But I wasn't happy in Javascript. It wasn't because I was stuck in my OOP brain. I didn't fight it. It just took a long time to embrace declarative programming. In 2018 I attended a bootcamp (Dev Mountain) and learned a single stack that, while opinionated, didn't bring me any fulfillment as a programmer. Mainly for the reasons you described. Too many choices. Not enough opinion. Too much flavor (fatigue) of the month. But mainly, I don't have a lot of joy like I felt when I was doing Ruby.
Fast forward to 2022. My company (a small 3 man development team) has been working on a greenfield project for three years. A massively complex project for such a small team, but finally we are done. Yay. But boy has the journey been wild in terms of our stack evolution. The thought of building a side project in the JS stack I am comfortable with just doesn't sound fun. I long for the warm fuzzies of Ruby. This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you.
For anyone that is interested, my current stack is React (Tailwind CSS)/GraphQL (Apollo and Postgraphile)/Express/PostgreSQL with docker CI/CD and AWS lambdas.
3solarmasses|4 years ago
Along with our artist platform, Dot Press: https://www.level.press/ (same developer, me :)
snemvalts|4 years ago
* Weird pockets of react everywhere (data-something-something) with tons of JSON just being interpolated into attributes.
* Webpacker and other rails magic is required for building the frontend
* Frontend and backend are tightly coupled. Default error handling is the Rails error view which certainly isn't user friendly.
* snake_case_for_data_from_ruby in frontend code
* The app feels more sluggish than if it were a SPA.
What I've learned from all this is that sometimes it's better to take the less opinionated road (SPA in this case), so you can be more specific later.
bdcravens|4 years ago
yawnxyz|4 years ago
Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes.
I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails or raw HTML!
For handling data, it's either Supabase or Airtable's API, hands down. Tailwind for design system.
I've tried Rails before, but as a newbie to Ruby, I couldn't even figure out how to write for loops. To me, that was too foreign, and too much thinking involved. And with Rails, you need to run a server too right? That's even more not-mentioned work.
pupppet|4 years ago
lobstrosity420|4 years ago
prescriptivist|4 years ago
Contrived example:
The functions for this kind of calculation has to be imported into any file I want to use them? There seems like a lot of copy pasting of this kind of stuff everywhere in a robust javascript app. I think it's reasonably easy to read and understand, so I don't fault that, it just seems tedious to use tons of libraries that you have to explicitly import everywhere to accomplish simple things. Feels like death by a thousand cuts.Meanwhile in Ruby (with Rails) this is functionally equivalent and is usable everywhere in the code:
edit: fixed some bugs :)jzig|4 years ago
matijash|4 years ago
vehemenz|4 years ago
Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
adithyasrin|4 years ago
Also pretty useful when you start a new project and you know what's happening.
philip1209|4 years ago
I recently started a new project in the same stack [1], and partway through paused because it was taking so long to deliver customer value. I jumped back into Rails, inspired by their new Hotwired framework [2]. And, holy shit - the speed of development became insanely quick. Not only that, but I've been able to achieve a higher level of polish than I would have with a single-page JS app. Specifically - building in real-time updates only took a few lines of code. It was possible to achieve this level of polish with an SPA, but realistically it would have taken me so much time that I would have never prioritized it.
I hadn't touched Rails in over a decade. As a junior developer, I felt overwhelmed because Rails had solutions for so many problems I had not yet encountered. But, returning to Rails with some more experience - I appreciate its "omakase" [4] approach so much more. So many best practices are built in or easy-to-install. Queues, cron, async jobs, audit logs, email click tracking, end-to-end testing, real-time updates, caching, sessions, URL slug "friendly IDs", image resizing, rate limiting, admin interfaces, rich text fields, S3 integrations, sitemaps - they all just work!
With the new Version 7, Rails is truly a "One Person Framework" [5].
[1] https://www.booklet.group
[2] https://hotwired.dev/
[3] https://bookletupdates.substack.com/p/comments-directory-and...
[4] https://dhh.dk/2012/rails-is-omakase.html
[5] https://world.hey.com/dhh/the-one-person-framework-711e6318
tylergetsay|4 years ago
lnxg33k1|4 years ago
dataminded|4 years ago
paradite|4 years ago
For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server.
This was the path that my previous company took.
handzhiev|4 years ago
BMorearty|4 years ago
Small nit about one point in the post:
> As far as I know, serverless platforms don't support WebSockets
I’ve spent the last couple weeks deep-diving on Cloudflare Workers. They have good support for WebSockets. And if you need your WebSocket to maintain state long-term, the server side can use a Durable Object.
fidrelity|4 years ago
Ultimately went with Rails. As said in the article: so, so much comes out of the box or from a very well maintained ecosystem.
Real-time dashboards (action cable), background jobs (active jobs, sidekiq), auth, tooling, etc. was each less than a day's work which allows us to launch so freaking fast.
Only real downside in my eyes is the hiring for our location (central Europe) and future UI complexity, where my solution will probably be to just drop in a Vue app where it makes sense.
DanHulton|4 years ago
I strongly prefer the explicit nature of JS programming, where you don't have to know a bunch of Rails-y magic to know where a certain symbol is coming from, it's just defined in the file you're working in (to pick one example). But I completely agree that the time from Start to CRUD in Rails is a killer app.
I keep kicking up new projects in my spare time, and for every one of them, I'd have to set up the application scaffolding, linting, set up a layout and basic design rules, figure out user management, and if I was getting serious, set up subscription management, team management, etc. Rather than rewrite it every time, I figured I could make an actual library out of it so I have a decent base to work from, and then turn it into a product, because I can't be the only one who has these similar issues.
Also, Nodewood isn't alone out there - there are all kinds of Rails-ey bootstraps or starter kits out there for all kinds of languages. Now, the fact that everyone thinks "Ruby" and immediately thinks "Rails", but they don't think "Node" and immediately think "and a starter kit" means Rails has performed some amazing marketing mojo, but that doesn't make it fair to compare JavaScript to Rails, the author should be comparing JavaScript to Ruby, or Rails to a Rails-ey bootstrap.
jack_riminton|4 years ago
papito|4 years ago
https://www.youtube.com/watch?v=y8OnoxKotPQ
whoisthemachine|4 years ago
lominming|4 years ago
Has that been changed/improved? Or RoR is still primarily used to build server side rendering (SSR) web apps?
avidphantasm|4 years ago
prea|4 years ago
I'd venture to guess that for a RoR newbie, it takes just as much time to understand the 'glue' (I've heard people refer to it as 'magic') that makes it all work together behind the scenes.
pictur|4 years ago
recursivedoubts|4 years ago
We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end.
But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects.
This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that.
I know I'd like the latter for my java projects!
20wenty|4 years ago
Zababa|4 years ago
My question is, how do you know when to choose which one? For example, I'm looking to build something that's in the "unbundling Excel" vein. The application will have lots of input from the users, and lots of graphs. It's supposed to be pretty interactive (once again to mimick Excel). And I'd like to build a SaaS out of it. What would you pick, and why? From what I understand a SPA would be better at the "heavy user interactions" part, and a regular MVC framework would be better at everything else. Maybe a combination of the two? But with limited development times, it seems like it would be slower to do that.
impostervt|4 years ago
The more "standard" the product you're building, the better off you'll be choosing a framework that is highly structured.
katzgrau|4 years ago
Barely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.
gwbas1c|4 years ago
The Razor templating system is very nice. It's not like mustache where you have to learn a completely new syntax; it's very minor bits of C# and regular HTML.
I'm not sure I'd pick Blazor in a complete greenfield situation; but given that I'm working in a C# shop, it's a great way for C# developers to be full-stack while keeping the learning curve simple.
fuzzy2|4 years ago
Instead, this is more about serverless vs. “classic backend”.
zdiscov|4 years ago
codingdave|4 years ago
Rails is not the only choice that does so. And people with broader skill sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
rosgoo|4 years ago
pphysch|4 years ago
SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects and companies.
SPAs are not designed for developer productivity, they are designed by BigCo that can spend 0.01% of their revenue to hire multiple teams/ICs to squeeze out a +0.1% increase in revenue. It's comparable to doing microarchitecture-specific optimizations for your clientside website code. Totally irrelevant to your side project or startup.
Pick a productive stack/framework and build out your product with a solid foundation. You can always bolt on websocket-based features as required. Maybe rewrite your frontend in a SPA framework once you hit $100mm revenue.