This resonates a lot! I've always considered myself a general software engineer (mostly doing algorithms and ML in uni), but then moved to industry and for every project needed to get into web. Over last 10 years I went through php, Java and Node on the backend and jquery/angular/react on the frontend. I understand and appreciate why and how these technologies developed, but it still felt I had to do a lot of re-learning to catch-up with the latest stack and build the similar thing all over again.
Don't make me think, or why I switched to Rails from JavaScript SPAs
191–200 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#192Google searches for React and node.js exceed searches for Ruby on Rails by 100% and 50%, respectively [1]. Some people have used this to argue that React/node are more popular than Rails. But I wonder if perhaps this discrepancy appears in Google Trends because it takes more google searches to accomplish the same thing in React/node versus Rails. I feel the Rails ethos of "convention over configuration" allows me to accomplish the same objective with less googling.
[1] https://trends.google.com/trends/explore?cat=31&date=today%2...
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#193I 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…
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…
If you are creating a rich web app, you still have to deal with all of this when generating HTML+JS in another language.
Rails doesn't save you from any of this, none of the back end frameworks do. I prefer writing SPAs because if I prefer to be directly authoring my HTML+JS instead of authoring it indirectly through a framework in a different language.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#194Earlier 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…
> 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. Do people believe this about Angular? Not primarily a front end dev, but in my limited experience with React and Angular, it seems like Angular's strength is that it provides more structure for scaling to larger projects.
Honestly Angular is great even for startups. With the current state of the the framework and the way the Angular CLI bundles code, it's pretty hard to break 90 on PageSpeed Insights (at least without pre-rendering). But it's also not that difficult to get in the high 80s, which is pretty good for a SPA. And it should only be getting more performant as they put more working into optimizing it.
It's easy to learn, the code is super clean, TypeScript is great, and imo it generally just makes for a good work environment.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#195I 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…
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…
"Javascript has such a minimal standard library"
My hope is that this has been/will continue to change over time, is this a fare statement? Does anyone know if the various working groups (e.g., WHATWG, W3C, etc.) have the goal of making the JavaScript more robust?
My vision is that the standard, built-in APIs would serve as a minimum viable platform that you can build simple to moderately complex applications in with only "minimal" external dependencies.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#196Seems like an "all or nothing" mentality. You either do it all in Javascript (both the frontend and backend) or you do it all in Rails.
Why not do the backend in Rails and the frontend in Javascript/SPA?
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#197Am 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.
I've interviewed a lot of web devs over the years. The distribution on this question is surprisingly bimodal. One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it. The other group of web devs has learned one very specific tool and they want to build their career around that to…
Have you noticed a difference depending on when they got into web development/whether they trained for it?
One thing I'm noticing as I'm looking for tech jobs as a tech person who hasn't ever been a tech employee before is that a lot of the job listings are very heavily tool focused. I wonder if newer/junior devs are reacting to what the market is presenting (as you hinted at with 'The more complex they can make something, the better they think it will look on their resume').
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#198The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#199I 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.
Do most people use Django as a server-side framework (no frontend-JS or very minimal JS, may be jQuery)? Or, is it mostly used as an API to interact with the React/Angular/etc front-end framework? What I am trying to get at is do people still build POST-redirect-GET patterns and such for form submissions or they use Django in a more 'modern' way?
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#200The 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”.
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.