A React Developer Chooses Rails, Igniting JavaScript Debate – InApps Technology

What better way to end the work week than with a debate over using one technology over another? This week, the debate came in the form of a blog post by developer Vadim Demedes, who wrote about “why I switched to Rails from JavaScript SPAs.”

In the post, Demedes relates his recent experience in choosing Ruby on Rails instead of using his normal go-to, a React-based single-page application framework. He marveled that he “didn’t procrastinate determining the perfect setup or choosing dependencies,” but instead “procrastinated after having finished the MVP,” adding “I’d rather do the latter!”

The issue, he writes, is that when starting with a new JavaScript app, he has to make far too many decisions just to get started, from which package manager to use to which framework, to which database, authentication, data fetching, and so on.

By contrast, writes Demedes, “As soon as I run rails new, I’ve got all of that.” Now, it doesn’t appear that Demedes is arguing that we throw the baby out with the bathwater, but rather that many JavaScript frameworks need some help in this realm. He suggests “more strong opinions and conventions to relieve us from making unnecessary choices” and “less configuration and manual labor to start working on anything.”

“In my opinion, that’s exactly what we, JavaScript developers, need more of when creating apps. Until we have more guidance and conventions, we’ll keep spending a week to set up the perfect app boilerplate built to ‘scale’. I’m still very much invested in JavaScript community, but for now I’m going to stick with Rails and enjoy building web apps,” he concludes.

Now, you don’t have to go very far to find a bit of disagreement, with many arguing that this is more of a problem with React than with the JavaScript ecosystem as a whole.

The comments on Hacker News similarly pan the piece for expanding the problem from a narrow one with a singular framework to something that takes on the entirety of JavaScript.

One commenter, for example, argues that “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.”

Various frameworks and tools — Angular, Blitz.js, Remix — also make their way into the conversation, but yet another commenter argues that it all really boils down to one thing: getting something done quickly and simply, as alluded to in Demede’s blog post title.

“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,” they write. “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.”

This Week in Programming

• The Argument for WebAssembly: WebAssembly might just be this thing you’ve heard of in passing, or something you’ve even read a little bit about, but an article made the rounds this week that argues that it’s time to pay attention to WebAssembly, and it’s well worth the read. The WebAssembly topic has been popping up increasingly in my own interviews, and just recently, Vercel CEO Guillermo Rauch told me that JavaScript developers should be paying close attention to the “very awesome but nascent [WebAssembly] ecosystem,” where he sees JavaScript having an edge. As for this article, it argues that “WebAssembly is at an inflection point” and that there will be “increased adoption of WebAssembly across the tech sphere, from containerization to plugin systems to serverless computing platforms” over the next few years. There’s simply too much to recap here, but it does well to summarize where WebAssembly excels, where it’s best used already, and where it’s potentially headed next. Already, WebAssembly powers things like Amazon’s Video Prime, Disney+, and the BBC, among many others. While the author concedes that it is still lacking maturity, they write that “many of these issues are being actively worked on and will probably reach an acceptable state within the next year or two. As such, it seems we’re on the brink of an explosion in WebAssembly activity, ecosystem, and community.”

• Go’s Most Popular Beta Gets a Sequel: The second beta of Go 1.18 was released this week, following up the first beta, which the team writes was “the most downloaded Go beta ever, with twice as many downloads as any previous release.” With it comes support for generics in both gopls and the VS Code Go extension. In addition to the long-awaited generics feature, Go 1.18 introduces fuzzing and the new Go workspace mode. Having put the first beta through its paces, the team also writes that it “has also proved very reliable; in fact, we are already running it in production here at Google.” Nonetheless, Beta 2 is here to make sure everything is good, as Beta 1 uncovered some “obscure bugs in the new support for generics”. The release candidate is also expected later this month, with the final Go 1.18 release slated for March. And while we’re talking about Go 1.18, Go AWK interpreter creator Ben Hoyt decided to take a look at Go performance from version 1.2 to 1.18 using the performance of his own tool “when compiled using each released version of Go from 1.2 (the earliest version I could download) to 1.18 (which is in beta now).” As you might expect (or hope, rather), Go has picked up the pace over recent versions. “Overall, countwords is now about 5x as fast as it would have been with Go 1.2, and sumloop is 14x as fast! (Though I first released GoAWK when Go was already at version 1.11, so it wasn’t around for the huge early gains.),” Hoyt writes. “For an actively-developed compiler like Go, it’s cool to be able to get performance improvements just by waiting and letting others do all the hard work. :-)”

• GitHub Gets Sponsors-Only Repos: Developers looking for a bit of financial support in their open source endeavors have a new tool in their belt this week, with the release of GitHub’s new sponsors-only repositories. The feature allows developers to attach a private repository to each of their sponsorship tiers, much like gifts for donation tiers on Kickstarter. GitHub offers a few potential use cases, such as “sponsorware”, or repositories available only to your sponsors, or giving sponsors early access to repos before they are open sourced. Alongside sponsors-only repos, GitHub also added support for custom sponsorship amounts, the ability to include sales tax, custom sponsorship messages according to tier, and metadata to help determine what brings in new sponsors. As for what’s coming next, GitHub says it is working “to improve the discovery experience on GitHub, making it easier for the community to explore dependencies and decide who to support, and helping maintainers who use Sponsors to grow their audience, community, and overall funding.”
• An Update on Asynchronous Rust: For those of you keeping an eye on the evolution of Async I/O in Rust, the Async Working Group has offered a bit of an update on Async Rust in 2022. Having previously written a shared async vision document, the group now says that they “are making towards realizing that vision.” They offer up a hypothetical anecdote of a Rust developer who, in the year 2024, happily pulls out their Rust guide and gets to coding, which contrasts with the current state of affairs, where there is “a lot of work to do yet in terms of RFCing and implementing the features that will let us write the code we talked about.” To find out more about where they are in that process, head on over and give the blog post a read, or check out the roadmap page. Heck, if you’re really into it, you could also lend a helping hand.