15 ms·

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

• rosgoo 5y ago
  I think https://blitzjs.com/ https://blitzjs.com/ exactly tries to bring Ruby on Rails convenience to js apps and makes all the decisions for you.
  • vdemedes 5y ago
    I haven't tried it myself yet, but I'm definitely looking forward to once they complete the pivot (see https://blitzjs.com/docs/blitz-pivot https://blitzjs.com/docs/blitz-pivot).
• xdxfw 5y ago
  If you like ruby, please give https://matestack.io/ https://matestack.io/ a try
• vehemenz 5y ago
  It is apples and oranges, but I think that's kind of the point. Unlike Rails or even PHP, the JavaScript ecosystem is all over the place. If you choose the most popular tools available, there are many decisions to make. Not everyone wants to do devops.
• streamofdigits 5y ago
  In a strange way the adoption of JS SPA's has made the "thinking-not-required" backend frameworks like Rails and Django less "opinionated" and thus requiring more thinking. I don't know about the Ruby/Rails ecosystem but in Django there are now quite a few different ways to deliver the "same" user functionality depending on how much one splits the load between front / backend, whether and how much it is structured around DRF etc.
• adrianthedev 5y ago
  And now you have Avo too (shameless plug). Half of the app is built for you. https://avo.cool https://avo.cool
• pavelevst 5y ago
  If stay away from serverless, cloud databases and “doing everything on frontend”, then it solves most of problems mentioned in article But rails and ruby still has many good parts. For example global classes and ruby threads to save per request context.
• phtrivier 5y ago
  Rails after more than a decade of development has a head start over react with about half a decade. Also, it's comparing spas and server side, which, suprise, is not the same thing. 'rails new' should be compared to 'create-react-app' - it's just not official _yet_
• lominming 5y ago
  It has been >7 years since I used RoR for a complex web app. The problem is not configuration vs convention. The problem I had was when I needed dynamic front end functionality for the user (drag and drop, no-refresh edits, etc.) I ended up needing to use another framework/library on the front end too (at that time it was Backbone). Has that been changed/improved? Or RoR is still primarily used to build server side rendering (SSR) web apps?
• HeavyStorm 5y ago
  Completely agree. I'm not a Rails person (just because I've never had a reason to learn Rails), but I'm a .Net fan. And oh boy how easy it is to create an app with it. On the back end, I pretty much doubt there's anything better. On the front, Razor is great.
• KingOfCoders 5y ago
  My 5ct https://www.radicalsimpli.city/ https://www.radicalsimpli.city/
• mohitgangrade 5y ago
  I would say this is an oversimplification. I like the choices I get when building with JavaScript. There's always something new to learn and I get to pick the flavors that I like to work with. :) But I do envy the simplicity of Ruby on Rails. I might try it for my next project after reading this article.
• BilalBudhani 5y ago
  this remind of a great article written by DHH https://dhh.dk/2012/rails-is-omakase.html https://dhh.dk/2012/rails-is-omakase.html > Rails is omakase. A team of chefs picked out the ingredients, designed the APIs, and arranged the order of consumption on your behalf according to their idea of what would make for a tasty full-stack framework.
• tapvt 5y ago
  Perhaps I missed it, but the single biggest reason that I moved away from SPAs (such as React) and back to server-side rendering of templates is avoiding having to model my data twice. That’s a lot of overhead. Granted, I’m in the B2B software space, so end-user expectations are those of accuracy, consistency and performance. I imagine expectations (or perhaps priorities) are different for consumer-facing applications.
  • continuational 5y ago
    There are a lot of solutions out there where you can share your datatypes between the client and server now though, and it's great!
    • khalilravanna 5y ago
      This comment would be more helpful with some examples. I’m personally very curious what the leading solutions are. I’ve worked with one involving GraphQL but that’s about it.
      • S04dKHzrKT 5y ago
        I can't speak to leading solutions, but in the .net world, there's Blazor[0] which is C# for the whole stack. There's also Fable[1] which is F# the whole way down. [0]: https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blazor https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz... [1]: https://fable.io/ https://fable.io/
        • merb 5y ago
          you forgot: Reinforced.Typings. btw. most of the time I wish my company used such things or that code would be more isomorphic, BUT!!! most of the time isomorphic models lead to way more problem, especially when it comes to validation.
      • wlamartin 5y ago
        tRPC is a good choice for TypeScript: https://trpc.io/ https://trpc.io/
• synergy20 5y ago
  read quite some articles like switching from SPAs to rails|django|laravel, basically from the new cool kid back to the old man in the backyard. but, what about using Go with its web frameworks(e.g. Gin), it has everything you need to build a web application, and it could be all in one binary, and if you want to scale it's not hard too.
  • pak9rabid 5y ago
    We use Go for our backend that has to run on embedded systems. For running a basic REST API, it works great and is extremely lightweight.
• throwawaynay 5y ago
  Hey Vadim, how experienced with rails were you before starting reviewbunny? Would you advise a JS dev(with no prior experience with Rails) who wants to launch multiples MVPs to switch to Rails? Thanks
• 5350-uiop-1130 5y ago
  6 months later: why I switched from Rails to [insert framework]
• pphysch 5y ago
  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 and companies. SPAs are not designed for developer productivity, they are designed by BigCo that can spend 0.01% of their revenue to hire multiple teams/ICs to squeeze out a +0.1% increase in revenue. It's comparable to doing microarchitecture-specific optimizations for your clientside website code. Totally irrelevant to your side project or startup. Pick a productive stack/framework and build out your product with a solid foundation. You can always bolt on websocket-based features as required. Maybe rewrite your frontend in a SPA framework once you hit $100mm revenue.
  • funklute 5y ago
    > SPAs are not designed for developer productivity Unless your app is big enough to have separate developers/teams for backend and frontend. In this case I'm relatively convinced by the argument that it allows you to decouple the two, so that all they need to agree on is the API. Do you disagree? If so, how come?
  • bauerd 5y ago
    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.
    • YuukiRey 5y ago
      I don't think anyone would take fault with using a SPA for a text editor. What most people are criticizing is using a SPA for a page that serves mostly non-interactive content. And that is the majority of the web, after all.
    • pphysch 5y ago
      Yes, I have. With a proper backend language like Go it is trivial to manage concurrent WebSockets and arbitrary data across them.
