Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't make me think, or why I switched to Rails from JavaScript SPAs

reviewbunny.app

Post reply on HN
Print view View original

111–120 of 490 posts

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#111

Post by pphysch »

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.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#112

Post by bdcravens »

katzgrau wrote: post #2

I mostly work in Rails, but when I have to hop into a node project, it feels like I'm stepping back into PHP in terms of sheer madness. Barely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.

I find you have to create your own structure (in almost every instance, I drift back towards MVC, though it's generally hand-rolled)

Express isn't terrible; it's just more like Sinatra.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#113

Post by sam0x17 »

horsawlarway wrote: post #63
chrisan wrote: post #38

Earlier quoted context omitted.

as a former Rails user now Laravel user, I would agree with this. PHP has mage huge strides in typing too, I havent kept up with Ruby to know if they do the same

No - typing is still basically a complete after-thought in Rails. Sorbet is trying, but it's... not there yet (although getting better).

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.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#114

Post by dnfa »

jack_riminton wrote: post #85

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!

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#115

Post by sam0x17 »

sinsterizme wrote: post #49
chrisan wrote: post #38

Earlier quoted context omitted.

as a former Rails user now Laravel user, I would agree with this. PHP has mage huge strides in typing too, I havent kept up with Ruby to know if they do the same

Unfortunately Ruby's typing story is abysmal. I hope they manage to improve it soon, otherwise I fear the language will continue to flounder

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.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#116

Post by bdcravens »

impostervt wrote: post #105

All frameworks are great, until you need to do something non-standard, and then you'll spend a large amount of time fighting the framework. The more "standard" the product you're building, the better off you'll be choosing a framework that is highly structured.

Very few apps don't have a framework. The issue is whether you built it yourself.

Also, "non-standard" apps are far less common than we would like to think. There's only so many potential ways to reinvent wheels.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#117

Post by ajmurmann »

1_player wrote: post #69
codingdave wrote: post #7

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 se…

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 f…

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.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#118

Post by fernandotakai »

tylergetsay wrote: post #76

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.

"use the right tool for the job"

most apps don't need to be SPAs -- they could be normal HTML templates with a sprinkle of JS on top to make it more "dynamic".

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#119

Post by sam0x17 »

codingdave wrote: post #7

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 se…

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.

Re: Don't make me think, or why I switched to Rails from JavaScript SPAs

#120

Post by dntrkv »

franga2000 wrote: post #96
dntrkv wrote: post #75

Earlier quoted context omitted.

> 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…

I'll pick just one point to address: > 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.

Post reply on HN