React Developer Chooses Rails, Sparking JavaScript Debate

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

In the post, Demedes recounts his recent experience in choosing Rubies on rails instead of using its normal go-to, a React based single page request framework. He marveled that he “didn’t procrastinate on figuring out the perfect setup or choose dependencies”, but rather “procrastinate after finishing the MVP”, adding “I’d rather do the latter!”

The problem, he writes, is that when starting out with a new JavaScript application, it has to make way too many decisions just to get started, from which package manager to use to which framework, to which database, authentication, data recovery, etc to.

In contrast, writes Demedes, “As soon as I use new rails, I have all that.” Now, it doesn’t seem that Demedes is claiming that we are throwing the baby out with the bathwater, but rather that many JavaScript frameworks need help in this area. He suggests “stronger opinions and conventions to save us from making unnecessary choices” and “less setup and manual labor to start working on anything”.

“In my opinion, this is exactly what we JavaScript developers need most when building apps. Until we have more guidance and conventions, we’ll continue to spend a week to implement the perfect app template designed to “scale”. I’m still very invested in the 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 far to find a bit of disagreement, with many saying this is more of a problem with React than the JavaScript ecosystem as a whole.

the comments on Hacker News similarly, pan out to expand the problem from a narrow problem with a singular framework to something that takes up the entirety of JavaScript.

A commentator, for example, argue that “If you compare Rails to something like Nest.js, you’re not missing much. Nest is one of the best application frameworks I’ve used in any language, and it comes with everything you say JS doesn’t have.

Various frameworks and tools – Angular, Blitz.js, Remix – also make their way into the conversation, but yet another the commentator supports that it really all comes down to one thing: doing something quickly and simply, as the title of Demede’s blog mentions.

“I think the author has gone into too much detail here, because this crowd is full of people who are going to be able to tear pieces of this article to shreds. But that both misses the most important point and proves it in process – Rails gave them a set of answers good enough that they didn’t need to drill down and could just focus on their application,” they write. done. And people with broader skill sets can put together their own solutions and might not want to anyway. But this author just wanted to pick a platform and move on, and yes, Rails works for that .

This week in programming

  • The argument for WebAssembly: WebAssembly might just be that thing you’ve heard of in passing, or something you’ve even read a little about, but an article made the rounds this week that claims it’s time to pay attention to WebAssembly, and it is worth reading. The subject WebAssembly comes up more and more in my own interviews, and most recently, the CEO of Vercel Guillermo Rauch told me that JavaScript developers should pay special attention to the “very awesome but nascent [WebAssembly] ecosystem”, where he sees that JavaScript has an advantage. As for this article, it claims that “WebAssembly is at an inflection point” and that there will be “increased adoption of WebAssembly in the technology sphere, from containerization to plugin systems to computing platforms serverless” over the next few years. There’s just too much to recap here, but it’s good to recap where WebAssembly excels, where it’s already best used, and where it’s potentially headed next. Already, WebAssembly powers things like Amazon Video Prime, Disney+and the BBC, among many others. Although the author concedes that it still lacks maturity, he writes that “many of these issues are being actively worked on and will likely reach an acceptable state within a year or two. As such, it appears we are at the edge of an explosion of 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 on from the first beta, which the team said was “the most downloaded Go beta of all time, with twice as many downloads as any previous version” . It comes with generic support in both gopls and the VS Code Go extension. In addition to the long-awaited generic feature, Go 1.18 introduced fuzzy and the new Switch to workspace mode. After putting the first beta to the test, the team also writes that it “also proved to be very reliable; in fact, we’re already running it in production at Google. Nevertheless, Beta 2 is here to make sure everything is fine, as Beta 1 uncovered some “obscure bugs in the new generics support.” The release candidate is also expected later this month, with the final release of Go 1.18 slated for March. And while we’re talking about Go 1.18, Go AWK creative performer Ben Hoyt decided to take a look at Upgrade performance from 1.2 to 1.18 using its own tool’s performance “when compiled using every released version of Go from 1.2 (the first version I was able to download) to 1.18 (which is currently in beta)”. As you might expect (or rather hope), Go has picked up the pace compared to recent releases. “Overall count words are now about 5x faster than with Go 1.2, and sumloop is 14x faster! (Although I first released GoAWK when Go was already at the version 1.11, so it wasn’t there 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 work. :-)”
  • GitHub gets sponsor-only repositories: Developers looking for a little financial support in their open source endeavors have a new tool under their belt this week, with the release of GitHub’s new standards reserved for sponsors. The feature allows developers to attach a private repository to each of their sponsorship levels, much like giveaways for donation levels 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 repositories before they are open source. Along with sponsor-only repositories, GitHub has also added support for custom referral amounts, the ability to include sales tax, custom referral messages based on tier, and metadata to help determine what attracts. new sponsors. As for what’s next, GitHub says it’s 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 grow their audience, community and overall funding.”
  • An update on asynchronous rust: For those of you keeping an eye on the evolution of asynchronous I/O in Rust, the Async Working Group has offered a small update on Asynchronous rust in 2022. Having already written shared asynchronous vision document, the group now says that they are “moving towards the realization of this vision”. They offer a hypothetical anecdote of a Rust developer who, in 2024, happily pulls out his Rust guide and gets down to coding, which contrasts with the current state of affairs, where there is “a lot of work still to be done in terms of RFCing and implementing the features that will allow us to write the code we talked about. To learn more about where they are in this process, go and read the blog post, or check out the roadmap. Heck, if you’re really into it, you can too lend a hand.

Comments are closed.