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

171–180 of 490 posts

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

#171

Post by taylorwc »

coffeefirst wrote: post #28
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…

Sure. And I think what makes Rails and Django shine is they have sound default answers. I’ve yet to see anything in Node that feels like a stable 1:1 replacement. Next.js is excellent, but you still need to sort out a lot of pieces on your own.

Definitely some exciting stuff like Redwood and Wasp working to solve these problems. I always loved what Meteor tried to do for this, though the JS ecosystem sort of evolved in a different direction.

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

#172

Post by dimgl »

realusername wrote: post #143
brabel wrote: post #121

Earlier quoted context omitted.

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.

This is a pretty huge assumption.

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

#174

Post by 1_player »

Oddskar wrote: post #167
brabel wrote: post #121

Earlier quoted context omitted.

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…

The answers to this in 2022: 1. Doesn't matter so much as long as you're using newest versions of either one. Newest yarn has plugin support which is neat. Npm has more stable backing and an open roadmap. Could be some considerations regarding monorepo support, but otherwise either is fine. 2. Yes 3. Use ES6 modules 4. Jest + Cypress 5. Vite

* Note: this is only valid for the time of writing. We cannot guarantee these libraries will still represent the state of the art past this date.

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

#177

Post by valenaut »

brabel wrote: post #121
1_player wrote: post #69

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…

This really hits home for another JS outsider that likes the language but not the ecosystem. I like to do small personal projects in Node. Simple things like consuming the Google Sheets API feel great, but when I want to expand the scope of the project and start thinking about tests, caching, and "am I doing my modules/imports/package management the RIGHT way" I usually give up or switch to a different stack.

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

#178

Post by jeremyjh »

pphysch wrote: post #111

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…

Yeah. I've done the server-side thing quite a lot. I don't like it. You always end up with "little bits" of javascript code strewn about in your DOM doing adhoc manipulations based on user events, server data arriving etc., and so the actual behaviour of your app is more difficult to reason about. Also, I want my users to have a nice experience and enjoy using the app, even if I don't have a KPI to represent that benefit. And until quite recently that was much easier to do in a modern SPA framework. I think the newer hybrid approaches like Phoenix LiveView give you the best of both worlds though.

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

#179

Post by jrockway »

pphysch wrote: post #146
bauerd wrote: post #131

Earlier quoted context omitted.

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.

On whatever page you're using websockets, you're basically doing what an SPA does. If you click something and the page sends and receives a message via websockets and then updates the DOM, congratulations, you have something that's the same level of complexity as a SPA.

Your original post says that this style of interaction only exists to "fleece VCs". But it seems you're doing that, with an additional added layer of complexity on top (namely the server-rendered pages).

I'm guessing you implement the interactivity with tags or something in your html/template templates, skipping the pain of npm and bundlers. I'm not sure that's the hard part of SPAs, though. Just an annoying one. The hard part is synchronizing the state of the frontend and backend over a communications channel.

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

#180

Post by realusername »

dimgl wrote: post #172
realusername wrote: post #143

Earlier quoted context omitted.

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

This is a pretty huge assumption.

Anybody who had to maintain & keep up to date a large node codebase knows what I'm talking about. Testing is an afterthought at best and non-existent in a lot of packages. I'm not talking about the top packages of course, just the N+4 small packages you depend on.
Post reply on HN