3 ms·

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 t

by fuzzy2 5y ago

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

jillesvangurp 5y ago
I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views. Rails is basically optimized for server-side model view controller with HTML views rendered server side and served to a browser. SPAs, mobile, and desktop applications typically have their own client side model view controller type frameworks; so server side views are not that relevant for those. Any frontend browser project I've dealt with in the last ten years or so was a basically a SPA. A third variant exists in the form of server side views rendered using client side technology. Some people actually do e.g. server side react in order to limit client side processing. This is less common but perfectly valid. Back in the day, you'd use server side includes or similar technology. So, it's nothing new but popular for some things. Usually node.js is used for this but I've also seen this done via Java & Spring, which wasn't much fun for our frontend developers but still worked. I'm not a fan of either Rails or Javascript server side. I've done both but it's just not my preferred stack. Ruby code bases I've dealt with were messy, over engineered, and underwhelming in terms of performance. It's been a while since I had to deal with that since it seems to have gone out of fashion. Most node.js stuff I've dealt with looks like it's fine for small projects but it gets messy quickly if you scale up. Typescript helps but I'd probably reach for other techstacks. The point is, you have choice and there is a lot of specialized stuff out there and no technical need to use anything js on the server. My pet theory is that many frontend developers get into server development via node.js and then discover something better like Go, Rust, or whatever. I've seen some of my younger friends and colleagues go through this process a couple of times. My preferred server-side stack is Kotlin currently. There are several good server frameworks for it. I'm very familiar with Spring but have also used Quarkus and Ktor. Kotlin makes these a lot nicer to use.
- fuzzy2 5y ago
  > I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views. Hm, no, sorry, I complete disagree. TFA is complaining about some choice. It is indeed related to the frontend. Then goes on to complain about project structure, databases, API design patterns/technology, authentication, scheduled jobs (really?), email templates (just trolling at this point) and Websockets. What? Sorry. No. This article isn’t about stateful client applications. Or client applications. It isn’t even about server-side rendering. It is about backend (and its backend), and nothing but. SPAs are not backend. TFA most certainly isn’t about about server-side JavaScript. It’s only about “serverless”. Whatever that may be.

by fuzzy2 5y ago

jillesvangurp 5y ago

I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views. Rails is basically optimized for server-side model view controller with HTML views rendered server side and served to a browser. SPAs, mobile, and desktop applications typically have their own client side model view controller type frameworks; so server side views are not that relevant for those. Any frontend browser project I've dealt with in the last ten years or so was a basically a SPA. A third variant exists in the form of server side views rendered using client side technology. Some people actually do e.g. server side react in order to limit client side processing. This is less common but perfectly valid. Back in the day, you'd use server side includes or similar technology. So, it's nothing new but popular for some things. Usually node.js is used for this but I've also seen this done via Java & Spring, which wasn't much fun for our frontend developers but still worked. I'm not a fan of either Rails or Javascript server side. I've done both but it's just not my preferred stack. Ruby code bases I've dealt with were messy, over engineered, and underwhelming in terms of performance. It's been a while since I had to deal with that since it seems to have gone out of fashion. Most node.js stuff I've dealt with looks like it's fine for small projects but it gets messy quickly if you scale up. Typescript helps but I'd probably reach for other techstacks. The point is, you have choice and there is a lot of specialized stuff out there and no technical need to use anything js on the server. My pet theory is that many frontend developers get into server development via node.js and then discover something better like Go, Rust, or whatever. I've seen some of my younger friends and colleagues go through this process a couple of times. My preferred server-side stack is Kotlin currently. There are several good server frameworks for it. I'm very familiar with Spring but have also used Quarkus and Ktor. Kotlin makes these a lot nicer to use.

fuzzy2 5y ago
> I would say it is more about having stateful client applications that implement some kind of client side model view controller and uses some kind of remote API vs. the traditional server applications that generated HTML views. Hm, no, sorry, I complete disagree. TFA is complaining about some choice. It is indeed related to the frontend. Then goes on to complain about project structure, databases, API design patterns/technology, authentication, scheduled jobs (really?), email templates (just trolling at this point) and Websockets. What? Sorry. No. This article isn’t about stateful client applications. Or client applications. It isn’t even about server-side rendering. It is about backend (and its backend), and nothing but. SPAs are not backend. TFA most certainly isn’t about about server-side JavaScript. It’s only about “serverless”. Whatever that may be.