Live data from Hacker News

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

reviewbunny.app

131–140 of 490 posts

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

#131

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…

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.

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

#132
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.

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

#133

Earlier quoted context omitted.

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…

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.

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

#134
post #102

Earlier quoted context omitted.

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…

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

Last I looked the rails like JS framework was https://adonisjs.com/

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

#135

Earlier quoted context omitted.

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…

Remix feels a bit like Ember routing, but with SSR and React.

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

#136
post #121

Earlier quoted context omitted.

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…

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * whi…

Great questions. 3 years from now you will have completely different answers.

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

#137

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…

I can build SPA-s on my own. Based on your assessment, should I ask for infinite salary since my work is Google scale?

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

#138

Earlier quoted context omitted.

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…

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

Yeah it feels like this NextJS opinion is very out of date.

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

#139
post #74

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.

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

#140
post #88

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.

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.

No, a lot of SPAs don't use WebSockets at all, they just use xhr requests.
Post reply on HN