• whoisthemachine 5y ago
  I agree with the author's core assertion that throwing too many decisions at a project right away makes it difficult to even get started. It increases the risk of hitting analysis paralysis right away. I've rarely worked with Rails, but when I did, I really enjoyed its approach to sensible defaults, easily overridden if needed. I hope that's still available, and I think other frameworks benefit from following that approach.
• avidphantasm 5y ago
  The lack of opinions in JavaScript frameworks (esp. React) is what keeps me away and using old boring things like Django. I am not a full-time web developer, and don't have time to follow the latest states of the galaxy of tools needed to build a web application. I am hoping that SvelteKit is the next boring tool that will offer an alternate way forward that is worth my time learning (once it stabilizes a bit).
• samlambert 5y ago
  I'd like to clarify that you do not need any type of connection pooling or proxying in front of PlanetScale. We can handle a massive amount of connections unlike a lot of other DBs.
• bugeats 5y ago
  The `create-react-app` project has existed for years, and gives you a standardized stack the bundles and boots with a single command. Rails 7 has abandoned JS bundling in favor of using somebody else's CDN. Have fun with that.
  • mikebowman 5y ago
    > Rails 7 has abandoned JS bundling in favor of using somebody else's CDN. Have fun with that. This isn't true. You can vendor your JS libraries and Rails will bundle them for you. It uses jsbundling-rails[1] to handle that. https://youtu.be/mpWFrUwAN88?t=772 https://youtu.be/mpWFrUwAN88?t=772 [1]https://github.com/rails/jsbundling-rails https://github.com/rails/jsbundling-rails
• 3solarmasses 5y ago
  Rails is the reason Level Frames has been written and maintained by 1 developer for 7 years. https://www.levelframes.com/ https://www.levelframes.com/ Along with our artist platform, Dot Press: https://www.level.press/ https://www.level.press/ (same developer, me :)
• jb1991 5y ago
  The article makes a comparison to react, but that’s a front end library. Does rails also do front end?!
  • Oddskar 5y ago
    React is a client side framework (no, it's not a library even if they say it is), not an "app".
  • thatguyagain 5y ago
    Yes, Rails has a view layer (frontend).
    • jb1991 5y ago
      I’ve never used rails, but you can actually write code that runs in the browser on the front end, in Ruby? Or is it more of a server rendering technique.
      • qbasic_forever 5y ago
        You can write HTML that includes javascript (bundled with all kinds of JS libraries if you need). But you aren't writing ruby code that turns into something that directly executes in the browser. Although with WASM I'm sure you could write ruby that also runs in the browser (no one really does this AFAIK).
  • qbasic_forever 5y ago
    Yep, it builds HTML on the server side and sends it to the browser through normal get requests. Instead of constructing HTML in a mix of JS + HTML (JSX) you typically write a mix of Ruby + HTML called ERB.
    • jb1991 5y ago
      Doesn't Ruby also have an HTML-over-websocket library that Basecamp built for Hey and released open source? (at least a year or two ago they said they would release it) This would be similar to Elixir's LiveView I think.
• hk1337 5y ago
  Seems 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?
  • merb 5y ago
    you can also combine them.
• papito 5y ago
  I think this is more a revolt against unnecessary complexity, which I think is a discussion to be had. I am not solving drastically more difficult problems than I did twenty years ago, yet the amount of complexity, maintenance, and overhead is staggering. Why? Oh, because "that's how they do it at the FAANG". https://www.youtube.com/watch?v=y8OnoxKotPQ https://www.youtube.com/watch?v=y8OnoxKotPQ
• Zababa 5y ago
  I've been wondering about when to use something like a SPA and when to use something like Rails recently. My understanding is that the two are getting closer, with React getting stuff like Next with server-side rendering, backend functions and stuff like that, while Rails is getting Hotwire to make richer interfaces easier. My question is, how do you know when to choose which one? For example, I'm looking to build something that's in the "unbundling Excel" vein. The application will have lots of input from the users, and lots of graphs. It's supposed to be pretty interactive (once again to mimick Excel). And I'd like to build a SaaS out of it. What would you pick, and why? From what I understand a SPA would be better at the "heavy user interactions" part, and a regular MVC framework would be better at everything else. Maybe a combination of the two? But with limited development times, it seems like it would be slower to do that.
• duveloper 5y ago
  I think the author is looking for Angular + Firebase...
• ryanmarsh 5y ago
  I surprised how few people have mentioned Remix. It's very Rails like (don't make me think). Albeit, Rails makes you have to think even less, Remix is headed in the right direction.
• fareesh 5y ago
  Roll safe tapping head meme Can't switch to Rails if you never bought the SPA hype in the first place
• katzgrau 5y ago
  I mostly work in Rails, but when I have to hop into a node project, it feels like I'm stepping back into PHP in terms of sheer madness. Barely any convention, lots of repetition and configuration - all things Rails specifically set out to solve.
  • pearjuice 5y ago
    PHP hasn't been madness for a long time. One could argue Laravel (a RoR inspired framework) has become better than RoR.
    • deleted 5y ago
      [deleted]
    • Cthulhu_ 5y ago
      I mean, there have been plenty of valid arguments against PHP the language and its standard library, but the big issue most people end up having have to do with its ecosystem, developers, and frameworks. My earliest rants about PHP was the sheer volume of bad tutorials; googling for "php sql" or whatever would invariably give you examples susceptible to SQL injection. And the other issue was that everyone was building frameworks, CMSes and forum software left right and center; there were a lot of islands, each with their own ideas, structures, etc. PHP should have made a much bigger push early on; mark the weird and unsafe functions as deprecated and point to e.g. prepared statement alternatives. They should have built a package / dependency manager much earlier on. And they should have made a lot more efforts to get a developer community up and running.
      • stanmancan 5y ago
        If you're actually interested in the subject, a good way to familiarize yourself with the current state of PHP is to run through something like https://laracasts.com/series/laravel-8-from-scratch https://laracasts.com/series/laravel-8-from-scratch. It should give you a good idea of the current state of PHP, what educational resources look like, along with a taste of the most popular PHP framework out there. These conversations always tend to go the same way; someone complains about PHP and then later admits it's based on their experience 5-10+ years ago. PHP has come a long way and is worth checking out if you're into web development.
