Live data from Hacker News

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

reviewbunny.app

141–150 of 490 posts

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

#141
post #120

Earlier quoted context omitted.

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…

> Everything else is a given.

Would you please send a link that summarizes this "everything else"? Every time I take a look at JS ecosystem I get lost.

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

#142

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 mostly agree, but it's very nice for the x% of your application that is real-time interactive. In some cases, x is high, such as Figma.

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

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

> * which test framework? Mocha? Karma? Jest? Cypress?

Most of the dependencies you will install will have no tests at all anyways. This is another issue of its own, you are building on very weak foundations.

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

#144
post #102

Earlier quoted context omitted.

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/

When I last looked at Adonis I was really turned off, but I don't remember why. Looking again, it seems like the templating is a real weakness, but lots of the other things are nice.

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

#145
post #86

I enjoy building SPAs, but I often wonder if my joy comes from having built something, or is it just seeing the little virtual ball make it's way to the end of the overly-complex Rube Goldberg-like contraption of cloud services, NPM packages, bundlers and frameworks my product is built upon.

I think the healthy part in the SPA workflow is that you can focus on one thing at a time by design. If the whole app is backend driven, everything is tangled and I might be tempted to fix everything at once.

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

#146
post #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.

Yes, I have. With a proper backend language like Go it is trivial to manage concurrent WebSockets and arbitrary data across them.

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

#147
The title refers to SPAs, a frontend technology. But most of the identified pain points are not about SPAs at all. Well okay maybe the first two or three, but they’re very superficial.

Instead, this is more about serverless vs. “classic backend”.

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

#148

Earlier quoted context omitted.

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

I've spoken about my dislike of next.js a few times, and it's mostly centered around its documentation. It is decent, but it is no way as complete as an established framework like Django. Have you ever compared the depth of the two? I'm on mobile, just read and compare, I don't know, the routing API docs for both.

Also the APIs are very simplistic, I haven't used it in the past few months when I quit my job, but I vividly recall how anything outside of the simple examples it provides were an exercise in frustration and digging into Github Issues and its source code. The whole data fetching system is so incredibly convoluted if you're doing a little more than static pages or build-time rendering. getInitialProps, getServerSideProps, getStaticProps, hooks, etc., all with their own caveats and performance considerations.

Next might be one of the better JS frameworks but it's laughably bad compared to Django, Rails, Phoenix.

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

#149

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?

You can also deploy Hadoop on your own, or write platform-specific assembly on your own, but the question remains: is it worth it?

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

#150

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…

This comment should be printed and put up on quite a few teams' wall.
Post reply on HN