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

291–300 of 490 posts

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

#291

Post by usrusr »

vidarh wrote: post #253
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…

As someone who has used Ruby as my main language at a number of companies for the last 17 years and deeply dislike Rails and rarely use it, I couldn't disagree more. Rails draws the attention, but there's plenty other uses.

That's interesting to hear, I would have guessed that Python had long won everything that could be ruby but isn't rails. Clearly, nothing will stop the inertia of someone who just happens to be productive through experience (you can probably find works-for-me wizards for almost anything, perhaps not for vba or ada but I wouldn't bet on it).

Is there much happening in terms of libraries outside the rails scope or is it more a case of one less thing to worry about once you've become good with the batteries included?

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

#292

Post by robertoandred »

vdemedes wrote: post #17
designium wrote: post #8

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

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

So use a JS framework?

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

#293

Post by mmargerum »

pphysch wrote: post #111

SPAs are the "Google-scale" of frontend tech. YAGNI unless you are Big (or trying to fleece VCs). SPAs are useful where the latency and overall UX of a button press can be translated to some tiny % increase in a KPI through A/B testing, etc. Where you want to track user behavior down to a pixel & microsecond, and wrapping every element in JS is the only way to get there. This is frankly irrelevant to 99% of projects…

Vue/React/Svelte are pretty damned productive. 1/5 - 1/10th of typical server rendered or native UI LOC. If I never write another line of code directly manipulating UI controls I can die a happy man.

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

#294

Post by jack_riminton »

bdcravens wrote: post #122

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.

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.

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

#296

Post by jack_riminton »

weatherlite wrote: post #288
ta-run wrote: post #59

Earlier quoted context omitted.

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.

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…

I think there should be a RailsJS where they literally copy every convention of RoR

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

#297

Post by pictur »

wruza wrote: post #184
pictur wrote: post #19

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.

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…

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

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

#298

Post by continuational »

tapvt wrote: post #56

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

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!

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

#299

Post by craigmcnamara »

MakerSam wrote: post #271
andrei_says_ wrote: post #243

Earlier quoted context omitted.

What are some specific “magical things” that are not mentioned in the rails guides? There’s always room for improvement and the documentation is an important part of the framework.

I don't think the Rails Guides mention Devise, the authentication gem, which is pretty important if you want create a public facing website with users. The devise documentation is pretty good though. Again, a little bit of a learning curve, but once you learn it you can add user authentication to your site pretty quickly. https://github.com/heartcombo/devise#getting-started

It's not in the guide because it's not core Rails. But there is a great site called RubyToolbox to help you find things that aren't core Rails. https://www.ruby-toolbox.com/categories/rails_authentication

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

#300

Post by dntrkv »

simion314 wrote: post #152
dntrkv wrote: post #75

Earlier quoted context omitted.

> Javascript has such a minimal standard library, you will need to get one or three third-party libraries to augment its core Maybe 5-10 years ago, there is no need anymore > 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 framework. Depends on your needs. Small app? React on its own is enough. Larger app? Add a router. That…

>Maybe 5-10 years ago, there is no need anymore Is still either create your own or install a random package that brings other 20 as dependencies. Example, you want to show an Alert or Yes/No popup, This are built-in everywhere but n Web world you need to review and install a third party thing, or create your own buggy or incomplete implementation. Maybe you want modal dialogs, this is a standard in GUI tookits but yo…

This is a different discussion since Rails doesn't come with such an option either.

But I think you're hitting on two different, yet very related, issues here.

1. Browsers have a very limited set of standard UI components

2. Browsers are held back by the decades long, uninterrupted chain of backwards-compatibility

Both of these things are true. Back in the day, browsers forced more convention and design on elements (alert, select, input, list, textarea, etc), though developers weren't happy with the pace of innovation and design choices offered by the browsers so they began looking at alternative ways to implement the same thing. Eventually the browsers loosened up the restrictions and allowed styling of most of these elements in almost any way you like (though there still are issues).

The great thing about the web is that you are allowed to do this. You have the freedom to build things anyway you like. Of course, that comes with drawbacks like you've pointed out above. iOS is great because it provides a standard framework and approach to implement all of the things you outlined above. Though at the same time, you are limited to UX decisions that Apple deems "correct." I own an iPhone and Macbook and I wouldn't want it any other way at the OS-level.

But the web is the one platform we have where you don't have to abide by anyone's rules. The whole industry can iterate on approaches and the best ideas win. I like this world. I know it's not for everyone, but we don't have any other platform with such reach and freedom from any one company making the rules.

Post reply on HN