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.
As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts.
The best way to work on rails is to either already know rails yourself, or be working with a rails guru, which admittedly there are a bunch of those.
At least with a configuration over convention you can just look at the code and figure out what is happening. With rails, there are certain magical things you just Need To Know and the only way to know those things are to already know them before running into it.
I was going to say the same thing and figured someone else already had.
People would often ask how I knew so much about rails and, ya, the answer is that I read the guides. They are extremely readable and it doesn't take that long. Like a couple of days. You might be surprised how much is retained by just reading through them, even without actually trying things out as you go.
I would like to stress: read the guides, not the docs. Use the docs for reference.
I've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing.
Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem domain.
The rails guides document about 10% of the problem domain. That's mostly ok, because the problem domain exists in the wider world, and there's lots of documentation elsewhere. The problem is that the rails guides document about 1% of the solution space. And that's an issue, because rails claims to be the solution space.
Rails routing is done by passing a block into the framework that's instance_exec'd on... Something. Want to know what, so that you know what API is available to you? Too bad. Here are a list of recipes for the couple most common things you might want to do. Want to do anything more sophisticated, or just understand what your options are? Uh, sorry.
Oh, you want to set and read cookies? Here's a recipe for how to read cookies and how to set them with lots of options. You changed how you're setting cookies and now browsers are returning two cookies of the same name and you want to know how to detect and fix this? Silence from the rails guides! (In fairness, the rack documentation actually included enough information to solve that. But it wasn't mentioned in the rails guides about cookie handling. And the rack documentation was a specification, not a guide. It actually tells you what pieces there are and describes their semantics.)
And it just goes on and on. Rails has about one hundred options for every one actually mentioned in the guides. In some sense that's a good thing. The guides only give you an incredibly limited set of tools. It's very good that the rest exist. But it means that the guides are a very bad way to learn rails, because they don't give you enough information to solve unforeseen problems yourself, or even enough information to understand code someone else wrote to solve those issues.
They put you in the position of hoping someone else anticipated your weird problem and already told you how to solve it. They don't equip you for solving anything weird by yourself.
This feels pretty stawman-y to me. They are meant to be highly digestible examples of everything the framework has to offer. They can be read through quite quickly, yet people still fail to and then you have people who don't know what scopes are or reinvent ways to do enums and what-have-you just because they weren't aware this stuff exists already. If you need to drill down into a specific topic, that's what the docs and blog posts are for. Having the level of detail you describe in the guides would only turn-off newcomers even more.
The guides are great for someone doing what most people use Rails for. Recipes with some side cases are very appropriate for that audience.
If you want to know more about an API, there's https://api.rubyonrails.org and the classes are quite will documented. These docs don't show up in the guides and might be what you're looking for. I should also point out that the API docs are directly linked in the header of the Guides.
> Programming is not regurgitating recipes without understanding.
Call me cynical, but the problem with this argument is that professional software development is about making something that fulfills a set of requirements, and ideally is modular+generalized enough in its design that it can be reused in the future to reduce future development time+costs.
With this in mind, I can see why the Rails documentation wouldn't really care if you learn how Rails works- all they care about is that you know how to use it.
This isn't to say that the desire for greater understanding is bad, just that it's not an effective way to keep an aging, tried-and-true web framework relevant.
You do know you can read the api documentation right? Also you can read the code. The guides are not supposed to have every answer to bugs you encounter. 1% of the solution space? Please, youre so far off it’s laughable
When people ask me how to improve their programming this is my first advice - speed read docs/stdlib top to bottom and keep writing a lot of little things. It’s amazing how many people choose painful path of learning through osmosis.
If you want to make an app from scratch, you must first understand the universe.
This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.
there are about 35 guides in the rails guide list and half of those are digging deep into the framework... reading the first 10 of them would get you about 95% of what you really need to know in rails so that you can look up stuff later. hell even just doing the getting started guide walks you through a fairly complete rails application.
yah, that's what i did when i first got into rails (~3.0/3.1): read 5-10 of the guides while working through michael hartl's tutorial and reading/watching a number of railscasts (which are dated now, but still have good basic info).
i'm working (slowly) on a personal project in rails 7 using all the hotwire with importmaps newness, and so far, it's been so much better than recent rails' diversion into all that node/yarn/webpacker mess.
I just put all the essential ones through firefox reader mode and the high end of reading them at what is what an average reader can read at based on the word count and it puts it at 10.31 hours of reading. that's a basically complete understanding of rails that most people don't have. to get 80% there you could probably skim most of them and read the main articles on models, views, and controllers and be done in a few hours. (firefox uses a somewhat naive approach though that just counts words and can't distinguish new code vs. the interesting bits so i'd wager the time is less since there is a lot of repetition in code)
it's not a ton of investment compared to how much time it would save you if you use rails later.
"Best way to learn" seems too vague to have a productive conversation about. If your goal is to become proficient with a framework, then reading the docs top to bottom is probably a great thing to do, but if you merely want to hack together a one-off project over a weekend then it's probably not worth investing the time to exhaustively learn about all the features and paradigms of that framework.
Did you learn English by reading the dictionary top to bottom? I’m gonna go ahead and guess that no, you didn’t. You learned English by being surrounded in it and practicing.
You're being strangely combative in this thread, as though you are personally offended by something. What's your problem, and why are you letting it drive you to make such weak arguments? Do you have some past trauma related to being forced to read, or is it just bad experiences with Rails specifically?
It really doesn't take more than a few seconds to figure out why your analogy of learning a language by reading a dictionary written in that language is both stupid and inapplicable here, so I'm not going to try to further address that aspect of your comment (especially since you don't seem inclined to directly respond to anything in my comment).
You’re right, I apologize. You are right that my analogy is stupid on a bunch of different levels.
I’ve been surrounded by so many rails fans who use it for every possible problem. “If all you have is a hammer, everything is a nail” was the epitome of what was happening. Then being left with trying to sift through old versions of documentation, trying to figure out what is the “current” way of doing things in rails vs the previous ways, aye yi yi. Rails has definitely left me with a sour taste in my mouth.
I’m not saying rails is bad, it is great in so many situations. I’m just saying it is not a silver bullet, and the cult behind it has some real blinders on.
I stand by my original argument though that for most people, reading documentation top to bottom isn’t the best way to learn. If it works for you, great.
It's the single most irritating interaction I have had with a coworker, and I have had it at least once at every job I've ever had.
"Hey, thing xyz is super confusing, can you (help me use it|explain how it works|rewrite it so I understand it)?"
"Did you read the document I sent? The document (has sample code that does the thing you're trying to do|explains how it works|explains why the simpler approach doesn't actually work in practice)"
"...No."
It's incredible how some devs can learn 15-20 different programming languages, and completely forget English in the process.
Call me crazy, I’d just rather read the relevant section of code I am working on and be able to understand it from there, rather than first having to understand the entire universe.
When working with a framework, it helps to understand the framework. Then, all the individual pieces make better sense. The advantage is that you only have to gain this understanding once.
A framework is a social contract, if you will. The framework authors are taking on the onus of some complexity to give you a cleaner and easier to grok codebase. The tradeoff is that you do need to read the guides or you will be diving deep into framework internals whenever you want to understand some app level code.
The problem with RoR is that it's an all-encompassing framework. It gives you a huge collection of things you typically don't need — entire major layers like the database are frequently completely irrelevant to projects. This isn't just true of small projects, but can often extend to a large part of a career.
One of the grave dangers that older/wiser programmers have learned is to stop trying to pathologically "drink the entire river". Programming has a constant deluge of new frameworks, tools, and publications coming out, and it's easy to fall into the trap of thinking you need to know, well, everything. I know a lot of 'aspiring programmers' who accomplish next to nothing precisely because they waste most of their time reading about programming instead of actually practicing it. It's sadly rather similar to 'aspiring writers', or any other craft — some reading is helpful, but not when it crowds out the actual task it's meant to teach. Life is short, and you have a choice between "actually making things" and "doing prep work for making things". That's all reading the docs is — it's just prep work. It's completely useless unless it parlays into actually accomplishing things.
There are semi-rare cases where some language/framework is actually teaching you new fundamentals and is worth deep-reading to gain core skills as a programmer. Haskell broke new ground. Lisp was enlightening. Smalltalk was a worthy historical study. Rust is genuinely changing things. Unfortunately, Rails just isn't special.
When I was considerably younger, I used to pathologically do this — I used to buy books on programming, and read them like a school textbook "exam cram". I read entire books on languages (like Perl) that ended up exiting the zeitgeist before I ever did any work in them — and I now have no reason to do so (I feel sorry for Perl, because Larry Wall seems like a cool guy, but perhaps it's a testament to its influence on other languages that it no longer has uniquely redeeming features). I even read books on various applications. Naively, at the time, I looked at learning as a pure, unalloyed good — rather than a dangerous spend of lifetime I'll never get back.
I deeply regret wasting that time on that instead of learning a meaningful skill.
> The problem with RoR is that it's an all-encompassing framework. It gives you a huge collection of things you typically don't need — entire major layers like the database are frequently completely irrelevant to projects.
You do know you can just turn off the parts you don’t want, don’t you?
Don’t want database support? Just turn it off or don’t include it in the first place.
Rails doesn’t have to be “special” it just has to get the job done and it does.
Agreed but as evident in this post's discussion, developers only have the desire to do so once for <insert-favorite-web-framework> and then the need to do so again for any other framework is understood as the other being clearly terrible and immature.
This is a fine answer if you're responsible for a small numbers of technologies, otherwise there are far too many "top to bottom" docs to read in a lifetime, let alone the time you have to meet whatever deadline is in front of you.
Where it gets even trickier, is that these days nobody is responsible for just a small numbers of technologies.
Does your app use the internet? Read about TCP/IP and DNS and other internet technologies top to bottom.
Does your app use a database? Read the DB docs top to bottom.
How about multiple data stores?
Is you app publicly facing? Read about 100 different potential security issues top to bottom.
I could go on...
Only if the docs were good enough! You always have to look at the source code for most Gems and it's full of unnecessary "magic". I guess Django is a much better alternative because of Python different school of thought
I couldn't have had a more opposite experience. My last job was as a solo dev on a legacy Rails 3.2 project. I didn't even know Ruby when I took the job, but have a lot of experience with other MVC frameworks. Learning Rails has mostly been a breeze with a lot of "I wish framework <X> did it this way, this makes a lot more sense" type of moments.
Rails docs are among the best I've ever used for a framework personally. They blow most things in the JS ecosystem out of the water.
Apparently people prefer blog posts to docs. This is not a problem of course, until you need to either debug (hence understand what you're doing at depth) or build something non-trivial.
The problem with Rails is not a lack of blog posts or docs, it's that there's often no way to find what doc you need to read without already understanding the framework. Reading the entire docs and then trying to remember and understand it is a style under which some people learn well and I think it is important for mastery, but the ability to trace back and understand a small piece of a framework is valuable too especially when you're first starting out. Certainly when I try to understand something with node or js libraries I don't jump to blog posts, but I am usually able to find what I need to google to to get the docs I want. That wasn't the case with rails when I was first starting
No the real problem with Rails is autoimport and bad tooling that you can't jump to source easily. I would love rails if jump to definition worked well but it's deal breaker.
I agree that Rails has a kind of a steep learning curve. Also agree that I didn't find the Rails Casts helpful - I found them out of date, so I didn't spend any time watching them.
For me, learning how to learn a new thing at times seems like the hardest part for me. For Rails, the best I've found is the Michael Hartl tutorial [1]. He walks you through setting up a blog with Rails - first the quick way and then the hard way, so you walk away with a nice understanding. He keeps the tutorial up to date and he's been available for questions when I've emailed him. It costs a few bucks ($39) but well worth it IMHO. I spent a few weeks going through that book, did a few apps on my own, and then was able to create new apps fairly quickly.
The official Rails Guides are a great resource too and kept up to date too [2].
Configuring your local rails development environment is pretty easy with the thoughtbot laptop script [3], otherwise it can be kind of a pain to do it from scratch.
I'm appalled everything I realize most developers don't actually read docs... It's unbelievable. Do we expect things to work the way each of us imagine? Or what do one expect when starts using something without reading the documentation?
I have the exact opposite experience. I have done a lot of Java - Spring, Node + Angular / React development. And having just started a job with Ruby on Rails, I have never found a new language + framework + ecosystem to be so easy to jump in on and learn and understand. The convention over configuration works really really well.
If that's not bad enough you're probably working on a legacy app with a whole bunch of mix-ins, proxies, Active Record callbacks, and other nonsense that makes it nigh on impossible to understand what any code does.
Saying that mixins and callbacks are always incomprehensible is silly. They're just a way to pack up code and they can work beautifully. If you don't wanna use them you're gonna have to write the logic in some alternative way, so a bunch of service objects I guess? Does that automatically make code comprehensible - the fact it's using many small classes? I'm sure people can and are writing shitty services as well.
There’s nothing more frustrating than debugging some ruby module with 10 different mixins defining functions with generic ungreppable names like “user”. Then it turns out the mixins have mixins.
The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
Rubymine's autocomplete got to a state where I barely ever have to grep anything.
Look what you're describing can happen, it's just not that often or is the norm. It's usually some crappy legacy project no one wants to upgrade or touch that reaches such a state, there's absolutely no reason why what you described can't be refactored. The fact it isn't being refactored tells you more about the company/teams working on it than about the framework.
> The common refrain is well, don’t write shitty code then, but all code starts off looking good to the person who wrote it. I guarantee if you have 400 engineers working on a Rails app it will end up in this state because it (ironically) lacks sane guardrails
This can be said the same of any other framework or language. It is up to your team to organize the code, write documentation, agree upon linting rules and of course encourage best practices. If you’re leaving those decisions to each engineer writing code - thats the problem
I’m not sure if this is still a thing but I remember the Rails community being obsessed with aliasing methods and other ways of dynamically defining code at runtime. Coupled with the fact that Ruby is already hard to statically analyze and ‘grep’ is your only hope… good luck following the alias_method_chain rabbit hole…
So maybe your problem is there is too much documentation that spans too far back and getting current relevant examples and docs is the hard part. The rails guides are kept current, but any popular framework that has been around for a while is going to have a similar problem. Rail's guides are pretty good compared to many others I've seen. Also there are books, courses, video series, and plenty of other resources that are up-to-date. There is no shortage of high quality up-to-date learning content available. It just may take some work to weed out some of the older content.
There is a reason why most coding bootcamps are based on Rails and React instead of Go, Java, PHP, .Net etc - they are easy to learn, work and reason with.
> the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts.
I mean, when learning a new language or framework, reading the docs or watching videos and tutorials are part of the course? What other MVC frameworks have you worked with where someone new could just go in and start building an app without actually learning it first?
I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly.
You don't need devise, so I think it's good it's not included. It used to be that devise was good to use as it had the best practice way to set up the password fields etc. But that has been moved to rails core. It's still worth reading the devise documentation, but I'm so familiar with how it sets things up I can just set it up manually faster than messing around with devise itself.
AFAIK there's nothing in the rails guides to help with authorisation. I googled and couldn't decide between pundit and cancancan. I went with the latter because of some tutorial videos I found. But it wasn't easy: 1. I couldn't find documentation for methods so common as `can?` [1], and 2. the 'magic' of how rails automatically sets instance variables differently and sometimes not at all before each action was also very confusing. Like many other things, it was confusing until you understood what it was doing, but figuring out exactly what it was doing and why took hours of experimenting with the behaviours of each action, and being the recipient of quite a lot of condescension on stack overflow for even asking.
When I learned rails the community had a fundraiser to fund the documentation writing (this was v0.7 or so IIRC). Being able to read the docs sounds like a dream come true.
As a beginner, I didn't find this to be true. Django worked fine and could do what I wanted.
I suspect that if I were coming from Javascript where "I know what I want to do" if only I could "make Django do it", I would feel the impedance mismatch.
This is a very standard problem--"You can write FORTRAN in any language." Leaving behind the idioms you are used to and adopting the idioms of your new environment takes time and energy.
There was a lady in one of my previous projects whose job was to maintain the integrity of sensitive financial data (she was doing a lot by hand, as they wanted a human to check every number). In the 2 years or so I worked there, there was not a single mistake from her. I didn't hear much appreciation for her from others, but my CTO used to call her the most important person in the company.
Some tools, some people just work, just do their job quietly and efficiently. They do not get any appreciation, precisely because they are too efficient and go unnoticed. JS is not one of them for sure.
I doubt this, at least for my country a simple search in LinkedIn of "NodeJS" and "React" have tenfold the results of searching for "Rails" or even "Django".
It might be a bubble but basically every new startup and small/midsize company are using NodeJS and even big companies are building new services with it.
At the least, it is a self-reinforcing tragedy. ("Look, all the big players use framework xyz as well, it cannot be that bad then!") JavaScript being thrown at problems, for which it is not so well suited with all its warts. Web developers being thrown at problems, with which they do not have experience, because "Now we can use JS in the backend as well!". In many cases it sets organizations up for getting stuck at local maxima or for straight failure.
Never thought from this angle and it does make sense. Probably doesn't explain all the difference, but a considerable part of it is not unreasonable to assume.
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:
I should've been more clearer. This post isn't comparing Rails to any framework out there.
What I was trying to say is that Rails got a lot of things right and it's making me productive, because I don't have to make the same decisions over and over again when making a JS app. Rails made those decisions for me and the only thing left for me is to build my app.
I myself like Next.js and Remix a lot, but they still leave you to spend time making basic decisions, like how to organize your project or how to implement background jobs.
That's why I'd love to see more conventions and less configuration in the JS land.
> I'd love to see more conventions and less configuration in the JS land.
Which is what the parent post is saying NestJS offers. I'm not familiar with it, so can't comment on the veracity of that claim, but I think you might have missed their point, perhaps because they confusingly called it "Nest.js" which could be mistaken for "Next.js".
You could compare Red Delicious to Granny Smith and a programmer will come along and say it's an unrelated variety. The problem is even if you want to use a larger library/framework, there are over ten thousand to choose from. The JS ecosystem is built upon the Unix philosophy of "Do one thing and do it well." So there is a reason React is not a framework and that is not your fault. If you do not use a Rails copycat, you are left with many decisions for packages. Nobody has time for that so everyone just uses what is most popular. So the comparison is fair, it's just a comparison between philosophies.
I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives.
The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and the rest in the early 2010's, and it went along with Github and the emergence of everyone and their dog building libraries and frameworks.
The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose. This was exacerbated by React that emphasized NOT being a framework but just a rendering layer.
Pick ANY one-size-fits-all framework in the JS space and you will see "bad" decisions that people don't like.
The closest thing to a full JS framework at the moment is probably Angular, which feels bloated and overly complicated (annotations, component / folder structure / file naming) or Express (stringly typed? I haven't looked at it in forever).
The dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a Rails protect. JS would have to lose a lot before it could achieve similar focus.
Ruby is a wonderful language for other things outside of Rails. I'm old. I've done csh, bash, perl, tcl, and python for scripting and miscellaneous programs. Since discovering Rails, I use Ruby for basically everything now. The only miss I've had in recent memory has been needing to do heavy statistical work with R for speed reasons, but, then, you're not going to do that in JS (or anything else) either.
As someone who has used Ruby as my main language at a number of companies for the last 17 years and deeply dislike Rails and rarely use it, I couldn't disagree more.
Rails draws the attention, but there's plenty other uses.
That's interesting to hear, I would have guessed that Python had long won everything that could be ruby but isn't rails. Clearly, nothing will stop the inertia of someone who just happens to be productive through experience (you can probably find works-for-me wizards for almost anything, perhaps not for vba or ada but I wouldn't bet on it).
Is there much happening in terms of libraries outside the rails scope or is it more a case of one less thing to worry about once you've become good with the batteries included?
Thor looks great! I'd be surprised if something similar didn't exist for most languages, but with many of them living in obscurity because discovery is so hard without a well-established name for that class of tool. Some googling for "CLI framework" led me to oclif ("Thor for js"?) and to https://www.nexmo.com/legacy-blog/2020/06/12/comparing-cli-b... , but that can't be everything.
PS: https://github.com/shadawck/awesome-cli-frameworks also lists some for go and rust, getting there! (though most probably not half as complete as Thor, self-documentation should definitely be a first-class citizen!)
I rarely find an area where I've needed libraries and there haven't been decent stuff available in Ruby other than when doing quite esotheric stuff (e.g. there's no good low level X11 client implementation for doing raw X11 stuff). Often multiple competing projects.
E.g. for ORMs ActiveRecord which is Rails default is in my opinions nowhere near good enough compared to e.g. Sequel, and there are several others.
Sometimes those projects involve wrapping stuff - including Python - or porting Python, but most of what I use is pure Ruby.
With respect to Python, to a lot of the Ruby community Python is in many ways the antithesis of what we want in a language. Python looks horrendous to me. It matters - I stare at code most of my day. If I were to switch languages, Python wouldn't make the shortlist even. It's not that I think Python is objectively worse, but subjectively to me it's unreadable and messy and I can afford to avoid using it most of the time.
EDIT: To expand on some of what I use or have used Ruby for: web dev with Sinatra and Padrino (my main reason for avoiding Rails here is that most of what I do is mostly API driven, and because I prefer Sequel as the ORM), financial modelling (I work for a VC), my text editor of the last few years is written in Ruby (but not packaged up to be useful for others yet - I'm gradually splitting parts of it out into gems, though), DevOps by generating terraform, service orchestration (proprietary pre-Kubernetes orchestration of containers and vms across on-prem, colocated, managed servers and VPSs split between openvz, docker and KVM), system to auto-deploy replicated sets of Postgres servers with logs and backup dumps automatically distributed to a Ruby storage service (pre-RDS, and running on the aforementioned orchestrator), PDF generation, messaging middleware, scraping, large scale crawlers, trading bots. And many more.
Rails has a clear one way to do things because there are no/few other options because everything else has withered away.
To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.
It always gets me abit, angular is called bloated however all the react/vue applications i have worked with have been bloated by shitty packages left and right to fix problems that never existed in angular, im probably just to old or what not but i dont find the configuration bad since you can always figure out what went wrong, that is not the case on react/vue unfortuenately, it ends up being very opinionated by the last dev that took charge, and the endless refactors of architecture because now there is a new way of doing it..
> The attitude was different; instead of big opinionated but inflexible frameworks, people wanted to pick and choose.
I enjoy working with Node and JS, but this IMO is what contributed to the fragmented node ecosystem where you have 100 different npm libraries that do the same thing and reinventing the wheel is rampant
The point here is that you do not have to think about choices, there is a "rails way" for every problem. There is no such thing as "the node way". They are hundreds of ways, some of them are dead ends.
And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.
If it turns out your goals are a very simple crud app for a team of under 5 - Rails is probably a great choice.
For most everything else, you should probably understand why Rails made the choices they did, and what the trade-offs are. (ex: I would argue that the author is making a HUGE mistake by not just immediately outsourcing auth to something like a self-hosted Keycloak instance, or Okta/Auth0 - but my needs require enterprise auth support (SAML, OIDC, Provider support, etc) and maybe his don't)
But the thing is... there are TONS of simple CRUD app frameworks out there. Rails is a good one, but so is NestJS, or ASP.net Core. There's at least one "Opinionated" CRUD framework for almost every language.
Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change, too many contradicting "opinions" between major versions.
> And thank fucking god for that. It turns out there's no such thing as "The one way" - it's a choice for a reason: It has consequences and trade-offs that are applicable to your goals.
That comes with a downside though, which is that for any given problem there won’t necessarily be an ultra-well-supported “happy path” where every conceivable problem has long been documented along with a solution.
To me the lack of happy paths can be a problem. It’s something that is often encountered with Android development because Google can’t make up its mind and it’s very frustrating — usually your choices are between 5 different APIs that suck in different ways, meaning you have to pick the one that sucks in a way you think you can deal with best. It’s a significant damper on both velocity and motivation.
If you're just doing something so simple that "every conceivable problem has long been documented along with a solution." then you're using the wrong tool if you're programming anything at all.
Problems that fall into that space are usually better served by simple site builders (Wix/Square/Shopify/Wordpress/etc).
It also comes with more debugging in the node world. Since everybody is doing things differently and the packages you install are usually poorly tested (or not at all), you very encounter shortcomings.
> Too many versions, too much change, too many contradicting "opinions" between major versions
Tell us you haven't used Rails much without telling us you haven't used Rails much. There's been precious little I've needed to change in my approach since the 3.x days. The new TurboJS world they're baking into 7 sounds significant though.
> Rails is still good, but I find it has a distinct "ASP.net classic" feel to it now - Too many versions, too much change,
Well Rails is gonna celebrate 20 in 2 years, so yes there's quite a lot of versions and changes over the years, that's inevitable for every long running project I think.
Arrghh... This week was the first in years where I didn't FOMO. And here comes Nest.js.
I desperately need an ad blocker though for shiny new tech thingies.
Interesting, why is Nestjs used by so many online casinos? Is that random or is there some specific feature or approach used that is particularly valuable for that use case?
Online casinos have usually been very aggressively sponsoring anything and anyone willing to take their money (and the usual reputation hit that can come with the perceived shadiness of gambling). That's especially true for newcomers who just burn as much money as they can, trying to establish a foothold. I'd say, being on the front page of a popular, credible project like that is probably sought after, hence the unusual amount of casino sponsorships
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.
React really has nothing to do with SPA and is only the "V" in MVC. So I'm curious how you were modeling your data in the first place. Since you didn't mention the backend language, I'm going to assume you aren't using node and don't get the benefit of isomorphic code here.
I don't feel it's too much of a stretch to assume that most people doing SPA are probably using node on the server and something like Redux. Then it's a matter of "hydrating" the Redux store + React. Which basically amounts to serialization of the data and passing it to the client via a global variable embedded in the source of the HTML page. When done in this manner, the modelling and fetching of data is identical on the client and the server.
> I’m in the B2B software space
Does your software act like an application? I really feel like B2B is the place to use SPA. You have a login, some sort of dashboard, the user interacts and modifies things. SPA is really slick in this use case. Where SPA falls apart is when you need to present your site as individual pages to Google for SEO and try to get some of the benefits of SPA. That's a nightmare to get right and to maintain.
For B2B I would not use SPA on the marketing, landing, pricing, signup pages and use SPA for the application, itself. Effectively a dual site. Which works really well.
Agreed. We tried bolting a js front onto our elixir app and instead ended up using liveview. It saves us a ton of effort and has most of the bells and whistles our users expect anyway.
This comment would be more helpful with some examples. I’m personally very curious what the leading solutions are. I’ve worked with one involving GraphQL but that’s about it.
I can't speak to leading solutions, but in the .net world, there's Blazor[0] which is C# for the whole stack. There's also Fable[1] which is F# the whole way down.
btw. most of the time I wish my company used such things or that code would be more isomorphic, BUT!!! most of the time isomorphic models lead to way more problem, especially when it comes to validation.
Maybe this isn't what the GP comment meant, but I think codegen can serve this function pretty well nowadays. I'm currently working on two separate projects, the first is a Django project with DRF and I codegen with drf-spectacular [1] and openapi-typescript-codegen [2]. The other project also uses Django, with the API through Hasura and codegen with graphql-codegen [3]. In both of these cases I've been able to largely avoid duplicating my models clientside, or at least it isn't manual.
Can't speak for the rest of the world, but my team has been using an NX monorepo with a standard types library that can be imported into any application in the monorepo. It is trivial to use the same interface, enum, class, or other type-enforcing mechanism across multiple frontend and backend services. The development experience has been quite nice, and refactoring/changing the data structures is a breeze. If you are in the Typescript world and haven't looked at NX...check it out.
By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.
Yep, I personally have written our backend in Python (with type-hints) and the frontend is a React SPA that I recently migrated from JS to TS.
After the migration to TS, I really want something I can use to model the data once and use in both the backend and frontend, because its very repetitive. Haven't found anything yet.
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.
Been working with Rails close to a decade now. I've built several, non-trivial products using Rails for the API, by myself. What I and my coworkers dislike about Rails is the sheer amount of magic. Oh and concerns, let's not forget that pattern.
Rails is amazing at standing up a CRUD app (really API) in a matter of minutes. I can have a basic CRUD app with authentication, authorization, API, caching, background jobs, local development (docker compose), production in any cloud / k8s and CI/CD done within a day. Adding business logic that's well tested is simple.
Once the app starts to get serious usage, needs to integrate with complex enterprise systems, handle huge loads of data, etc. it becomes necessary to step away from Rails-way of doing things. All of a sudden you can't push more into Sidekiq cause of how much it impacts the DB via ORM loading. Now you're writing custom SQL. It's not all that hard to do in Rails, but at that point, you're writing Ruby and not using Rails magic any more.
Your dismissive comment does not address the realities of building a solution that goes beyond CRUD. It ignores the many levels of experience present on a team or the amount of technical debt one accrues while building a non-trivial production system.
While it doesn't take much experience to get started with Rails or to get a good amount of progress on a product, it takes skill to keep the technical debt under control. Or to make good decisions about architecture. Or to understand which parts of the system to optimize. It requires actual experience building web solutions without the crutch of a framework to know when to ignore Rails and when to double-down on it.
And your dismissive comment attempts to imply that I haven't done "real" work with Rails, but I can assure you that, with 25 years of professional development experience, 13 of which using Rails as my primary stack, I have integrated with many legacy systems, and I find Rails works really well for that, actually. And, while I admit there's usually a place or two in an application to have to "shell out" to hand-coded SQL -- and even more tellingly -- that's usually some of the most-important functions of the application, it's hardly a reason to throw the baby out with the bathwater.
Making good architectural choices for complex problems/solutions is difficult with any framework or language though. What I like with rails is that it's easy to work on the easy parts, but it doesn't stop you to make more complex choices on the difficult parts.
class Assignment < ApplicationRecord
belongs_to :project
belongs_to :release
accepts_nested_attributes_for :release, reject_if: :all_blank, allow_destroy: true
end
Would represent several hundred lines in Java and Angular.
Do you really need to see every line of code required to explain every object and how they relate to each other to the various compilers in your application?
Ok I'll bite - what else have you tried and what made rails so more productive?
My experience with big web frameworks - though I can't speak to rails in particular - is that everything is sunshine and rainbows until I veer a little bit off the standard path (or rail) and then it all becomes a nightmare. Where as if I'd done a little bit more myself up front, the thing is more resilient and can easily go where I want it.
Really happy to be wrong here, would love it if rails became my secret weapon. I'm a big ruby fan. But I'm sceptical.
Rails has a ton of escape hatches when you want to make a different choice from the defaults, just as long as you’re writing a web app or HTTP API. The challenges I’ve run into in the Rails ecosystem more revolve around 3rd-party extensions making assumptions about how my app works and not being as flexible as the framework.
I've done web apps with PHP, ASP.NET, .NET Core, and, unfortunately, Java/Angular. The only thing that really hangs up .NET for web apps these days is its reliance on Entity Framework. What I've finally concluded is that I'm glad to tradeoff speed and strong typing of .NET/EF for the flexibility and "omakase" of Rails/AR. Obviously, YMMV.
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.
I think in reality the JS ecosystem is fat with choice for convention over configuration style frameworks. Projects such as Nest, Sails and Adonis leave nothing on the table compared to Rails. The problem is a lot of programmers would rather loosely cobble something together with express than to stick to rigid standards. That's what I think actually leads to the problem of inane NodeJS codebases people always complain about, it's cultural rather than technical. Perhaps the accessibility and popularity of JavaScript leads to a much larger crowd of inexperienced programmers.
My hunch is that most JS developers just aren't aware of these frameworks. A lot of people in this thread are mixing up Next.js and NestJS, and NestJS is the most popular out of the three you mentioned. Sure it has a lot of stars on Github (44k), but even I had forgotten I had starred it.
A lot of JS tooling that popped up in the last 10 years is amazing. The React way of building a UI makes a lot of sense to me and I like it way more than HTML + JS combo from the old days. Also, using JS for both frontend and backend is convenient and great for hiring teams.
But, after years of making SPAs, it gets tiring to assemble all of the pieces from scratch every time. I don't want to configure things, I want to build my ideas.
I've seen this myself on the .NET side. Someone will create an MVC application then rip all the views out and tag everything with a decorator that turns those controller endpoints into API endpoints, then slap Angular or React on top of that. More recently I've seen Web APIs created which explicitly lack any front end integration (this is what we do at $DAYJOB when .NET makes sense).
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.
I think there are ways to do this correctly but it has to be more static pages with JS enhancement and/or making certain sections standalone "single page apps". It sounds like you're halfway in-between and that leads to the sorts of issues you're talking about. Being halfway in-between does mean that you're also halfway to an SPA, so maybe just commit fully to that direction?
Personally, I find webpacker to be straightforward and not that magical relative to the asset pipeline.
> it's better to take the less opinionated road (SPA in this case), so you can be more specific later
Can you elaborate on this a bit? Are you saying that an SPA with React (+ other server-side pieces in NodeJS?) would have been the better choice than the Rails + some React mess you wound up with? What about sticking with just Rails, no React?
Yeah, SPA approach would separate the frontend and backend conceptually to different microservices.
Frontend is served separately off CDNs, backend isn't involved with it. When frontend team decides on a different framework/approach, they can switch, and the frontend just consumes the backend API.
Backend focuses on building an API, doesn't have to deal with templates etc.
The other server side piece doesn't necessarily have to be Node, it can be whatever the backend team wants it to be, Rails is also fine. All it has to do is spit out JSON.
I think he wanted to know why you decided that you actually needed React on the front-end, as opposed to doing it «the Rails-way»: HOTwire Stimulus etc.?
Some back end devs unwilling to learn React are planning to try it.
However as I understand, it's using WebSocket. At my previous job, building a customer service view that used it solely for real time updates, I wouldn't use it for anything critical without some heavy fault tolerance (like checksums or a simple incrementable number to count how many messages have been sent). The messages can be randomly dropped by whatever is in between.
I wouldn't want to write in Stimulus as a front-end dev. It looks like writing AngularJS from 2012, way too imperative. Template and logic are also separate which makes legibility harder compared to JSX.
AFAIK Hotwire Stimulus isn’t using WebSockets. I think you’re thinking of StimulusReflex.
Normal Hotwire Stimulus is just JS controllers that references DOM nodes via CSS tags. Example: https://stimulus.hotwired.dev/
I agree that JSX is better.
Check out Rux which is «A jsx-inspired way to render view components in Ruby» [to make HTML on the server]. https://github.com/camertron/rux
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.
This and my sibling nailed it. Defaulting to a SPA is a terrible way to start web projects you would like to complete on time. But wait! Now your company has "front end devs" who you can't trust to touch your back end - better use React again to give these people something to do since JS is all they know.
My approach is Rails until the last possible moment. I'm no Rails maximalist - I did recently spin out a major part of our application into an Express service, as the Node library for a specific task was the best in breed. But I'm very defensive against signing my name on a complexity mortgage.
Agree, unless your UI is very interactive and complex e.g. a photography editing app then you can likely go without an SPA
Your designer might be pissed, but your customers probably don't care all that much and your CEO is going to be pleased at the speed, stability and simplicity of what you've created.
I've run into plenty of apps that don't really look that great yet are SPAs. Like basic form post kind of sites. As I mentioned elsewhere, I got blocked paying a student loan due to one, and had to jump into Devtools to get a broken CVS app to submit a prescription request.
Agreed, but additionally you might need/want an SPA because you want to be able to very quickly spin up mobile/desktop apps (e.g. with Capacitor/Electron) or you want a functional offline mode.
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 think the healthy part in the SPA workflow is that you can focus on one thing at a time by design. If the whole app is backend driven, everything is tangled and I might be tempted to fix everything at once.
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.
I think you don't want to support the article's claims, but you kind of support it by mentionning the choice that you need to make between NestJS and Adonis or any other frameworks. With the ruby ecosystem, there is almost always a clear convention on what to do (example: the conventional choice
is to use rails, which leads to a bunch of pre-made choices)
Conventional choice at a framework level isn't really necessary though, is it?
I mean, you can read and choose what you like whether it's Nest/Adonis/Blitz or anything else. Once that choice is made everything that follows is opinionated.
Part of the problem I think is that none of the JS frameworks became a clear winner in the full stack batteries included framework niche. For Ruby the clear winner is Rails. For Python it's Django. For C# it's .NET.
What is it for Node then - I keep getting many names - Nest/Next/Adonis/Blitz/Sails? And lately Redwood? And probably more I'm missing out?
It would have been better for Node if there were 1-2 frameworks with huge momentum behind them then 6-8 frameworks that none of them caught a lot of mindshare.
So long as that is in fact the point of the article, I agree completely. However I'd still have to point out that comparing the Rails framework to solutions which do not try to fill the same role such as React made for a confusing article.
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:
In my opinion having to be explicit about what imports are used where makes the code more readable. There's never any "mystery" methods suddenly being called in the middle of a complex function (sometimes without a namespace so you're not even sure which library it's from), and I suppose it makes stuff like tree-shaking easier as well.
Still requires one import but that's hard to avoid. Don't be afraid of them, the IDE will usually add them automatically and hide them anyway. It's a good way to increase tracability maintainability, instead of magic stuff happening in the background.
It's a contrived example, as I say. The point is constructing intervals and doing the interval range checks requires importing those functions everywhere and constructing shape objects for them to use. Don't read the code literally.
Obviously you can wrap them in a your own interval function which does the same thing. So like:
function myOwnIntervalBetweenFunction(date, offsetBefore, offsetAfter)
Which is more hygienic but my point is I don't have to do that with Ruby ever.
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].
I wish the Go community had a popular monolith framework that folks rallied behind using when necessary. Unfortunately it's a wild west of bodging together your own routing, config, auth, etc. and nothing is consistent.
Reminds me of Paul Graham’s essay on language power “Beating the Averages”
“It must have seemed to our competitors that we had some kind of secret weapon-- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.”
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've interviewed a lot of web devs over the years. The distribution on this question is surprisingly bimodal.
One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it.
The other group of web devs has learned one very specific tool and they want to build their career around that tool. The business requirements don't matter. They're going to use their favorite tool regardless of whether or not it's appropriate. The more complex they can make something, the better they think it will look on their resume.
The latter group can be valuable assets if you know that your application requires a SPA and matches the person's chosen specialty. However, if you're hiring a dev who wants to build complex apps and your company doesn't require complex apps, you're going to end up with unnecessarily complex apps. Then the person will use the complex app to boost their resume and leave for another company.
Fortunately, it's not too hard to differentiate between the two groups at interview time.
"One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it."
You could replace SPAs with almost any technology (Queues, Kubernetes, an RDMS as opposed to BaaS, Servers as opposed to lambdas) and it would be correct depending on your own background and personal bias.
Can confirm. I once had as a team me a weirdo that would refuse to run ANYTHING on his computer outside of docker. From git, to his browser, to the mail client, to the editor...everything had to be in a container. His Thinkpad had more containers that our entire production cluster. What a waste of energy and time.
at least for me, that's the difference between someone on a senior level and someone that is not on that level yet. sometimes you just need to be pragmatic and say "this should be on an ec2 server with a simple html page -- no need for a react frontend that talks to a graphql endpoint that sends message to rabbitmq so another microservice can consume it".
also, being able to accept that a simple solution is good without putting too many barriers in front of that.
Just using an EC2 server typically involves a load balancer, a web server (nginx/Apache) and another web server like unicorn to manage the threads, and then a database at the bare minimum. That’s not objectively than using an SPA and a BaaS.
If you’re a front end engineer who’s used to working with node then an SPA + BaaS might be much simpler to you than running an EC2 instance that serves basic html.
Edit: and that doesn’t even get into securely managing updates, access controls, infrastructure, etc. those things might seem fairly trivial today but in the future imagine getting dinged for them in an interview.
A friend inside my company was telling me that they can't have an app written for them in C# because it's NOT JAVA. That .NET stuff is too new and trendy! And probably insecure!
I swear, my Fortune 150 company is going to continue to do waterfall development in Java by outsourced teams until our products are no longer relevant, and we're bought for spare parts.
> One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it.
I like to see myself in this group. The problem is, however: requirements creep. Especially when consulting. The customer doesn’t know the full extent of their needs, and they always want more and more. Which in the end often invalidates the initial decision of «going simple and lean». Then you’ll have trouble explaining why incremental changes start to take so much time.
So I think there is some merit to the approach of getting really good at a particular powerful and generalizable set of tools (even if they have flaws, such as not being lean, a bit complex, and shipping more JS to the client). I think that’s why React and NextJS’ is so enormously popular, even though they’re overkill for most sites and webapps.
Have you noticed a difference depending on when they got into web development/whether they trained for it?
One thing I'm noticing as I'm looking for tech jobs as a tech person who hasn't ever been a tech employee before is that a lot of the job listings are very heavily tool focused. I wonder if newer/junior devs are reacting to what the market is presenting (as you hinted at with 'The more complex they can make something, the better they think it will look on their resume').
Junior dev here (but a career changer at aged 35), I initially learned Ruby/Rails at bootcamp
80% of the market is looking for some React + backend and there's a huge pressure to learn such an SPA framework but I've steadfastly refused and have stuck to 'full-stack' Rails. Luckily there's a resurgence going on for Rails and I think it's going to last. Boring always wins in the end
I'm your polar inverse: I'm 33 but started coding when I was 4, I've just never worked as a developer (at least not on a team; I've done freelance), and I'm debating making the jump as inflation starts creeping up. I run into the opposite problem: I've played around in frameworks but I don't have the 'years of experience' with them so I worry my resume is going straight in the trash.
Ha, I had a very nerdy upbringing. My grandfather was obsessed with TVs and ran a side repair business, and then in turn my dad got into micro-computers and PCs. On my mom's side, we've got a bunch of engineers and sci-fi nerds. I learned to type before I could write, and I learned to read by playing things like Dragon Warrior with my dad.
I was also a hyperlexic little weirdo who did things like read the SimEarth manual for fun when I was 5 and decided to explain the differences between prokaryotes and eukaryotes to anybody who would listen. So when we got Web access in '93, I was all in. And I loved getting to do something where all that mattered was how good I was at it, since I was bored senseless in school.
I very much had an upbringing like Larry Page's. I'm just a lot dumber than he is.
Edit: I also doubt you could do that now, on reflection. So much of learning programming is based on feedback and I could only collaborate because nobody asked how old you were and/or if they did, they assumed I was lying. Up until I was about 11, it was assumed I was somebody who just didn't want to share any personal information online/a privacy freak who was making up a stupid answer. "Okay, haha, you're a 7 year old girl. Fine. I won't ask."
You are correct - many apps use SPAs when the business requirements don't necessitate it. I got hung up paying a loan on the Department of Education because of bad Angular on the payment form. I had to "hack" (push through a request using DevTools) a page on CVS's speciality pharmacy page to order a very important medication. (Also Angular)
There are definitely apps that are only possible using SPAs. Using a front-end framework should be based on business need, not personal preference, but unfortunately, boot camps and the like are churning out developers who are being taught that every problem is a nail.
Is SPA just another way of saying "WebSockets"? I've added minimal websocket-based real-time features to what are otherwise simple serverside web apps, for example a terminal emulator. Don't need to go full SPA.
Yeah whenever these SPA-slamming posts come up, I just try to imagine carpenters posting about why they switched to hammers from screwdrivers. They're just different tools that excel at solving different problems.
To use your analogy, what if a popular screwdriver company started a trend among young carpenters to use their screwdriver handles as hammers? And then large numbers of carpenters were driving nails with screwdriver handles instead of hammers?
That is where the SPA slamming is coming from.
It's not that people fail to grasp the concept of different tools for different jobs.
As I said in a sibling comment, the problem is that some SPA-developers then see everything as one type of problem (I said nail there, but using your analogy, screw works better). Carpenters will tell you that screws aren't really superior nails - certain applications actually hold up better with nails (interesting enough for this analogy, those with a lot of side load, where screw heads may actually shear off)
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.
Obviously anecdotal but the startup I just joined (12 people, series A-ish) chose Rails. The team had previously come from a startup who crashed and burned in the complexity of a React SPA
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 agree - Rails does everything, and there isn't a JS solution that's similar out of the box. You have to be familiar with a ton of stuff not to get caught up in content marketing traps for solutions that look like they fit your use case but probably don't.
For prototyping things, I like the way Next.js generates a lot of boilerplate routing and api endpoints for you, and so in that way it's similar to rails scaffolding things for you. But when it comes to db migrations, an ORM, anything else, you're on your own!
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.
This aligns with my experience. It’s also a classic case of picking the right tool for the job.
I think RoR is an easy choice for anyone looking to ship some variation of a basic CRUD app. Trying to do anything interesting (read: competitive in today’s SaaS market), however, becomes a chore in reading source code to understand undocumented “magic” and fighting the framework. Use Rails if you ship many different CRUD apps or a CRUD app that is just a frontend to your services business (your “real” product).
On the other hand, learning how to bootstrap a proper JS (ideally TS) app is a job for someone with time and experience. Even then, not all answers are satisfactory. The benefit is the full power of modern web is unlocked. Use JS if you’re trying to build a company that will live or die on a single SaaS product.
Every company I’ve worked at falls squarely into the “single, innovative SaaS product” category. The ones that have started on Rails always tack React on top and then it’s just a world of hurt as the complexity gets out of control.
You have to know enough about the choices and their edge cases to make good choices. You are also at the mercy of all of those choices continuing to evolve in complementary ways in the future.
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.
why you see having more than one option as a problem
Because some of us are hardwired to choose carefully. If so, when we have to go buy some groceries we just want to get a decent car and drive. The car and driving itself is irrelevant or minutiae, but we can’t tell whether it could take left turns from the start. When there is no decent car by default, we try to be picky about every component, and when it’s almost perfect, it’s also night and the shop is closed.
It may be easy for you, for a combination of reasons: a huge experience, low perfectionism and high “fuck it, will sort it out later”-ism, and then something else. But it’s not a professional path we used to. Our professional path is to ask someone which car to buy and go buy it. But if you ask someone which js framework to use for regular tasks, you get this thread instead.
On top of that, your resume will miss a 3 years of Winch experience, which suddenly everyone demands when you lose a job or fail your company.
I think that perfectionism is a downside and coined that “easy for you” as a better mode which everyone would operate in otherwise. But it’s hard to let go of these anxious feelings, so we stick to picky routines (because if you’re not confident, it is unwise to git push). Sorry that my message wasn’t clear enough in this part.
Personally I’m trying to care less when it is reasonable to do, but even the amount of options where to do that in common js stacks is overwhelming.
I mean, analysis paralysis is a real thing. But I think people vastly overestimate the value of having a golden hammer solution like Ruby on Rails on your ecosystem and downplay the disadvantages.
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.
I had similar feelings with Rails. Just memorize this billion convention and you are good to go. Also didn't help that running Rails on Windows was (maybe still is) considered a bad idea.
Same here. Inherited a huge rails code base and it's as bad as any node project. The autoloading has been enabled in the entire project so I have no clue whether a class is defined within the project or is fetched from a gem. I've never grepped this much in my life
I don't know for rails, but whatever dev I do on my Windows machine I just do it via VSCode in WSL2. Or I ssh into my dev machine (shared hosting via uberspace).
I haven't even tried to setup dev environments for python, php or js on Windows. It is just so easy to use WSL2.
I mean, there have been plenty of valid arguments against PHP the language and its standard library, but the big issue most people end up having have to do with its ecosystem, developers, and frameworks. My earliest rants about PHP was the sheer volume of bad tutorials; googling for "php sql" or whatever would invariably give you examples susceptible to SQL injection. And the other issue was that everyone was building frameworks, CMSes and forum software left right and center; there were a lot of islands, each with their own ideas, structures, etc.
PHP should have made a much bigger push early on; mark the weird and unsafe functions as deprecated and point to e.g. prepared statement alternatives. They should have built a package / dependency manager much earlier on. And they should have made a lot more efforts to get a developer community up and running.
If you're actually interested in the subject, a good way to familiarize yourself with the current state of PHP is to run through something like https://laracasts.com/series/laravel-8-from-scratch. It should give you a good idea of the current state of PHP, what educational resources look like, along with a taste of the most popular PHP framework out there.
These conversations always tend to go the same way; someone complains about PHP and then later admits it's based on their experience 5-10+ years ago. PHP has come a long way and is worth checking out if you're into web development.
I recall that when Active Storage was publicly announced[0], Laravel's Filesystem (itself a thin layer over Flysystem) had already been out for at least 2 years[1].
I came here to say that, as someone who's used both Rails and Laravel.
Basically it comes down to magical behavior, and the fact that Rails has way too much of it. Syntactic sugar and DSLs are maybe fine for rolling out new projects, but become burdensome on large codebases. I was on a large project and found myself in goto hell where I literally couldn't trace through the code. It was relying on every magic trick in the book to make the code as small and cute as possible, but failed utterly to provide anchors in the code where "this happens here" or breadcrumbs connecting chunks of code. It was a giant hodgepodge of I don't know what. Really clean spaghetti code I guess.
Now, Laravel has its own warts, but they aren't conceptual warts. For example, the stack traces in Laravel are way too tall, with way too many factories and patterns in the vendor code. I feel that things like the IoC container were not implemented as well as they should be. The goto hell in Laravel happens around stuff like the bootstrap process, registering service providers, queuing, etc. They made some mistakes in scattering those things around instead of handling them in one central place. Pretty much all classes provide 95% of what you need, but adding missing functionality yourself requires learning the entirety of the package (in fairness, this happens with pretty much all platforms). There's a tendency for Laravel projects to not support helper functions or custom classes in a standardized way, so sometimes it's hard to find business logic. Not nearly as hard as in Rails though. But as a whole, I'd take conceptually clean interfaces with mundane implementations and no surprises over magical behavior any day.
Just to not leave anyone out - I wouldn't implement business logic in any Javascript framework. I feel that async basically makes it impossible to do it deterministically. I'm sorry that happened to Javascript and am still in mourning about it, because it had some advantages over PHP in how it treated associative array access with "[]" the same way as object member access with "." which could have been used in PHP to implement copy-on-write everywhere and really set it apart from all other imperative languages. Mistakes were made in both, and Ruby as well, that took them all in directions that I wouldn't have chosen.
You know, I wrote up a long response about what strikes me as a good framework, but realized that the core of it is that a conceptually correct approach may not need a framework:
Today I mostly write solutions in a synchronous-blocking, functional-reactive, event-driven, immutable, stateless, data-driven, declarative manner that tries to avoid custom types/objects, manually managing nulls or asynchronous behavior. Which if all orchestrated correctly, leads to future-proof code because it's so obvious that it's self-documenting and the failure modes are all safe.
IMHO, the vast majority of software out there involving Javascript, Ruby, Python, really any of the imperative languages, can't achieve what I'm trying to do. It even feels like they actively work against me sometimes. I think of Laravel as getting most of the interfaces and approaches conceptually correct, even if the internals use factories and patterns and hand waving that I consider spaghetti. Whereas Rails involves some element of drinking the kool-aid, because it encourages some conceptually incorrect approaches like ignoring process separation to achieve better performance or fit with some preexisting notion of what's beautiful or easy. Along those lines, probably stuff like Phoenix/Elixer, Erlang, etc are closest to what I'm working towards, but they introduce their own custom syntax that strikes me as perhaps too DSL-like and I have an aversion to that. Which is the main reason why I struggle to learn stuff like Haskell.
There truly are vanishly few actually good solutions today, and I've been following web development for over 25 years now. That used to really get me down. But I realize now that the situation presents an opportunity to fix things and build a better future, which I am grateful for.
Sure, community interest peaked around 2014, but usage among enterprise and startups is higher now than it ever was. Ruby is boring now because it works.
If you want typing in Rails, you're in reality itching to try Crystal lang and most likely Amber framework. Much faster too as it's a systems language.
I’m itching to try Crystal, since it has goroutines aka. greenthreads aka. fibers for easy concurrency, static types, automatic null checking, and performance on par with Golang.
But Crystal has around 468 open bugs at the time of writing :(
I did run a startup for a year that was on crystal, and I will say the community is quite good at addressing real bugs. There are a lot of "you don't know what you're doing" bugs and "this is already fixed but you haven't updated" bugs and "this is really a feature request" bugs in the tracker. I wouldn't read into it much. There hardly exists a popular programming language or framework without at least several thousand open issues.
As the commenters pointed out, Express.js doesn't try to solve the same problems as Rails. Trying to use one for the other's use case doesn't make any sense.
Yes, but the problem is that there's still nothing in the node ecosystem that's as complete as Rails. Fine, express.js isn't going to do the job. Neither is anything else.
Python is plenty popular and so is C#, and when you're looking at a batteries included full stack framework you have ONE popular choices - Django or .NET. For PHP it's Laravel (sure, you have other options like Symfony but they are niche), for Elixir its Phoenix.
How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?
> How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?
How is it a bad thing? Again, JavaScript is far more popular than all of those for web related development. The issue is that like you're stating, there isn't a single main option perse. I'd use NestJS.
I think its generally bad, or at least I wouldn't want no part of it. There's decision fatigue for one - how the hell do you decide what to use.
Another problem is why would I want to relearn a new framework every time I switched companies? And how do I know these frameworks are going to survive long term in such a chaotic community?
I have little doubts Django or Rails will be here in 10 years, can you be confident all these JS frameworks will still be here? Some will and some will probably become irrelevant.
Yes Next, Nest, Sails, Gatsby, Blitz, Redwood - none of them became a leading framework like Django or Rails or Laravel has, which means being a Node developer and moving between companies or projects you'll probably relearn everything in a different framework.
For me this is just to chaotic and unstable.
I see no difference. PHP has a billion FWs and a billion more CMSs. Python is the same way. Rails is the only example you give that has merit. I mean PHP is a terrible example. I've been coding PHP since around 2007, PHP has Zend FW, Laravel, Cake, Ignitor, Symphony, Silex... it keeps going and going. All I can see from your comment is some biases against JS. You do you on what you want to learn or use. But its not really an argument that holds up imo.
Laravel is the leading PHP framework by far, I don't think it's up for debate. Ruby also has many frameworks (Padrino, Hanami) but it's obvious Rails is the common choice.
Laravel is as much of a leading framework as React/NextJS are the leading frameworks for JS(next 2.5 million weekly downloads on npm, react 15 million). Its almost a 1:1 comparison. In the same way that I already pointed out JS like php, has a million fw but insiders know what the leading ones are. Everyone knows React is the clear on top winner. NextJS is also a clear on top FW. I dont think its up for debate at this point.
Yes, and in the Ruby world we also have Sinatra, but notably, people have tried and failed to get Rails-like frameworks up and running in JavaScript (Sails.js, others). The question is whether the problem is the language or the community -- I think it's a bit of both.
I've used Laravel and agree that PHP isn't all bad and can be used intelligently. And this is coming from a former CodeIgniter core dev (if you recall). But being real, you've got to admit that most PHP projects aren't in Laravel, they're batshit spaghetti code continually reinventing (or outright ignoring) the standard patterns that come in a boilerplate rails projects.
That probably has more to do with PHP being such an easy language to get started with, inviting a lot of rookies/cowboys to the party.
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”.
I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views.
Rails is basically optimized for server-side model view controller with HTML views rendered server side and served to a browser. SPAs, mobile, and desktop applications typically have their own client side model view controller type frameworks; so server side views are not that relevant for those. Any frontend browser project I've dealt with in the last ten years or so was a basically a SPA.
A third variant exists in the form of server side views rendered using client side technology. Some people actually do e.g. server side react in order to limit client side processing. This is less common but perfectly valid. Back in the day, you'd use server side includes or similar technology. So, it's nothing new but popular for some things. Usually node.js is used for this but I've also seen this done via Java & Spring, which wasn't much fun for our frontend developers but still worked.
I'm not a fan of either Rails or Javascript server side. I've done both but it's just not my preferred stack. Ruby code bases I've dealt with were messy, over engineered, and underwhelming in terms of performance. It's been a while since I had to deal with that since it seems to have gone out of fashion. Most node.js stuff I've dealt with looks like it's fine for small projects but it gets messy quickly if you scale up. Typescript helps but I'd probably reach for other techstacks.
The point is, you have choice and there is a lot of specialized stuff out there and no technical need to use anything js on the server. My pet theory is that many frontend developers get into server development via node.js and then discover something better like Go, Rust, or whatever. I've seen some of my younger friends and colleagues go through this process a couple of times. My preferred server-side stack is Kotlin currently. There are several good server frameworks for it. I'm very familiar with Spring but have also used Quarkus and Ktor. Kotlin makes these a lot nicer to use.
> I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views.
Hm, no, sorry, I complete disagree. TFA is complaining about some choice. It is indeed related to the frontend. Then goes on to complain about project structure, databases, API design patterns/technology, authentication, scheduled jobs (really?), email templates (just trolling at this point) and Websockets. What?
Sorry. No. This article isn’t about stateful client applications. Or client applications. It isn’t even about server-side rendering. It is about backend (and its backend), and nothing but. SPAs are not backend.
TFA most certainly isn’t about about server-side JavaScript.
It’s only about “serverless”. Whatever that may be.
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.
Have you looked at Svelte? We've been migrating over to it from Redux/React, and it's so far been a great experience. It's greatly simplified a lot of our code, and eliminated a whole lot of redux/state boilerplate.
Definitely mature enough. Take a look at their really awesome interactive tutorial to see how well-developed all the pieces of Svelte are: https://svelte.dev/tutorial/basics
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.
The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that.
* Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core.
* React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
* Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
* Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc.
Without speaking of the DOM and CSS, which are just _now_ starting to feel feature complete for most use cases.
Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
I think Ember was a lot closer to a complete framework. I do believe that that's also why it didn't gain as much popularity. The learning curve was a lot steeper than for React or Angular. You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing, Redux or wherever you are including now. All along the way it feels smooth, but you end up with some more complicated, glued together whole. With a larger framework you might end up with something less complex and cleaner in the end.
I think on the backend we historically have had more complex problems sooner. You gotta connect to some database, serve multiple pages, track some context along, render views or API responses. It's much easier to anticipate the need for a framework or solutions to these problems sooner.
I built a product and we bet on Ember back when it, angular and react all looked like top choices. I’d say one of the biggest failures was that it didn’t provide clean upgrades We got stuck with 3.something and no clear path forward. Second, it wanted everything to be Emberized. I forget what exactly it was, but we struggled to wrap other tools in service containers so that they could be injected into our code. I think it was probably Google JS APIs like Maps, which at the time wanted you to load the toolkit their way. Ember-data probably was the biggest mistake to adopt. The amount of time I spent trying to fool some outdated JSON serializer in Rails into embedding something the way ember data wanted was a huge waste. The only other JS I’ve used seriously is Backbone, and once I was waste deep in ember I had major regrets that I didn’t choose it instead.
> You won't run into the problems with the slimmer libraries till later and at that point you understand them and "just" learn the new thing,
No that’s only true for “junior-based development” where every greenfield project is given to juniors with an assumption that “they will learn on the job”. So they start with a simple framework and learn “while the requirement are getting more complex”.
What in fact happens is that the project was severely under-specified by the stakeholders and the juniors had “no idea that would be needed”.
While I liked the React approach to UI modularization much more than that convulted MVC interpretation Ember had, Ember's routing was quite awesome, and I missed it switching to React.
Regarding "require" vs "import", I find this to be a constant nightmare trying to choose one or the other. The browser and tooling for writing for the browser has all-around excellent support for using "import".
Then, at some point, I want to run some unit tests using Jest or something, and it turns into a total fucking nightmare. Each bit of tooling has certain expectations for how it expects you to import--relative vs non-relative? Do you include the .js at the end? What about .ts at the end? (That one is always "no".) Do you need .js / .mjs or .cjs / .js? Do you use ts-node? Do you want to see a warning printed to stderr every time you run Node?
1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine.
I guess your point is that this would change constantly, which isn't really the case.
Yarn and NPM has been around for a long time. Yarn 1 used to be the better choice since NPM stagnated, now they're a bit more equal.
Typescript has been around for a long time. So has ES6 modules. Same for Jest and Mocha.
The only thing that is changing somewhat are the bundlers and build tools (thankfully, they've been the weakest part of FE dev for a long time).
I've kept up with frontend for many years. There really isn't all that much "fatigue" if one actually understands what the tools do and the niches they fill.
I agree with this persons answer, if your goal is to go full custom. If you want all this setup done for you I suggest NextJS. It should be noted that Deno is not a bundler but an entirely different JS Runtime. The question should be do I use Node or Deno.
I often find my choices will rub up against each other a lot. I never know whether to build glue code because that's the right way, or I should have picked a different library.
This really hits home for another JS outsider that likes the language but not the ecosystem. I like to do small personal projects in Node. Simple things like consuming the Google Sheets API feel great, but when I want to expand the scope of the project and start thinking about tests, caching, and "am I doing my modules/imports/package management the RIGHT way" I usually give up or switch to a different stack.
> * which test framework? Mocha? Karma? Jest? Cypress?
Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.
Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.
I think these are great questions. As someone who has been doing Golang for a couple of years and just got back to doing Node.js development again, I can answer some of these questions. I'll add that most JavaScript developers never think about these questions btw.
* Should I use npm or yarn?
This is one area where JavaScript is notoriously weak. As another comment mentioned, the answer might be different a couple of years from now. I discovered a package manager recently named `pnpm` and it is incredible, quite frankly. That being said, any package manager will do. They all work well (relatively, npm gets very slow in bigger projects).
* Should I introduce Typescript to be able to handle complexity better?
In 2022, the answer to this is almost always yes, for backend systems. I think this is unfortunate because you do need a transpiler. But its ease of use and type safety are hard to pass up once you've used it on a project. For frontend I tend to be more lax, although a lot of developers argue you should use TypeScript there too.
* Which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?!
Nowadays you'll likely only use `import/export`, especially if you're using TypeScript. This is not a question most JavaScript devs ask on a daily basis.
* Which test framework? Mocha? Karma? Jest? Cypress?
The short answer is it doesn't matter. The longer answer is that if you want assertions and snapshot testing built-in, Jest is a good choice. If you decide to go with Mocha, you'll need an assertion library (most commonly Chai). You probably don't want to use Karma as it was originally designed around Angular 1.x and it's starting to show its age.
Cypress is an end-to-end testing framework and has nothing to do with the rest. You'd use it in place of something like Protractor or Selenium. Additionally if you're using something like GraphQL you probably won't be able to use Cypress without a lot of hardship.
* Should I use a bundler like webpack or just move on to esbuild? Vite? Deno?!?!
This is only relevant in the frontend nowadays. And you'll probably want to use Vite. `esbuild`, while an amazing project, is a bit too verbose to set up and Vite uses it under the hood. IMO Grunt and Gulp and Webpack have never been good bundling systems (I dread every time I have to use these), so any new innovation in this area is welcome.
I see a lot of people complaining about the constant churn. I'm of the opinion that the JavaScript ecosystem is constantly improving. Vite and pnpm are absolutely amazing and I wish I would have had these tools when I was first doing frontend development. I would argue that every year JavaScript development gets way easier, not harder, and now it's the most accessible it's ever been.
Unfortunately, the amount of options can get overwhelming. Off the top of my head, there's a ton of HTTP frameworks (Express, Koa, Sails.js, Hapi.js, Nest.js, etc.) The list goes on. However I don't think this is a fair argument against JavaScript. There's a lot of choice in the Python and Golang world too. Just make good choices (maturity, stability, support) and don't always choose the newer, shinier framework, and you'll seldom run into problems in the JavaScript ecosystem IMO.
I looked at pnpm and I like it... so it's bringing the Maven strategy of having ONE place where dependencies are downloaded to and shared between projects to JavaScript!?.. which has been used since early 2000's in Java land... :D good.
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison.
How so? I found NextJS to be one of the most pleasant and well documented frameworks to work with. Sure, you'll have to read most of the docs to find out how to do something the NextJS way, but so far, I've come to agree with every design choice they've made.
The only gripes I have with it are debugging serverless functions that work in development, but then break in the vercel/aws blackbox.
I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both.
Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations.
Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.
I think in general it's a very tall order to compete with the documentation of Django. It's pretty much world class. I wish more projects had such good documentation.
Agreed with everything you say here. Really want there to be a go-to Rails-like framework for JS, but nothing has reached that point yet.
I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack app. https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use.
Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerplate to go on top of SvelteKit to give me all models, user auth, admin dashboards, payments, etc that you need in almost every app these days: https://sveltesaas.com
My big problem with sveltekit so far has been how strongly it wants you to use their back end.
I already have my own back end, but sveltekit is all about using their back end stuff. And their back end is 100% all in on serverless functions. If you want to write a more traditional back end and do something like grab private API keys when your service starts up, well sorry no easy way to do that, although there is an active git issue thread with people pretty much begging for the functionality.
Doing stuff like initializing logging libraries and passing them to models, or fetching API keys from secure storage buckets, is such a very common operation in any at-scale app, that I am beyond obscenely surprised sveletekit doesn't offer an out of the box way to do those things.
You can use Svelte completely separate from SvelteKit - we've been using it for a while now and integrating with our pre-existing APIs with no issues, some of those are serverless, and some are just instances behind a load balancer.
You can, but that is obviously not a happy path the svelte devs want you to use. 90%+ of tutorials and docs out there are for doing things with sveltekit.
I eventually beat it into shape of generating a true SPA, generating paths that weren't at the root of the domain, and I convinced express to serve up assets accordingly. Took way too many days to get it working though.
And there was Sails and any number of other attempts at this.
A key strength for Rails is Ruby and a key weakness for any aspiring JS equivalent is JS and the JS ecosystem.
If the Rails team had had to spend time adapting to 6 different alternatives to bundler, rack, and every other library they use it wouldn't be what it is today.
When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.
> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core
Maybe 5-10 years ago, there is no need anymore
> React is an excellent view library and nothing more. You will need to get one or three third-party system to turn it into a fully fledged web framework.
Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That’s basically it. If you want a centralized state store, you can pick one of those up. It’s really not that difficult.
> Frameworks like Next.js are good enough to create a static page, but as requirements grow more complex, its limited feature-set and lack of in-depth documentation will feel like a prison
I don’t find any of this to be true.
> Dev tooling is non existent, so it's on you to get and _configure_ a linter, type checker, testing framework, bundler, etc
You mean there is nothing built in to the language itself? Yeah, that’s a feature in this case. We wouldn’t have the amazing 3rd party tooling if it did. The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
> The JS tooling ecosystem is amazing and getting things setup nowadays just takes one command.
Which command would that be? Sure it's one command if you use one of a billion template projects, but just picking one of those is a chore and I'd never call that situation "amazing".
Nowadays the only choice you’re really making is which styling library to use and which state management. Everything else is a given.
Anyways, if you know enough about FE to have an opinion on the tooling, great, choose what you want. If you don’t wanna choose, use Next.js or CRA with React/Styled-Components and then add React Router if you need routing and add state management if you need it.
These aren’t difficult choices to make. I have a feeling that the problem is that people are trying to make decisions they don’t need to be making up front.
Evaluate the choices when you reach a situation that requires it.
React, Webpack, Eslint, Jest, React Testing Library
That’s the standard setup nowadays and it’s what most people should go with. If you want type checking, add TS to the mix.
But seriously, just use Next.js you can build tiny static sites with it and you can build complex SPAs. It’s very lightweight and basically just strings together all these tools while adding some convention that you can follow if you wish.
First, these generators are incredibly flexible. You can easily construct one command that fits your requirements. Understanding the correct options, your requirements for every part of the tool chain, and their occasionally predictable down-the-road implications takes quite some time, admittedly. However, all professional tools require knowledge and doc reading and experience with the latest bleeding-edge tools and experimentation and luck, I assume. Once you get a few years of experience under your belt working with this tool chain (not skipping the 3-4 hours per day after work to keep up with the latest JS ecosystem updates for this and the other new stacks you’ll need to learn throughout the week) you’ll be able to craft a command that requires very little reading or luck to use, and it could work, unmodified, for days, if not a week. If it turns out to not actually do what you want, you probably want the wrong thing— just ask on SO. But one-and-done, friend. Set it and forget it.
Second, this is all really easy if you just take the time to understand the tool chain. It’s just 4 or 19ish crucial, interdependent parts that all really should be in place from the very beginning and only most of them have inscrutable configuration schemas. Some are even documented! If you need more handholding than that, Sally, countless domain experts in countless online fora eagerly offer guidance like “go learn how X works first” or “lol that guide is weeks out of date— you have to use knippull.js instead of GROUNCE because GROUNCE was taken over by FlammBae last week and they’re just trying to sell add-ons for their data store and have ignored all PRs to support the latest version of SLAPPD which flibBleJs uses to transmogrify bNumbn{e}rs templates which you need for tr1xBits.js to work.” Once you understand how that all works, and understand how the generators implement those things, know how to compensate for the NBCF delta (Non-Backwards-Compatible Feature delta which calculates the number of implementation changes between typing the first character of your command and hitting enter,) theoretically your one-and-done is undeniably achievable.
Finally, people overstate the complexity of fixing a project started with the wrong boilerplate. Just experiment a bit. Spend a few days trying all the options to see which welcome pages don’t look broken in your browser (unless, of course, you’re using Waggle with FlermBox) and then narrow it down a bit based on that, and then just pick one. You can always fix it if it’s wrong. A literal child could understand the concept of “delete your project and start fresh” so I don’t think it should be hard to explain the concept to experienced software developers.
Developers used to paralyzingly straightforward legacy logic and organizational paradigms love to say that JS web dev tooling has the logical structure of a Wallace and Gromit short. They're completely ignoring the fact that this process was not designed— it evolved, and that’s okay. Not great, but okay.
Ultimately, it might look a little weird and insane and fragile if you peel back the onion skin to see how the sausage gets its secret sauce— but you too can achieve the pinnacle of modern developer push-button convenience with JS.
Is still either create your own or install a random package that brings other 20 as dependencies.
Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation.
Maybe you want modal dialogs, this is a standard in GUI tookits but you need to create your own or install a package/module/plugin specific for your project shitty framework
Maybe your designer demands a (context) menu one with keyboard shortucts and native looking like , or a scrollbar that matches the website/app theme colors or that works horizontally without holding Shift like in native apps, you have again to find 1 solution from a giant pile of shitty packages.
The dropdows,scrollbars, number spinner, color picker inputs CSS customization is pathetic, the designers demand customization and the only solution is installing third party stuff.
There is no DataGrid or ListView component with a smart implementation that can hold many items so all websites implement a crappy inefficient thing, or show you only 20 items and you need to hit NExt Page like a money or again you find a third party solution.
As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS. But as a platform the Web /DOM is still garbage, CSS got some nice feature with flexbox but that is all.
People that did not wrote complex desktop apps with a GUI framework will not understand this, and think that the shitty component they create by nesting 12 divs and catching 2 events is the exact same thing. It is not, this GUI frameworks components are efficient and handle all events/cases properly. Even Google devs were incapable to make the Youtube search suggestion dropdown work correctly, many times it gets stuck open and you can't close it without a reload.
This is a different discussion since Rails doesn't come with such an option either.
But I think you're hitting on two different, yet very related, issues here.
1. Browsers have a very limited set of standard UI components
2. Browsers are held back by the decades long, uninterrupted chain of backwards-compatibility
Both of these things are true. Back in the day, browsers forced more convention and design on elements (alert, select, input, list, textarea, etc), though developers weren't happy with the pace of innovation and design choices offered by the browsers so they began looking at alternative ways to implement the same thing. Eventually the browsers loosened up the restrictions and allowed styling of most of these elements in almost any way you like (though there still are issues).
The great thing about the web is that you are allowed to do this. You have the freedom to build things anyway you like. Of course, that comes with drawbacks like you've pointed out above. iOS is great because it provides a standard framework and approach to implement all of the things you outlined above. Though at the same time, you are limited to UX decisions that Apple deems "correct." I own an iPhone and Macbook and I wouldn't want it any other way at the OS-level.
But the web is the one platform we have where you don't have to abide by anyone's rules. The whole industry can iterate on approaches and the best ideas win. I like this world. I know it's not for everyone, but we don't have any other platform with such reach and freedom from any one company making the rules.
>The great thing about the web is that you are allowed to do this.
The truth is that for desktop(no idea about iOS or Android) I can also customize things as much as I want and I can do it faster and get better results. Desktop GUIs can give you pixel level access so you can have a button that plays a video inside it and rotates around while jump[ing and changing opacity.
About the Web I don't want to remove the option for everyone to invent their own menus if they want, I wish Mozilla,Google and Apple provide native options or as a stand alone library that you optionally include in your project.
For SPA this browser makers could colaborate to provide a standard framework, optional to use but would have all the basic features, bugs fixed and security updates, but it would be done by professional developers not as a side project by some Google dev with 0 experience in GUI toolkits.
> As a language JS progressed a lot, so much I am not sure if switching to TS is a good idea or I just need to wait until JS will catch up with TS.
Can you elaborate on this? TS is just adding type checking to JS, the only runtime addition are enums. I doubt that JS will incorporate type checking anytime soon.
I like to use class in JS to have types, some features are still missing in the major browsers like interfaces, some static stuff (I forgot), I miss the private and protected keywords , my IDE can show me errors for using the wrong types or even from JSDoc documentation but JS needs a standalone compiler/checker that will detect type errors at "compile" time.
My issue with the JS world is that it is leaking from frontend webdev into other domains. 0.1% of your users having a bad user experience because of using a "just good enough" JS library is pretty fine for me, even if I am - as a user - in that 0.1%. But taking down your whole k8s cluster thanks to switching to a "just good enough" JS library from a battle tested python library is the exact opposite of "fine".
> The issue I have with the JS world is that the most used libraries and frameworks are just "good enough for a small project" and no more than that.
Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.
Came here to say this. Angular ticks just about every box from the original article. It is opinionated (IMO in a good way, but YMMV), well structured, and batteries are included. You still have the flexibility to do data access, state management, and such however you like but there are well-established patterns and libraries if you want to lean on them. Modules help you scale to larger projects, with fairly painless code splitting / lazy loading. You don't have to set up any complicated build scripts, and the cognitive complexity is low (as long as you don't overuse rxjs) so junior devs can easily jump in. And, Angular is very mature now in 2022, with few-to-no breaking changes between versions. I highly recommend it as the state-of-the-art SPA platform today.
Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it.
It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
Well there are basically only two things that need to happen:
- The number of round trips needed to render a page needs to go from 3 to 2.
- The amount of JavaScript in the core framework needs to be slimmed down.
The second is already on the roadmap -- they are making Zone.js optional, and supposedly the next version of RxJS is going to be significantly smaller. In order for this to actually happen, Google needs to keep funding the project for at least another full year, which seems likely given how much they depend on it. In terms of the former -- well, it seems increasingly likely that they'll work on adding those kinds of options to the CLI once they get through with the other stuff. And if not, you can alway go back to straight Webpack and just do it yourself. (I personally like the benefits of the CLI and not having to deal with Webpack, but if Webpack keeps improving then who knows, maybe I'll switch back.)
> Javascript proponents say the ability to mix and match is its strongest feature, but to me the analysis paralysis of having to stop and shop for a library that does X (and will only do X) is a total productivity killer.
If you can settle on a good enough batteries-included framework without analysis paralysis, you can make the individual as-needed decisions about libraries without it. It's not a problem of a higher order.
If anything, it's lower-pressure, because the cost of a wrong choice is much smaller.
My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust?
My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
The working group most in charge of JS is ECMA's TC-39 (TC => Technical Committee) [0]. They've been taking a very deliberate, slow path to expanding the "standard" library because they take a very serious view of backwards compatibility on the web. Some proposals were shifted because of conflicts with ancient versions of things like MooTools still out in the wild, for instance. (This was the so-called "Smooshgate" incident [1].)
This may speed up a bit if the Built-In Modules proposal [2] passes, which would add a deliberate `import` URL for standard modules which would give a cleaner expansion point for new standard libraries over adding more global variables or further expanding the base prototypes (Object.prototype, Array.prototype, etc) in ways that increasingly likely have backwards compatibility issues.
TC-39 works all of their proposals in the open on Github [3] and it can be a fascinating process to watch if you are interested in the language's future direction.
If you are creating a rich web app, you still have to deal with all of this when generating HTML+JS in another language.
Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.
Sure. And I think what makes Rails and Django shine is they have sound default answers.
I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.
I'm working on two inherited Django web apps right now, for the same customer. I wish Django has a default project structure like Rails. It doesn't. The only common ground between the two apps is that they are written in Python, use the same ORM and templating engine. One is a spaghetti monster of a zillion of apps that depend on each other (so the separation in apps is useless) and the database is totally opaque to inspection. The other app luckily tucked nearly everything inside a single app so its saner to navigate and we can query the database with SQL tools.
The point is that Django lacks a sane default for project structure and it costs time/money to people using it.
That's not accurate. Djano encourages, but does not mandate, a particular structure. Incompetent developers will always find a way to subvert whatever sensible defaults are at hand, which is the case you are faced with.
I have not had as much of a problem with structuring django projects. I agree there could be better documentation recommending best practices.
There is a very good talk from Dan Palmer from Djangocon 2021 called "Scaling Django to 500 apps" that gives helpful advice for project layout in a django app that may only have a few or several apps:
That said, if we're going to dig on Django, it lacks typing, core-based API patterns and any embrace of modern front end. There are positive signals though, releases are coming faster and there is some real talent on the tech board right now.
I do think django and python in general are in a defensive position to hold the future of backend webdev compared to node / deno. However, there's still plenty of opportunity to compete for developers.
I've never used Next.js so I decided to take a look. The first step in their Getting Started guide illustrates this pretty well...
npx create-next-app@latest
# or
yarn create next-app
I would choose npx while my friend would choose yarn but there isn't a default or even an indication of why you might like either choice. We kinda just assume everyone already has a preference for npx or yarn.
This is really a Node or JavaScript problem and not an Next.js problem. Not that I have any idea how you might solve it. This is also just a single example and we tend to have these decisions at a lot of steps along the way.
As others have pointed in this thread, there's NestJS, Sails.js and AdonisJS, which are closer to Rails than Express or Next.js. And there's Meteor too, like the sibling post mentioned.
But to be fair 99% of JS backends I see are using Express (or AWS Lambda). Considering there's lots of choices I wonder if the problem is the fact the community never focused on a single solution. I wonder if a Merb/Rails-style merge between some of them would help that.
Recently I’ve also been impressed with Remix that was mentioned in the article. It seems to have solved the client server code duplication problem while still offering the benefits of both.
> I’ve yet to see anything in Node that feels like a stable 1:1 replacement
I’m not sure why there should be; for people who are happy with “good enough” default choices for a web app, Rails exists and makes the choice “Ruby” when it comes to language.
Definitely some exciting stuff like Redwood and Wasp working to solve these problems. I always loved what Meteor tried to do for this, though the JS ecosystem sort of evolved in a different direction.
Do most people use Django as a server-side framework (no frontend-JS or very minimal JS, may be jQuery)? Or, is it mostly used as an API to interact with the React/Angular/etc front-end framework? What I am trying to get at is do people still build POST-redirect-GET patterns and such for form submissions or they use Django in a more 'modern' way?
From my recent foray into modern Django world, most simple projects and MVP start out as server side like the official guide. Then, when people need some extra frontend magic like React and/or SPA, it's pretty easy to insert into Django. You just include the bundled React/Vue app into a js script still included and served by the same Django route/view/template. Of course, it's also common to start transitioning to Django Rest Framework (DRF) as your API points.
You can use either or both... server-side comes out of the box, and is used by the getting started tutorial. API-based is also very common using django-rest-framework.
I'd say it is still a mix of both and both paths are well-supported and well-maintained.
> 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.
No doubt here! I know there's a lot of nitpicking, but that's just my experience so far. I wanted to make it clear by removing all "we" or "you" words from the post to make sure I'm not saying my opinion is the definitively right one :)
> Rails is not the only choice that does so.
Absolutely, the only two reasons I went with Rails is because Ruby looks beautiful to me and I was following the news in Rails world for years.
Frameworks in general are about providing a set of decisions and idioms for you to follow, and so they work very well in teams and long-lived projects. They also tend to be pragmatic rather than exotic, so they are robust and useful, not fancy and brittle.
On personal projects I do whatever the hell I want, in professional projects I always use a framework, to make sure everyone is on the same page and we don't have to bikeshed every simple decision on the road to delivery.
A big thing a lot of people forget -- you can deploy most Rails apps to serverless/lambda (where individual controller actions are automatically mapped to individual lambdas) using Ruby on Jets with minimal to no changes to the original app. A lot of people think of Rails as a bit antiquated but that particular setup is imo ahead of what serverless framework even offers and definitely gets around the traditional problems of scaling rails app servers.
Rails does, but Ruby is so close to Python and Python has the numerical crowd so you're eventually going to need it anyway if you're successful.
I know it sucks, because Rails is better than Django, but at the end of the day I love Ruby but my day job is Python. Also, even though I can never remember capitalization, underscores , pluralization, interfaces in Python[0] at least I don't have to think when I type `and` and at least strings aren't mutable by default and when I need the data science it's right there waiting for me.
[0] lol "".startwith, "".starts_with, start_with(""), etc. In Ruby it's Time.now, come on people.
Ruby's not as consistent as you think. I can pull single examples out too -- is it 1.upto or 1.up_to? And I've never had a problem with Python's pluralization.
> In Ruby it's Time.now, come on people.
YMMV, but I don't find it terribly burdensome to import datetime and call datetime.now().
Because is it datetime.datetime.now? or date_time.date_time.now? or datetime.Datetime.now? Or datetime.DateTime.now? Or DateTime.now? or dt.datetime.now?
Because it could be any of those. Some people import datetime like numpy (import numpy as np) so they can call timedelta like dt.timedelta and this is fine and everything, but the combination of no standard in python for how to do this, plus the hard to remember interfaces, plus the multiple libraries that try to do the same thing and the different way they differ in capitalization, etc. Means there is just way too much to remember off the top of your head.
In ruby it's Time.now and I never forget it and I never have to import it and that is honestly awesome. If I open a shell anywhere in any project for any version of Ruby I've used the current time is just eight chars away, and even though I love Python, that has never been the case on any Python project I've worked on and I've worked on more than a few.
That's an interesting point. I used Rails extensively when I was a web developer. I gave this up when I shifted back to an analytical role and started writing much more numerical code in Python for analysis rather than application development.
If I were to write a web app, my first instinct would be to go back to Rails. However, I do agree with you that much as I like Ruby and Rails, Python would be my overwhelming choice for analytical or numerical code - and I do like Python.
One possibility would be to handle as much CRUD and UI development in rails as possible, and make analytical code available to the app through services in Python.
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.
Have you tried to implement interaction-rich applications such as calendars or text editors with server-side rendering? You won't be able to recreate the UX an SPA can afford, regardless of revenue.
Widgets require JS, of course. Javascript was born to sprinkle some of it on top of an HTML page, not to make a whole meal out of it. This is what GP is arguing about and I tend to agree. Single Page Apps are not worth the effort in my experience, apart from very niche use cases.
The velocity proposition and fantastic developer experience of writing JS in the backend and frontend and data layer is overrated and misleading. It's everything but.
I don't think anyone would take fault with using a SPA for a text editor. What most people are criticizing is using a SPA for a page that serves mostly non-interactive content. And that is the majority of the web, after all.
On whatever page you're using websockets, you're basically doing what an SPA does. If you click something and the page sends and receives a message via websockets and then updates the DOM, congratulations, you have something that's the same level of complexity as a SPA.
Your original post says that this style of interaction only exists to "fleece VCs". But it seems you're doing that, with an additional added layer of complexity on top (namely the server-rendered pages).
I'm guessing you implement the interactivity with <script> tags or something in your html/template templates, skipping the pain of npm and bundlers. I'm not sure that's the hard part of SPAs, though. Just an annoying one. The hard part is synchronizing the state of the frontend and backend over a communications channel.
Except not really, because one is architecturally simple and relatively easy to grok/hack, and the other is big and complex and built specifically for operating at a massive scale and multi-team environment.
We're talking ~200 combined LOC of idiomatic Go+TS & a couple popular libraries vs. an entire SPA framework and its various DSLs.
State synchronization over a long distance is always going to be a balancing act of performance vs. reliability vs. security. It's never simple and outsourcing those decisions to a framework is not always the correct choice as it may bite you later.
Yeah. I've done the server-side thing quite a lot. I don't like it. You always end up with "little bits" of javascript code strewn about in your DOM doing adhoc manipulations based on user events, server data arriving etc., and so the actual behaviour of your app is more difficult to reason about. Also, I want my users to have a nice experience and enjoy using the app, even if I don't have a KPI to represent that benefit. And until quite recently that was much easier to do in a modern SPA framework. I think the newer hybrid approaches like Phoenix LiveView give you the best of both worlds though.
I don't follow this logic. Why do you end up with JS strewn everywhere? Sounds like poor organization practices.
1. User arrives at a page where a real-time widget may exist. <src> widgets/mywidget.js on that page.
2. User triggers mywidget.js by pressing a button or just existing. It dynamically creates the widget elements, requests a secure websocket, then sets up input/output handlers.
3. Done.
mywidget.js could be big and sophisticated -- a multiplayer video game, for instance -- but it is certainly not "strewn everywhere".
I'm not talking about how my javascript source files are organized, I'm talking about how the functions are dispatched from the UI. That is done with event listeners strewn about in the DOM.
If you are referring to "the page is the widget" then you need to make a very good case why wrapping all the HTML in JS is in your interest. Facebook has an interest in doing this because they want to wrap every element in a bit of JS so they can closely track user behavior. Briefly hovering over a link, button or ad? Facebook wants to know everything about that interaction, in order to provide value to their clients (i.e. advertisers).
A normal developer is happy with that element just being a `<a>` or `<input>`. The entire page does not need to be a JS widget (SPA).
In my experience as a user, these SPAs built by very large companies for a very large audience seem to be full of bugs & issues when they try to do to much.
Something like a music player seems to work great as a SPA. But something more complicated like Google AdWords or large financial apps & you're bound to run into issues often.
It doesn't cite any evidence or sources, it just declares the opinion of one person on the internet as if they are facts. Who do think would be convinced by this that doesn't already agree?
> 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. This is frankly irrelevant to 99% of projects and companies.
And even so, I can't think of a single example in which there are two versions of a service and the one that almost never reloads the page feels faster than the one that reloads on practically every action.
In fact, the last time I recall seeing a large web-app sort of product that made me go "holy shit, that's so snappy I can hardly believe it's actually doing anything, but it is", it was... written in PHP and reloaded the page damn near every time you clicked anything.
> SPAs are not designed for developer productivity
Unless your app is big enough to have separate developers/teams for backend and frontend. In this case I'm relatively convinced by the argument that it allows you to decouple the two, so that all they need to agree on is the API.
Vue/React/Svelte are pretty damned productive. 1/5 - 1/10th of typical server rendered or native UI LOC. If I never write another line of code directly manipulating UI controls I can die a happy man.
SPA's need not be complex nowadays. I use https://lit.dev 's templating engine. When I want something simple, I use just the templating engine not the full web component framework.
Lit's templating engine is just html that is made super efficient to render because only parts that change are re-rendered. There is no inter language to learn like JSX. It uses native browser html parser, native browser templating capabilities (<template> tag), native event handling and native literal template capabilities of javascript.
I have a simple wrapper class that renders and composes components efficiently and reactively when state changes. The views look like:
class TestView extends LittleLit {
static get properties() {
return {
paramter: {}
};
}
constructor(){
super();
this.el=document.querySelector('#main');//root component attached to the dom
this.subcomponent=new SomeView();
}
render(){
this.subcomponent.somestate=this.somestate;//propagate state down if necessary.
let h=html`<H1>Hellow ${parameter}</H1>${subcomponent.el}`;
render(h, this.el,{host:this});
}
}
To use
v=new TestView();
v.parameter='world';//this triggers rendering if the parameter changed.
Here is my whole framework:
class LittleLit {
constructor() {
this.el=document.createElement("div");
this.refreshScheduled=false;
this._properties={};
let properties =this.constructor.properties;
if(properties!==undefined){
for (let prop in properties) {
this.property(prop,properties[prop]);
}
}
}
refresh(){ //you can call refresh to trigger rendering efficiently
if(this.refreshScheduled===false){
this.refreshScheduled=true;
window.queueMicrotask(()=>this._update());//deduplicated rendering in an efficiently scheduled microtask
}
}
_update(){
this.render();
this.refreshScheduled=false;
}
property(name,options){
Object.defineProperty(this, name, {
set(v){
if(this._properties!==v){ //refresh only if property changed
this._properties[name]=v;
this.refresh();
}
},
get(){return this._properties[name];}
});
}
I've also developed lots of server side generated webapps (edit: websites) and I still like the SPA approach more because it's more clean and domains are better separated. So the answer is usually yes, to me it's worth it if the problem requires SPA.
You make it sound like SPA-s are like the Death star, but this is really far from the truth.
read quite some articles like switching from SPAs to rails|django|laravel, basically from the new cool kid back to the old man in the backyard.
but, what about using Go with its web frameworks(e.g. Gin), it has everything you need to build a web application, and it could be all in one binary, and if you want to scale it's not hard too.
>I still enjoy React, but why is it so much harder to create apps in the JavaScript ecosystem, compared to Rails? We have all the necessary tools after all.
It is not harder at all as long as you do not commit to those giant frameworks and accompanying toolsets. I wrote decent size SPA using couple of libs and plain JS. Was fairly easy.
This is why i use Angular, alot of things are already implemented and working, its easy with nswag on top of api's. mostly i just use the framework rather than taking a bunch of design decisions, i just cant get along with the custom vue/react applications :(
I'm not a Rails person (just because I've never had a reason to learn Rails), but I'm a .Net fan. And oh boy how easy it is to create an app with it. On the back end, I pretty much doubt there's anything better. On the front, Razor is great.
I look at it the other way around, to someone coming from Ruby/Rails, there are far too many choices to make and it can seem very overwhelming. But on the flip side you get very granular control over your projects structure. Like when the author mentioned the framework options:
- NextJS, Gatsby - Best for building "websites" that are optimized for SEO
- Vite, CRA, Remix - Best for building SPA's
- Koa, Express - Backend frameworks.
On the one hand it's very overwhelming, but on the other hand, each framework accomplishes something very specific. Even the differences between NextJS and Gatsby, Gatsby uses a different model for how you would fetch data, with Next you write regular Node code, with Gatsby you do everything through GraphQL.
I surprised how few people have mentioned Remix. It's very Rails like (don't make me think). Albeit, Rails makes you have to think even less, Remix is headed in the right direction.
I'd like to clarify that you do not need any type of connection pooling or proxying in front of PlanetScale. We can handle a massive amount of connections unlike a lot of other DBs.
At least for the front-end part another, more complete framework like Angular might have been a better fit for the author. Angular comes with pretty much all you need.
As someone who is in the same position as author, Angular + Firebase is a very helpful alternative to moving to Rails while providing the benefits of an SPA.
I like the choices I get when building with JavaScript. There's always something new to learn and I get to pick the flavors that I like to work with. :)
But I do envy the simplicity of Ruby on Rails. I might try it for my next project after reading this article.
ASP.NET is great but it definitely comes under the same banner of 'too many choices needed' compared to Rails.
e.g.
Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)?
Database - Do you use Dapper, Entity Framework or just utilize a SQLConnection object manually (And then do you use System.Data.SqlClient or Microsoft.Data.SqlClient)? Which database driver do you you use?
Authentication - Do you implement this manually? Do you use something like Identity Framework? Do you use a third party provider like Azure AD(B2C), Auth0 etc. etc.? Do you use header based authentication, JWT's etc. etc?
Jobs - Do you create a separate service project or Windows Service? Do you use HangFire or Quartz?
Email delivery - How do you render your templates? Do you send via SMTP manually or do you use a third party API like Mailgun/Sendgrid etc. etc.
Folder structure - completely up to you, no real standards there.
Testing - Do you use XUnit, NUnit, MSTest, SpecFlow?
There is no "Core" anymore: LTS is now .NET 6. If you are building webpages, the "Legacy" .NET Framework 4.x is no longer relevant in any way (unless you are unlucky enough to have legacy apps with no drive/budget for cleaning up tech debt, and I'm sorry on your behalf). The last LTS "Core" version (.NET Core 3.1) is out of support in December and the upgrade path is simply .NET 6. There's only one choice right now and it is .NET 6. (It'll complicate a bit with .NET 7 in a few months, but only in the alternating LTS/"current" versions way of things like NodeJS, nothing like the Core/Framework confusion of the past few years.)
> MVC, Razor Pages, Web API and Blazor
MVC and Web API merged many moons ago, it's not really a choice between them, they use the same APIs and are built the same way way today.
(Editorializing: Razor Pages is making many of the same mistakes of ASP Classic or PHP/ColdFusion over again, and I don't see it as a great choice personally. Blazor is making similar mistakes to both Razor Pages and Silverlight, and
really feels like ASP Classic 2.0. I understand its appeal to some development teams, but wow does it seem like a clunker from my vantage point.)
This comment is ridiculous. You've shifted this from "too many options for everything" to "any options at all". Also, how are these things framework specific? The API vs templates argument also applies for Rails. Choosing an authentication method also applies to Rails. Choosing rendered emails via SMTP vs Sendgrid - also applies to Rails. And so on. You can't mix business requirements with "tooling choices".
Rails has a templating system for generating emails (standard HTML/ERB files). If you're running an ASP.NET Web API (not MVC) the best way of doing that I've found is via RazorLight which you have to set up manually - https://github.com/toddams/RazorLight
For authentication, with Rails the standard is pretty much Devise or Omniauth (or both) - does everything for you. I've never found anything for ASP like Devise which gives you an entire registration/login system with all the required views/models/migrations in a couple commands.
> I've never found anything for ASP like Devise which gives you an entire registration/login system with all the required views/models/migrations in a couple commands.
???????????????????????????????????????????
You know that this is built-in, right?
I don’t fully understand the issues people have with JavaScript and especially React. Maybe it’s because we invested some time in setting up a baseline project with ESLint, prettier and a TSConfig that makes for an entirely fascist way of doing TypeScript that just happens to always work. Maybe it’s because we don’t NPM install a lot of things, but instead take what we need and build our own packages (riding free on the backs of hard OS labourers, but hey). Maybe it’s because we build most compute heavy things in Azure functions running either dotnet or Node. Maybe it’s because we’ve adopted ODATA, build a generic API for 95% or our use cases and then build an ODATA TS client that includes types for all ODATA URI conventions and all our tables. Maybe it’s because all our packages are build with Rollup and Microsoft’s own Type API. Maybe it’s because our pipelines flow directly through Azure DevOPs and into different deployment slots automatically once it’s set up with docker. Maybe it’s because I’ve never worked smart with another tech stack.
But building things with react is frankly the easiest, least complicated and most enjoyable thing that I have ever worked with.
For references I have a decades worth of C# experience, with a gradual transition into Python and now into C# and mainly TypeScript.
Don’t get me wrong, I don’t think you should use a tool that isn’t right for you. If Ruby works, great. If Django works, awesome. Hell, if old customised ASP 3.0 web forms help you deliver the product you need to deliver, then I’m just never going to judge you. I’ve been part of teams that created incredibly business value with tools most people would consider insane after all.
But I think TypeScript is just increasingly useful. The only thing you can’t do with TypeScript, and especially with JavaScript, is Google solutions.
I learned this the hard way when I had to build my first NPM package. It was easy enough, but then it had to work with Azure functions and I entered a world of hurt. As any good senior programmer, I read the documentation and didn’t understand one bit or it, other than GitHub enterprise has replaced NPM enterprise which is kind of shit when you’re using Azure DevOps and not GitHub, but hey, we’ll just put our packages public. I don’t have access to the corporate credit card anyway and getting it takes a week, and going public will enforce a lot of best practices on its own. Anyway, a week later and 9 million Google rabbit holes later, I stumble across rollup and Microsoft’s api for generating .d. type files. Ten minutes later, everything, works effortlessly. But that’s 9 million medium, dev.to, you name it attempts later. It’s 9 million different ts configurations. It’s 9 million package.jsons later.
So I sort of lied when I said that I didn’t get the author, because I do, but the thing is. It’s not really the technology is it? To me at least it’s rather the endless sea of useless “look at me” blog posts that inevitably follows popular technologies.
React is great until you have non-trivial state management then life starts to suck again.
The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time.
It is funny because Redux's religious adherence to a const store makes no sense. Sure it provides a cool debugging trick where you can rewind things, but other than that it seems to just provide an endless hole of performance issues with people using the spread operator incorrectly.
C# and Winforms lets me pump out CRUD apps at literally 20x the speed I can in React. What takes me a day in Winforms can take a month in React. Wish I was kidding there. I once prototyped a website in Winforms, less than day.
I spent 3 days getting a date time picker working across all browsers desktop and mobile with accessibility support working. (Only because Safari doesn't support datetime pickers....)
Web dev sucks compared to desktop development. Hell Java + Swing had higher developer productivity than web dev.
> React is great until you have non-trivial state management then life starts to suck again.
I agree. This is a bit where the lack of frontend seniority tend to show it's colors in my opinion. People try to fit every use case onto e.g. Redux (or the even less competent useState) and then try to throw middleware at it to solve all of the complexity they're drowning in.
Frontend really should utilize more powerful state management tools (when necessary of course), e.g. Observables or Finite State Machines. We're using hammers to solve problems that require screwdrivers.
I found MobX working wonders for React UI responsiveness. You can cut-off large parts of rerendering more-less for free, without worrying you'll cut-off too much.
I just wish MobX was statically typed, so I could know what has been observed by just looking at the usage site, instead of hunting for where the corresponding makeObservable is.
> Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework.
Yep, it builds HTML on the server side and sends it to the browser through normal get requests. Instead of constructing HTML in a mix of JS + HTML (JSX) you typically write a mix of Ruby + HTML called ERB.
Doesn't Ruby also have an HTML-over-websocket library that Basecamp built for Hey and released open source? (at least a year or two ago they said they would release it) This would be similar to Elixir's LiveView I think.
Yep, it's like every other MVC or server side framework. You can still send client side JS for interactivity, and these days there are small jquery-like micro frameworks like petite-vue, alpinejs, stimulus, etc. that are made to sprinkle in interactions where necessary. If you want the smooth SPA-like experience there are systems like hotwire or htmx which effectively hide all the page reloading.
I’ve never used rails, but you can actually write code that runs in the browser on the front end, in Ruby? Or is it more of a server rendering technique.
You can write HTML that includes javascript (bundled with all kinds of JS libraries if you need). But you aren't writing ruby code that turns into something that directly executes in the browser.
Although with WASM I'm sure you could write ruby that also runs in the browser (no one really does this AFAIK).
Language X is better than language Y is blog posts are incredibly boring. No one actually cares what the author thinks - Rails devs will agree, JS devs will disagree, and no one else will care. But there's a great lesson here nonetheless.
When you're running a startup, and you're at that critical stage after launching when you're trying to get traction, getting people to see you exist is key.
reviewbunny sells a service for developers who want to get an email digest of their pending PRs at the end of the day. The notification emails that Github and Gitlab send aren't particularly clear, and setting up mail rules to mark them as important doesn't work for everyone, especially if you're working on multiple projects at once. So the author set out to make a product to solve that pain point. Writing a controversial blog post has got them to the top of HN's front page, which is awesome, and if the graph at the bottom of the homepage is correct it's won them 2 new organisations and a few new users since the article was posted. Amazing stuff. That's exactly what founders should be doing.
Maybe if it was a little less controversial those numbers would be higher, but there's no way to tell. Nevertheless, this is a fine example of 'content marketing' in my opinion. Well played. And I say that as a JS dev. :)
In a strange way the adoption of JS SPA's has made the "thinking-not-required" backend frameworks like Rails and Django less "opinionated" and thus requiring more thinking.
I don't know about the Ruby/Rails ecosystem but in Django there are now quite a few different ways to deliver the "same" user functionality depending on how much one splits the load between front / backend, whether and how much it is structured around DRF etc.
Basically the author reduced himself with Rails happily to a subset of the options, yet does not want do it in the JS world. The question is why? In my experience it's fear. Fear of somebody coming along and criticizing him for using X instead of Y, for not using the shiny new Z, fear of basically feeling inadequate.
So get over it. The task of a developer is to make something useful. The users don't care about technology unless it's something that improves their life. They don't care about your SPA or not, and they especially don't care about the package manager your project uses.
If Ruby helps you do that, go for it, but otherwise just let go snd do things. Somebody will always nitpick.
[1] https://trends.google.com/trends/explore?cat=31&date=today%2...