• lobstrosity420 5y ago
  I don't understand the comparisons presented in the article. Comparing a full stack MVC framework to a front end library is as apples to oranges as it gets. IMHO frameworks such as NestJS and Adonis are more comparable to Ruby on Rails.
  • antoineMoPa 5y ago
    I think you don't want to support the article's claims, but you kind of support it by mentionning the choice that you need to make between NestJS and Adonis or any other frameworks. With the ruby ecosystem, there is almost always a clear convention on what to do (example: the conventional choice is to use rails, which leads to a bunch of pre-made choices)
    • ta-run 5y ago
      Conventional choice at a framework level isn't really necessary though, is it? I mean, you can read and choose what you like whether it's Nest/Adonis/Blitz or anything else. Once that choice is made everything that follows is opinionated.
      • weatherlite 5y ago
        Part of the problem I think is that none of the JS frameworks became a clear winner in the full stack batteries included framework niche. For Ruby the clear winner is Rails. For Python it's Django. For C# it's .NET. What is it for Node then - I keep getting many names - Nest/Next/Adonis/Blitz/Sails? And lately Redwood? And probably more I'm missing out? It would have been better for Node if there were 1-2 frameworks with huge momentum behind them then 6-8 frameworks that none of them caught a lot of mindshare.
        • jack_riminton 5y ago
          I think there should be a RailsJS where they literally copy every convention of RoR
• gavinray 5y ago
  I used to write Rails professionally for many years This comparison isn't a good one. Rails is an all-encompasing framework. If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have. --- EDIT: To clarify (because it is confusingly named), NestJS is a framework modeled after Spring Boot for TypeScript + Node: https://nestjs.com/ https://nestjs.com/ Not to be confused with Next.js, which is a framework for building SSR React apps.
  • subpixel 5y ago
    I can't help but think it is a reflection of the JS ecosystem that I assumed you had misspelled Next.js
    • WolfOliver 5y ago
      I guess Nest.js is actually right: https://nestjs.com/ https://nestjs.com/ A TypeScript framework like Rails is a framework for Ruby.
      • scoot 5y ago
        > I guess Nest.js is actually right Not quite. "NestJS" is actually right. :)
      • jondwillis 5y ago
        I'm lolling because their first code block next to a live preview shows "500 internal server error"
    • gavinray 5y ago
      This is a good point, updated parent post
  • rwoerz 5y ago
    Arrghh... This week was the first in years where I didn't FOMO. And here comes Nest.js. I desperately need an ad blocker though for shiny new tech thingies.
• jzig 5y ago
  I started my career with Rails, then some frontend, and now work a full-time job in Node. Agree with most or all of these points - full-stack javascript is kind of a mess and hasn't really progressed despite individual tools having done so. I think https://sailsjs.com https://sailsjs.com set out to solve a lot of these issues many years ago, by trying to be a JavaScript version of Rails. I'm not sure if they ever reached "feature-parity" though.
• codingdave 5y ago
  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 sets can assemble their own solutions and might not want that anyway. But this author just wanted to pick a platform and move on, and yep, Rails works for that.
  • ehnto 5y ago
    Frameworks in general are about providing a set of decisions and idioms for you to follow, and so they work very well in teams and long-lived projects. They also tend to be pragmatic rather than exotic, so they are robust and useful, not fancy and brittle. On personal projects I do whatever the hell I want, in professional projects I always use a framework, to make sure everyone is on the same page and we don't have to bikeshed every simple decision on the road to delivery.
  • vdemedes 5y ago
    > 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. No doubt here! I know there's a lot of nitpicking, but that's just my experience so far. I wanted to make it clear by removing all "we" or "you" words from the post to make sure I'm not saying my opinion is the definitively right one :) > Rails is not the only choice that does so. Absolutely, the only two reasons I went with Rails is because Ruby looks beautiful to me and I was following the news in Rails world for years.
  • coffeefirst 5y ago
    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.
    • CallMeMarc 5y ago
• designium 5y ago
  I think the author is trying to compare what it takes to create an MVP web-app with all modern features versus creating it in the JS ecosystem. Also, Rails is well known to have Convention over Configuration. That helps to set up and maintain a project since everybody has to follow the same pattern. The cons is that you lose flexibility from the architecture perspective. But in Rails, you have ways to overcome that easily. I think Rails lost popularity when the front-end JS framework movement started. Rails didn't have a response to that; people had to create the Rails app, remove the Views and use a JS framework to create the one-page app experience. Now, if you are already spending that much time using JS for the front-end, why not use JS for the backend? But then things got too complex in the JS due to the lack of conventions.
  • vdemedes 5y ago
    Couldn't have said it better myself! A lot of JS tooling that popped up in the last 10 years is amazing. The React way of building a UI makes a lot of sense to me and I like it way more than HTML + JS combo from the old days. Also, using JS for both frontend and backend is convenient and great for hiring teams. But, after years of making SPAs, it gets tiring to assemble all of the pieces from scratch every time. I don't want to configure things, I want to build my ideas.
    • robertoandred 5y ago
      So use a JS framework?
  • lobstrosity420 5y ago
    I think in reality the JS ecosystem is fat with choice for convention over configuration style frameworks. Projects such as Nest, Sails and Adonis leave nothing on the table compared to Rails. The problem is a lot of programmers would rather loosely cobble something together with express than to stick to rigid standards. That's what I think actually leads to the problem of inane NodeJS codebases people always complain about, it's cultural rather than technical. Perhaps the accessibility and popularity of JavaScript leads to a much larger crowd of inexperienced programmers.
• _fat_santa 5y ago
  I look at it the other way around, to someone coming from Ruby/Rails, there are far too many choices to make and it can seem very overwhelming. But on the flip side you get very granular control over your projects structure. Like when the author mentioned the framework options: > Next.js, Remix, Gatsby, Vite, Create React App, Koa or Express? - NextJS, Gatsby - Best for building "websites" that are optimized for SEO - Vite, CRA, Remix - Best for building SPA's - Koa, Express - Backend frameworks. On the one hand it's very overwhelming, but on the other hand, each framework accomplishes something very specific. Even the differences between NextJS and Gatsby, Gatsby uses a different model for how you would fetch data, with Next you write regular Node code, with Gatsby you do everything through GraphQL.
  • scoot 5y ago
    > NextJS, Gatsby - Best for building "websites" that are optimized for SEO "Next.js", not to be confused with NestJS...
