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

411–420 of 490 posts

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

#411

Post by basicallybones »

khalilravanna wrote: post #317
continuational wrote: post #298

Earlier quoted context omitted.

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!

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.

Can't speak for the rest of the world, but my team has been using an NX monorepo with a standard types library that can be imported into any application in the monorepo. It is trivial to use the same interface, enum, class, or other type-enforcing mechanism across multiple frontend and backend services. The development experience has been quite nice, and refactoring/changing the data structures is a breeze. If you are in the Typescript world and haven't looked at NX...check it out.

By the way, echoing some discussion above, we migrated from Express to NestJS, and it was an excellent decision.

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

#412

Post by Lio »

omarhaneef wrote: post #109
usrusr wrote: post #66

Earlier quoted context omitted.

The dominance of Rails for its use case within the field of Ruby is is only one half of the equation. The other half is that Ruby has mostly collapsed into Rails, there's not much Ruby happening outside of Rails. This could never happen with a js framework of similarly scope, because all the other js use cases won't go away. One example of such a thing that won't go away is doing client-side stuff in the scope of a R…

I think this is "the" correct analysis. Rails has a clear one way to do things because there are no/few other options because everything else has withered away. To put this another way: to have a convention in JS, just pick a convention, and now at least you have a convention, even if everyone else has their own.

It’s not really true that there are no other options for web development in ruby.

Roda[1], for instance, has a strong following for API work.

It’s just that Rails is a safe choice. It’ll will work fine for small teams and it will scale to the size of github when/if you need it.

1. http://roda.jeremyevans.net/index.html

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

#413

Post by yoyonamite »

snemvalts wrote: post #132

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 c…

I think there are ways to do this correctly but it has to be more static pages with JS enhancement and/or making certain sections standalone "single page apps". It sounds like you're halfway in-between and that leads to the sorts of issues you're talking about. Being halfway in-between does mean that you're also halfway to an SPA, so maybe just commit fully to that direction?

Personally, I find webpacker to be straightforward and not that magical relative to the asset pipeline.

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

#414

Post by fuzzy2 »

jillesvangurp wrote: post #200
fuzzy2 wrote: post #147

The title refers to SPAs, a frontend technology. But most of the identified pain points are not about SPAs at all. Well okay maybe the first two or three, but they’re very superficial. Instead, this is more about serverless vs. “classic backend”.

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…

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

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

#415

Post by snemvalts »

password4321 wrote: post #395
snemvalts wrote: post #132

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 c…

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

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.

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

#416

Post by endisneigh »

weatherlite wrote: post #340
endisneigh wrote: post #80

Earlier quoted context omitted.

This isn’t really true though, NestJS for example is very opinionated and similar. The issue is more that Node and JavaScript in general is too popular and there are way more options whereas ruby is rarely used for non rails work.

Python is plenty popular and so is C#, and when you're looking at a batteries included full stack framework you have ONE popular choices - Django or .NET. For PHP it's Laravel (sure, you have other options like Symfony but they are niche), for Elixir its Phoenix. How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?

> How is it a good thing for Node to have 5-10 competing frameworks that have similar adoption?

How is it a bad thing? Again, JavaScript is far more popular than all of those for web related development. The issue is that like you're stating, there isn't a single main option perse. I'd use NestJS.

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

#417

Post by arpyzo »

matt_mb wrote: post #248
jmondi wrote: post #228

Earlier quoted context omitted.

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 t…

"Reading docs top to bottom" is the answer to this frustration. It's strange that people don't think this is something they should do.

This is a fine answer if you're responsible for a small numbers of technologies, otherwise there are far too many "top to bottom" docs to read in a lifetime, let alone the time you have to meet whatever deadline is in front of you.

Where it gets even trickier, is that these days nobody is responsible for just a small numbers of technologies.

Does your app use the internet? Read about TCP/IP and DNS and other internet technologies top to bottom. Does your app use a database? Read the DB docs top to bottom. How about multiple data stores? Is you app publicly facing? Read about 100 different potential security issues top to bottom. I could go on...

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

#418

Post by dustymcp »

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 :(

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

#419

Post by merb »

S04dKHzrKT wrote: post #350
khalilravanna wrote: post #317

Earlier quoted context omitted.

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.

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/blaz... [1]: https://fable.io/

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.

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

#420

Post by HeavyStorm »

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.

Post reply on HN