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…
Don't make me think, or why I switched to Rails from JavaScript SPAs
131–140 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#132* 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
#133Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#134Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#135Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#136Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#137SPAs 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#138Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#139It'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.
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
#140Am 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.