• pictur 5y ago
  Choosing something and making a decision is not as difficult as it seems. You don't have to when someone comes along and tells you "we should use pnpm because it's much faster". Before using any tool, you take a brief look at how it works and what it does, and decide accordingly. I don't understand why you see having more than one option as a problem.
  • lobstrosity420 5y ago
    I mean, analysis paralysis is a real thing. But I think people vastly overestimate the value of having a golden hammer solution like Ruby on Rails on your ecosystem and downplay the disadvantages.
    • briantakita 5y ago
      Major upgrades in Rails has been complicated & time consuming in the past. Loosely coupled libraries mitigates the work of upgrades.
  • wruza 5y ago
    why you see having more than one option as a problem Because some of us are hardwired to choose carefully. If so, when we have to go buy some groceries we just want to get a decent car and drive. The car and driving itself is irrelevant or minutiae, but we can’t tell whether it could take left turns from the start. When there is no decent car by default, we try to be picky about every component, and when it’s almost perfect, it’s also night and the shop is closed. It may be easy for you, for a combination of reasons: a huge experience, low perfectionism and high “fuck it, will sort it out later”-ism, and then something else. But it’s not a professional path we used to. Our professional path is to ask someone which car to buy and go buy it. But if you ask someone which js framework to use for regular tasks, you get this thread instead. On top of that, your resume will miss a 3 years of Winch experience, which suddenly everyone demands when you lose a job or fail your company.
    • pictur 5y ago
      "It may be easy for you" I'm sorry that you understand this from my message. That's not what I meant. good luck with your professionalism.
• paradite 5y ago
  SPA and Rails are not mutually exclusive. For a simple MVP, Rails is enough. As features grow and frontend becomes more complicated, you can then evaluate again if you want to move the rendering part into a separate SPA while retaining Rails as API server. This was the path that my previous company took.
  • sdesalas 5y ago
    Totally agree.
• lnxg33k1 5y ago
  I think it all goes down to the explosion of popularity of javascript, it is a bunch of tools made by a relatively new to tech people, for relatively new to tech people, still trying to understand/learn how to do things properly , it is not an attack, it is just an opinion, many new technology at their dawn have had the same issue
• recursivedoubts 5y ago
  I think there is a barbell situation here: We need libraries that are less opinionated and more tightly focused, working through standard APIs that are open and composable. As an example, htmx works w/ any back end fine because it's "just HTML". That's great because you can use htmx with any HTML-producing backend without a big conceptual shift on either the front end or back end. But the downside of that approach is that it is more fiddly and doesn't handle a lot of stuff out of the box (e.g. CSRF protection) that someone who wants it to "just work" expects. This is where the other side of the barbell comes in: a nice and complete collection of htmx + whatever config is needed for a particular back-end, and all the other stuff that a typical developer might need to just get things running would be really nice. As someone from the java world, maybe just a pom.xml file w/ an init script that sets up the base project, or something like that. I know I'd like the latter for my java projects!
• adithyasrin 5y ago
  I like Laravel for similar reasons. It comes with tools and packages by default so I don't have make decisions. Also pretty useful when you start a new project and you know what's happening.
• eric4smith 5y ago
  And now with the kind of apps you csn make with things like Liveview, there is even vanishing reasons to use things like React. Most React websites did not need React. Even more so in 2022z
  • robertoandred 5y ago
    What's the reason to use LiveView? Looks like a lot of duplicated or dislocated behavior on top of a rickety and heavy websocket setup.
• 20wenty 5y ago
  This article resonated with me, but the main reason I moved from RoR apps to JS/SPA was hosting costs and scalability. I can build a SPA and host the bulk of it on Amazon S3 and pay significantly less monthly costs AND have scalability built in. If you've figured out a way to do something remotely similar with Rails, I'd be back in a heartbeat.
  • gls2ro 5y ago
    I think you meant to say that you can build the front end of an RoR app in JS/SPA and host it on S3. Because it is hard for me to see how you can create a backend API in JS and host it on S3. I might be wrong as my knowledge in JS is limited.
    • 20wenty 5y ago
      Right, front end on S3 built in something like React, and API/backend on other services. There are established patterns like https://docs.aws.amazon.com/prescriptive-guidance/latest/patterns/deploy-a-react-based-single-page-application-to-amazon-s3-and-cloudfront.html https://docs.aws.amazon.com/prescriptive-guidance/latest/pat... and https://docs.aws.amazon.com/whitepapers/latest/serverless-multi-tier-architectures-api-gateway-lambda/single-page-application.html https://docs.aws.amazon.com/whitepapers/latest/serverless-mu..., but looking at the diagrams supports OP's point: "it so much harder to create apps in the JavaScript ecosystem."
• cryptos 5y ago
  At least for the front-end part another, more complete framework like Angular might have been a better fit for the author. Angular comes with pretty much all you need.
• EnKopVand 5y ago
  I don’t fully understand the issues people have with JavaScript and especially React. Maybe it’s because we invested some time in setting up a baseline project with ESLint, prettier and a TSConfig that makes for an entirely fascist way of doing TypeScript that just happens to always work. Maybe it’s because we don’t NPM install a lot of things, but instead take what we need and build our own packages (riding free on the backs of hard OS labourers, but hey). Maybe it’s because we build most compute heavy things in Azure functions running either dotnet or Node. Maybe it’s because we’ve adopted ODATA, build a generic API for 95% or our use cases and then build an ODATA TS client that includes types for all ODATA URI conventions and all our tables. Maybe it’s because all our packages are build with Rollup and Microsoft’s own Type API. Maybe it’s because our pipelines flow directly through Azure DevOPs and into different deployment slots automatically once it’s set up with docker. Maybe it’s because I’ve never worked smart with another tech stack. But building things with react is frankly the easiest, least complicated and most enjoyable thing that I have ever worked with. For references I have a decades worth of C# experience, with a gradual transition into Python and now into C# and mainly TypeScript. Don’t get me wrong, I don’t think you should use a tool that isn’t right for you. If Ruby works, great. If Django works, awesome. Hell, if old customised ASP 3.0 web forms help you deliver the product you need to deliver, then I’m just never going to judge you. I’ve been part of teams that created incredibly business value with tools most people would consider insane after all. But I think TypeScript is just increasingly useful. The only thing you can’t do with TypeScript, and especially with JavaScript, is Google solutions. I learned this the hard way when I had to build my first NPM package. It was easy enough, but then it had to work with Azure functions and I entered a world of hurt. As any good senior programmer, I read the documentation and didn’t understand one bit or it, other than GitHub enterprise has replaced NPM enterprise which is kind of shit when you’re using Azure DevOps and not GitHub, but hey, we’ll just put our packages public. I don’t have access to the corporate credit card anyway and getting it takes a week, and going public will enforce a lot of best practices on its own. Anyway, a week later and 9 million Google rabbit holes later, I stumble across rollup and Microsoft’s api for generating .d. type files. Ten minutes later, everything, works effortlessly. But that’s 9 million medium, dev.to, you name it attempts later. It’s 9 million different ts configurations. It’s 9 million package.jsons later. So I sort of lied when I said that I didn’t get the author, because I do, but the thing is. It’s not really the technology is it? To me at least it’s rather the endless sea of useless “look at me” blog posts that inevitably follows popular technologies.
• RyanGoosling 5y ago
  Have any of you tried .NET?
  • thenerdhead 5y ago
    Yeah but this falls into similar territory. Do you choose ASP.NET MVC? ASP.NET Razor Pages? Blazor? ASP.NET Web API + Angular/React/etc? I think this article is basically saying "stick to the boring stuff that does what you need out of the box". What is that in .NET land though?
    • metaltyphoon 5y ago
      Razor pages, that id the boring stuff
  • Ducki 5y ago
    I love it!
  • throw_m239339 5y ago
    Have any of you tried JEE? ;)
  • benbristow 5y ago
    ASP.NET is great but it definitely comes under the same banner of 'too many choices needed' compared to Rails. e.g. Framework - Which .NET framework do you use (Core/LTS)? Do you use MVC, Razor Pages, Web API and Blazor (Server or WebAssembly) or Web API and an alternative JavaScript/TypeScript based frmaework?. Do you use JSON/XML/SOAP or gRPC? How do you serialize your JSON (NewtonSoft.JSON or System.Text.JSON)? Database - Do you use Dapper, Entity Framework or just utilize a SQLConnection object manually (And then do you use System.Data.SqlClient or Microsoft.Data.SqlClient)? Which database driver do you you use? Authentication - Do you implement this manually? Do you use something like Identity Framework? Do you use a third party provider like Azure AD(B2C), Auth0 etc. etc.? Do you use header based authentication, JWT's etc. etc? Jobs - Do you create a separate service project or Windows Service? Do you use HangFire or Quartz? Email delivery - How do you render your templates? Do you send via SMTP manually or do you use a third party API like Mailgun/Sendgrid etc. etc. Folder structure - completely up to you, no real standards there. Testing - Do you use XUnit, NUnit, MSTest, SpecFlow?
• yawnxyz 5y ago
  I've settled with Svelte (SvelteKit and Sapper), after having spent lots of time with React and Vue. Svelte works in a way that jives with how I think and work, and I've built enough components for myself that side projects now only take hours to design and build into working prototypes. I think everyone needs to have a "home platform" where it's just mindless to get started. Regardless whether it's JS SPAs or Rails or raw HTML! For handling data, it's either Supabase or Airtable's API, hands down. Tailwind for design system. I've tried Rails before, but as a newbie to Ruby, I couldn't even figure out how to write for loops. To me, that was too foreign, and too much thinking involved. And with Rails, you need to run a server too right? That's even more not-mentioned work.
  • sdesalas 5y ago
    I was wondering why nobody was mentioning Svelte and Vue. I find either of these two options is more productive than React or Angular anyday.
  • BenjiWiebe 5y ago
    I'm not new to Ruby but I don't know how to write a C-style for loop in Ruby either. Ruby has iterators, so you don't need for loops. list_of_things.each {|thing| thing.dostuff }
  • midrus 5y ago
    Settling with the latest newest and shiniest doesn't sound like settling at all.
• prea 5y ago
  It'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.
  • tobyjsullivan 5y ago
    This aligns with my experience. It’s also a classic case of picking the right tool for the job. 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.
  • dataminded 5y ago
    You have to know enough about the choices and their edge cases to make good choices. You are also at the mercy of all of those choices continuing to evolve in complementary ways in the future.
• tylergetsay 5y ago
  Am 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.
  • krisrm 5y ago
    Yeah whenever these SPA-slamming posts come up, I just try to imagine carpenters posting about why they switched to hammers from screwdrivers. They're just different tools that excel at solving different problems.
    • bdcravens 5y ago
      As I said in a sibling comment, the problem is that some SPA-developers then see everything as one type of problem (I said nail there, but using your analogy, screw works better). Carpenters will tell you that screws aren't really superior nails - certain applications actually hold up better with nails (interesting enough for this analogy, those with a lot of side load, where screw heads may actually shear off)
    • jonahx 5y ago
      To use your analogy, what if a popular screwdriver company started a trend among young carpenters to use their screwdriver handles as hammers? And then large numbers of carpenters were driving nails with screwdriver handles instead of hammers? That is where the SPA slamming is coming from. It's not that people fail to grasp the concept of different tools for different jobs.
      • jack_riminton 5y ago
        Exactly. 80+ % of all web dev jobs I see have some sort of SPA requirement I'd guess that only about 20% need to be an SPA and the rest is cargo culting
  • PragmaticPulp 5y ago
    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 tool. The business requirements don't matter. They're going to use their favorite tool regardless of whether or not it's appropriate. The more complex they can make something, the better they think it will look on their resume. The latter group can be valuable assets if you know that your application requires a SPA and matches the person's chosen specialty. However, if you're hiring a dev who wants to build complex apps and your company doesn't require complex apps, you're going to end up with unnecessarily complex apps. Then the person will use the complex app to boost their resume and leave for another company. Fortunately, it's not too hard to differentiate between the two groups at interview time.
• TheDesolate0 5y ago
• veidelis 5y ago
  Show me your UI and I will tell if you made a reasonable choice or a mistake.
• jack_riminton 5y ago
  There must be an internet law whereby the moment you criticise something about JS there’ll be a reply saying “x does this” where x is something you’ve never heard of before
  • dnfa 5y ago
    I agree - Rails does everything, and there isn't a JS solution that's similar out of the box. You have to be familiar with a ton of stuff not to get caught up in content marketing traps for solutions that look like they fit your use case but probably don't. For prototyping things, I like the way Next.js generates a lot of boilerplate routing and api endpoints for you, and so in that way it's similar to rails scaffolding things for you. But when it comes to db migrations, an ORM, anything else, you're on your own!
• pupppet 5y ago
  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.
  • tiborsaas 5y ago
    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.
  • dgb23 5y ago
    Ui state managegent has to live somewhere. All of the solutions that try to do it server side I tried eventually smear it all over the place.
    • draw_down 5y ago
• nesarkvechnep 5y ago
  I have evidence of many people who settled on JavaScript SPAs but still didn’t think.
• FpUser 5y ago
  >I still enjoy React, but why is it so much harder to create apps in the JavaScript ecosystem, compared to Rails? We have all the necessary tools after all. It is not harder at all as long as you do not commit to those giant frameworks and accompanying toolsets. I wrote decent size SPA using couple of libs and plain JS. Was fairly easy.
• philip1209 5y ago
  I built my last company with Go, Vue.js, gRPC, and Kubernetes. And, wow was it a slog. It was hard for new developers to jump in, we had separate engineers for frontend + backend, and there were things we never even touched - such as real-time/websockets or end-to-end testing. I recently started a new project in the same stack [1], and partway through paused because it was taking so long to deliver customer value. I jumped back into Rails, inspired by their new Hotwired framework [2]. And, holy shit - the speed of development became insanely quick. Not only that, but I've been able to achieve a higher level of polish than I would have with a single-page JS app. Specifically - building in real-time updates only took a few lines of code. It was possible to achieve this level of polish with an SPA, but realistically it would have taken me so much time that I would have never prioritized it. I hadn't touched Rails in over a decade. As a junior developer, I felt overwhelmed because Rails had solutions for so many problems I had not yet encountered. But, returning to Rails with some more experience - I appreciate its "omakase" [4] approach so much more. So many best practices are built in or easy-to-install. Queues, cron, async jobs, audit logs, email click tracking, end-to-end testing, real-time updates, caching, sessions, URL slug "friendly IDs", image resizing, rate limiting, admin interfaces, rich text fields, S3 integrations, sitemaps - they all just work! With the new Version 7, Rails is truly a "One Person Framework" [5]. [1] https://www.booklet.group https://www.booklet.group [2] https://hotwired.dev/ https://hotwired.dev/ [3] https://bookletupdates.substack.com/p/comments-directory-and-some-surprises https://bookletupdates.substack.com/p/comments-directory-and... [4] https://dhh.dk/2012/rails-is-omakase.html https://dhh.dk/2012/rails-is-omakase.html [5] https://world.hey.com/dhh/the-one-person-framework-711e6318 https://world.hey.com/dhh/the-one-person-framework-711e6318
  • mentos 5y ago
    Reminds me of Paul Graham’s essay on language power “Beating the Averages” “It must have seemed to our competitors that we had some kind of secret weapon-- that we were decoding their Enigma traffic or something. In fact we did have a secret weapon, but it was simpler than they realized. No one was leaking news of their features to us. We were just able to develop software faster than anyone thought possible.” http://www.paulgraham.com/avg.html http://www.paulgraham.com/avg.html
  • 5y ago
• impostervt 5y ago
  All frameworks are great, until you need to do something non-standard, and then you'll spend a large amount of time fighting the framework. The more "standard" the product you're building, the better off you'll be choosing a framework that is highly structured.
  • bdcravens 5y ago
    Very few apps don't have a framework. The issue is whether you built it yourself. Also, "non-standard" apps are far less common than we would like to think. There's only so many potential ways to reinvent wheels.
• bdcravens 5y ago
  If you can easily switch to a framework like Rails from a SPA, it's probably a sign your app shouldn't have been a SPA. There's too much "defaultism" in our industry.
  • jack_riminton 5y ago
    Agree, unless your UI is very interactive and complex e.g. a photography editing app then you can likely go without an SPA Your designer might be pissed, but your customers probably don't care all that much and your CEO is going to be pleased at the speed, stability and simplicity of what you've created.
    • fastball 5y ago
      Agreed, but additionally you might need/want an SPA because you want to be able to very quickly spin up mobile/desktop apps (e.g. with Capacitor/Electron) or you want a functional offline mode.
    • bdcravens 5y ago
      I've run into plenty of apps that don't really look that great yet are SPAs. Like basic form post kind of sites. As I mentioned elsewhere, I got blocked paying a student loan due to one, and had to jump into Devtools to get a broken CVS app to submit a prescription request.
  • hallway_monitor 5y ago
    This and my sibling nailed it. Defaulting to a SPA is a terrible way to start web projects you would like to complete on time. But wait! Now your company has "front end devs" who you can't trust to touch your back end - better use React again to give these people something to do since JS is all they know.
    • bdcravens 5y ago
      My approach is Rails until the last possible moment. I'm no Rails maximalist - I did recently spin out a major part of our application into an Express service, as the Node library for a specific task was the best in breed. But I'm very defensive against signing my name on a complexity mortgage.
• onion2k 5y ago
  Language X is better than language Y is blog posts are incredibly boring. No one actually cares what the author thinks - Rails devs will agree, JS devs will disagree, and no one else will care. But there's a great lesson here nonetheless. When you're running a startup, and you're at that critical stage after launching when you're trying to get traction, getting people to see you exist is key. reviewbunny sells a service for developers who want to get an email digest of their pending PRs at the end of the day. The notification emails that Github and Gitlab send aren't particularly clear, and setting up mail rules to mark them as important doesn't work for everyone, especially if you're working on multiple projects at once. So the author set out to make a product to solve that pain point. Writing a controversial blog post has got them to the top of HN's front page, which is awesome, and if the graph at the bottom of the homepage is correct it's won them 2 new organisations and a few new users since the article was posted. Amazing stuff. That's exactly what founders should be doing. Maybe if it was a little less controversial those numbers would be higher, but there's no way to tell. Nevertheless, this is a fine example of 'content marketing' in my opinion. Well played. And I say that as a JS dev. :)
• snemvalts 5y ago
  Working in a Rails based startup that took the same approach as OP, then at one point understood that we need React in the frontend, and a few years later the development process is a pain: * 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.
  • password4321 5y ago
    > it's better to take the less opinionated road (SPA in this case), so you can be more specific later Can you elaborate on this a bit? Are you saying that an SPA with React (+ other server-side pieces in NodeJS?) would have been the better choice than the Rails + some React mess you wound up with? What about sticking with just Rails, no React? Thanks for your time.
    • snemvalts 5y ago
      Yeah, SPA approach would separate the frontend and backend conceptually to different microservices. Frontend is served separately off CDNs, backend isn't involved with it. When frontend team decides on a different framework/approach, they can switch, and the frontend just consumes the backend API. Backend focuses on building an API, doesn't have to deal with templates etc. The other server side piece doesn't necessarily have to be Node, it can be whatever the backend team wants it to be, Rails is also fine. All it has to do is spit out JSON.
      • redbar0n 5y ago
        I think he wanted to know why you decided that you actually needed React on the front-end, as opposed to doing it «the Rails-way»: HOTwire Stimulus etc.? https://hotwired.dev/ https://hotwired.dev/
• 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.
    • 5y ago
• wirelesspotat 5y ago
  > Package manager > npm, Yarn 1 or 2 (yes, they're completely different), pnpm or Snowpack? I thought Snowpack was a build tool[0]. Is it actually closer to package managers like npm, yarn, pnpm? [0] https://www.snowpack.dev/concepts/how-snowpack-works https://www.snowpack.dev/concepts/how-snowpack-works
• nkjoep 5y ago
  imho, don't wanna think? just pick a boilerplate and go with the flow.
• yoda97 5y ago
  Haha that was my reaction when I first picked up Laravel. I'm pretty sure every new dev has the same reaction when picking up their first opinionated framework.
• deleted 5y ago
  [deleted]
• matijash 5y ago
  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.
• MakerSam 5y ago
  Google 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%205-y&q=%2Fm%2F0bbxf89,%2Fm%2F0505cl,%2Fm%2F012l1vxv https://trends.google.com/trends/explore?cat=31&date=today%2...
  • jacquesm 5y ago
    Or maybe the documentation for the one is better than the other.
  • emodendroket 5y ago
    I would suspect searches are overwhelmingly weighted to beginners to a particular environment.
    • oblio 5y ago
      Heh. That would have been the case 30 years ago, but nobody can hold info an entire stdlib in their head anymore. Advanced users just move their searches from Google to the reference docs page.
  • jmondi 5y ago
    As someone who came from other MVC frameworks outside of Ruby, learning Rails has been a cluster-f of searching through documentation circa 2013. The whole rails “convention over configuration makes it easier” is a load of bologna, because the only way to know the “convention” is to either have gone to a rails boot camp, reading the docs top to bottom, or maybe watching rails casts. The best way to work on rails is to either already know rails yourself, or be working with a rails guru, which admittedly there are a bunch of those. At least with a configuration over convention you can just look at the code and figure out what is happening. With rails, there are certain magical things you just Need To Know and the only way to know those things are to already know them before running into it.
• locallost 5y ago
  Basically the author reduced himself with Rails happily to a subset of the options, yet does not want do it in the JS world. The question is why? In my experience it's fear. Fear of somebody coming along and criticizing him for using X instead of Y, for not using the shiny new Z, fear of basically feeling inadequate. So get over it. The task of a developer is to make something useful. The users don't care about technology unless it's something that improves their life. They don't care about your SPA or not, and they especially don't care about the package manager your project uses. If Ruby helps you do that, go for it, but otherwise just let go snd do things. Somebody will always nitpick.
• BMorearty 5y ago
  Great post. This is one reason I love using Rails, the fact that it makes so many decisions for you—and with good defaults. Before Rails I had the exhausting experience of spending weeks making tech decisions just to start a project. (I’m also a huge JavaScript fan but for different reasons.) Small nit about one point in the post: > As far as I know, serverless platforms don't support WebSockets I’ve spent the last couple weeks deep-diving on Cloudflare Workers. They have good support for WebSockets. And if you need your WebSocket to maintain state long-term, the server side can use a Durable Object.
• prescriptivist 5y ago
  Rails and Ruby bake in a lot of really nice, ergonomic features for every day programming, not just larger architectural decisions. For instance I am working on a React Native app in my spare time and so much of Javascript seems tedious. Example is dealing with date ranges. Contrived example: import { isWithinInterval, subDays, addDays } from 'date-fns'; const today = new Date(); let range = { start: subDays(today, 1), end: addDays(today, 1) } isWithinInterval(today, range) The functions for this kind of calculation has to be imported into any file I want to use them? There seems like a lot of copy pasting of this kind of stuff everywhere in a robust javascript app. I think it's reasonably easy to read and understand, so I don't fault that, it just seems tedious to use tons of libraries that you have to explicitly import everywhere to accomplish simple things. Feels like death by a thousand cuts. Meanwhile in Ruby (with Rails) this is functionally equivalent and is usable everywhere in the code: Range.new(Date.yesterday, Date.tomorrow).include?(Date.today) edit: fixed some bugs :)
  • Too 5y ago
    Use https://momentjs.com https://momentjs.com instead moment('2022-02-05').isBetween(moment().startOf('day').subtract(1, 'day'), moment().endOf('day')); Still requires one import but that's hard to avoid. Don't be afraid of them, the IDE will usually add them automatically and hide them anyway. It's a good way to increase tracability maintainability, instead of magic stuff happening in the background.
    • kavaruka 5y ago
      moment is dead, nowadays there are better libraries https://momentjs.com/docs/#/-project-status/ https://momentjs.com/docs/#/-project-status/
  • jmondi 5y ago
    Not copying and pasting that code chunk and wrapping it into a utility function :red-flag: :red-flag: :red-flag:
    • prescriptivist 5y ago
• duveloper 5y ago
  As someone who is in the same position as author, Angular + Firebase is a very helpful alternative to moving to Rails while providing the benefits of an SPA.
• jugg1es 5y ago
  The same argument could be made for using Angular as well. Just because a framework is opinionated does not make it bad.
• Unbeliever69 5y ago
  This article really resonates with me but not because I've been down the same path. Back in 2011 I learned Ruby as a hobby language and from the beginning I fell in love. Probably because of my OOP background as a programming hobbyist since the 80s. A few years later I did a career pivot away from Ux into programming and after a brief stint in Java, my research just naturally funneled me to the Javascript ecosystem and full-stack development. Thanks Ryan Dahl! But I wasn't happy in Javascript. It wasn't because I was stuck in my OOP brain. I didn't fight it. It just took a long time to embrace declarative programming. In 2018 I attended a bootcamp (Dev Mountain) and learned a single stack that, while opinionated, didn't bring me any fulfillment as a programmer. Mainly for the reasons you described. Too many choices. Not enough opinion. Too much flavor (fatigue) of the month. But mainly, I don't have a lot of joy like I felt when I was doing Ruby. Fast forward to 2022. My company (a small 3 man development team) has been working on a greenfield project for three years. A massively complex project for such a small team, but finally we are done. Yay. But boy has the journey been wild in terms of our stack evolution. The thought of building a side project in the JS stack I am comfortable with just doesn't sound fun. I long for the warm fuzzies of Ruby. This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you. For anyone that is interested, my current stack is React (Tailwind CSS)/GraphQL (Apollo and Postgraphile)/Express/PostgreSQL with docker CI/CD and AWS lambdas.
  • multiplegeorges 5y ago
    > This has almost inspired me to build my passion side-project in Rails to get my mojo back. Thank you. Try it out. Rails 7 has a really interesting view on frontend dev with importmaps and Hotwire.
• TheRealDunkirk 5y ago
  What I've gathered, over the years, is that the people who dislike Rails because it makes a lot of decisions for them think they're just too cool for that. It insults their programming ability. OK, I can see that. So, go ahead; have it your way. But while you're still writing thousands of lines of boilerplate in both the front and back ends, and getting your types sorted out, I'm done with my app, and moving on to the next one.
  • purplerabbit 5y ago
    I dislike it because I prefer code over configuration OR convention. Please give me code I can understand-by-reading and not code I have to understand-by-synthesizing-with-a-non-collocated-knowledge-set. This is why the “worse” of golang is better than the “better” of rails
    • TheRealDunkirk 5y ago
      This simple class in Rails: class Assignment < ApplicationRecord belongs_to :project belongs_to :release accepts_nested_attributes_for :release, reject_if: :all_blank, allow_destroy: true end Would represent several hundred lines in Java and Angular. Do you really need to see every line of code required to explain every object and how they relate to each other to the various compilers in your application?
  • LAC-Tech 5y ago
    Ok I'll bite - what else have you tried and what made rails so more productive? My experience with big web frameworks - though I can't speak to rails in particular - is that everything is sunshine and rainbows until I veer a little bit off the standard path (or rail) and then it all becomes a nightmare. Where as if I'd done a little bit more myself up front, the thing is more resilient and can easily go where I want it. Really happy to be wrong here, would love it if rails became my secret weapon. I'm a big ruby fan. But I'm sceptical.
    • breckenedge 5y ago
      Rails has a ton of escape hatches when you want to make a different choice from the defaults, just as long as you’re writing a web app or HTTP API. The challenges I’ve run into in the Rails ecosystem more revolve around 3rd-party extensions making assumptions about how my app works and not being as flexible as the framework.
• bradwood 5y ago
  Gitlab support would be nice
• dataminded 5y ago
  I've been trying hard to make the migration from Django to Javascript for my dev work (95% of the time, I am building internal tools in a hurry) and it's been a major slog. I can write JS just fine, but spend all of my time trying to build a functional environment with the correct set of libraries and dependencies.
• phendrenad2 5y ago
  I'll also point out Laravel as a wonderful PHP alternative to Rails for people who dislike Ruby. And if you prefer Python, Django isn't terrible.
• fidrelity 5y ago
  We're launching our next startup in less than a month and were faced with the same decision. Ultimately went with Rails. As said in the article: so, so much comes out of the box or from a very well maintained ecosystem. Real-time dashboards (action cable), background jobs (active jobs, sidekiq), auth, tooling, etc. was each less than a day's work which allows us to launch so freaking fast. Only real downside in my eyes is the hiring for our location (central Europe) and future UI complexity, where my solution will probably be to just drop in a Vue app where it makes sense.
• jconley 5y ago
  If anybody wants to help solve this problem, hit me up. :) Working on it...
• zdiscov 5y ago
  This is exactly the problem I am facing now! I thought picking up and building things with Vue should be a breeze but boy what a nightmare its turning out to be. There is so much room for improvement in the JS ecosystem.
  • blitzd 5y ago
    Have you looked at Svelte? We've been migrating over to it from Redux/React, and it's so far been a great experience. It's greatly simplified a lot of our code, and eliminated a whole lot of redux/state boilerplate.
    • zdiscov 5y ago
      Haven't tried Svelte yet. Do you think its mature enough? Just hoping it is a relatively less painful can of worms to explore :)
      • Glench 5y ago
        Definitely mature enough. Take a look at their really awesome interactive tutorial to see how well-developed all the pieces of Svelte are: https://svelte.dev/tutorial/basics https://svelte.dev/tutorial/basics
• handzhiev 5y ago
  Slight offtopic, but is Rails again on the rise? I see a lot of startups using it. Can someone who is more into startups share insights?
  • jack_riminton 5y ago
    Obviously anecdotal but the startup I just joined (12 people, series A-ish) chose Rails. The team had previously come from a startup who crashed and burned in the complexity of a React SPA
• gwbas1c 5y ago
  For the past two weeks I've been evaluating Blazor. (C#) It's real nice. It comes in two flavors: Server-side that controls the browser via a websocket, or client-side that compiles C# into WASM. Server-side has the advantage that you don't have to wrap up all your APIs into contracts; client-side is a bit more "normal." The Razor templating system is very nice. It's not like mustache where you have to learn a completely new syntax; it's very minor bits of C# and regular HTML. I'm not sure I'd pick Blazor in a complete greenfield situation; but given that I'm working in a C# shop, it's a great way for C# developers to be full-stack while keeping the learning curve simple.
• DanHulton 5y ago
  I mean, this is why I wrote Nodewood: https://nodewood.com/ https://nodewood.com/ I strongly prefer the explicit nature of JS programming, where you don't have to know a bunch of Rails-y magic to know where a certain symbol is coming from, it's just defined in the file you're working in (to pick one example). But I completely agree that the time from Start to CRUD in Rails is a killer app. I keep kicking up new projects in my spare time, and for every one of them, I'd have to set up the application scaffolding, linting, set up a layout and basic design rules, figure out user management, and if I was getting serious, set up subscription management, team management, etc. Rather than rewrite it every time, I figured I could make an actual library out of it so I have a decent base to work from, and then turn it into a product, because I can't be the only one who has these similar issues. Also, Nodewood isn't alone out there - there are all kinds of Rails-ey bootstraps or starter kits out there for all kinds of languages. Now, the fact that everyone thinks "Ruby" and immediately thinks "Rails", but they don't think "Node" and immediately think "and a starter kit" means Rails has performed some amazing marketing mojo, but that doesn't make it fair to compare JavaScript to Rails, the author should be comparing JavaScript to Ruby, or Rails to a Rails-ey bootstrap.
• deleted 5y ago
  [deleted]
• redbar0n 5y ago
  My thoughts exactly. The JSFatigue is real. But, many options is a luxury problem.
• sexy_seedbox 5y ago
  These days, sticking with a traditional backend stack then sprinkle in unpoly or htmx on the frontend makes things so much simpler.
• dustymcp 5y ago
  This is why i use Angular, alot of things are already implemented and working, its easy with nswag on top of api's. mostly i just use the framework rather than taking a bunch of design decisions, i just cant get along with the custom vue/react applications :(