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

471–480 of 490 posts

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

#471

Post by dustymcp »

pas wrote: post #437
Cthulhu_ wrote: post #27

Earlier quoted context omitted.

I think the main Thing here is that Rails is the de facto standard, the 'golden hammer' of Ruby based apps, and there is no space - or developers - for alternatives. The JS ecosystem as we know it today started years after Rails (Rails was 2004, Node's oldest version on their releases page is from 2011), and only really took off after NodeJS came to prominence with frameworks like BackboneJS, Angular, then React and…

The default Angular structure is pretty verbose, but it's just TS, you can put the files anywhere. Also it seems many people prefer the Vue-style single-file components: https://muhimasri.com/blogs/how-to-create-a-single-file-comp...

It always gets me abit, angular is called bloated however all the react/vue applications i have worked with have been bloated by shitty packages left and right to fix problems that never existed in angular, im probably just to old or what not but i dont find the configuration bad since you can always figure out what went wrong, that is not the case on react/vue unfortuenately, it ends up being very opinionated by the last dev that took charge, and the endless refactors of architecture because now there is a new way of doing it..

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

#472

Post by stereocodes »

weatherlite wrote: post #339
stereocodes wrote: post #254

Earlier quoted context omitted.

As the other commentator pointed out there are a few options that do have a complete setup. NextJS, SailsJS, and Gatsby to name a few.

Yes Next, Nest, Sails, Gatsby, Blitz, Redwood - none of them became a leading framework like Django or Rails or Laravel has, which means being a Node developer and moving between companies or projects you'll probably relearn everything in a different framework. For me this is just to chaotic and unstable.

I see no difference. PHP has a billion FWs and a billion more CMSs. Python is the same way. Rails is the only example you give that has merit. I mean PHP is a terrible example. I've been coding PHP since around 2007, PHP has Zend FW, Laravel, Cake, Ignitor, Symphony, Silex... it keeps going and going. All I can see from your comment is some biases against JS. You do you on what you want to learn or use. But its not really an argument that holds up imo.

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

#473

Post by redbar0n »

snemvalts wrote: post #462
redbar0n wrote: post #452

Earlier quoted context omitted.

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/

Some back end devs unwilling to learn React are planning to try it. However as I understand, it's using WebSocket. At my previous job, building a customer service view that used it solely for real time updates, I wouldn't use it for anything critical without some heavy fault tolerance (like checksums or a simple incrementable number to count how many messages have been sent). The messages can be randomly dropped by w…

AFAIK Hotwire Stimulus isn’t using WebSockets. I think you’re thinking of StimulusReflex.

Normal Hotwire Stimulus is just JS controllers that references DOM nodes via CSS tags. Example: https://stimulus.hotwired.dev/

I agree that JSX is better. Check out Rux which is «A jsx-inspired way to render view components in Ruby» [to make HTML on the server]. https://github.com/camertron/rux

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

#474

Post by machiaweliczny »

space_fountain wrote: post #319
atmosx wrote: post #280

Earlier quoted context omitted.

Apparently people prefer blog posts to docs. This is not a problem of course, until you need to either debug (hence understand what you're doing at depth) or build something non-trivial.

The problem with Rails is not a lack of blog posts or docs, it's that there's often no way to find what doc you need to read without already understanding the framework. Reading the entire docs and then trying to remember and understand it is a style under which some people learn well and I think it is important for mastery, but the ability to trace back and understand a small piece of a framework is valuable too esp…

No the real problem with Rails is autoimport and bad tooling that you can't jump to source easily. I would love rails if jump to definition worked well but it's deal breaker.

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

#475

Post by weatherlite »

stereocodes wrote: post #472
weatherlite wrote: post #339

Earlier quoted context omitted.

Yes Next, Nest, Sails, Gatsby, Blitz, Redwood - none of them became a leading framework like Django or Rails or Laravel has, which means being a Node developer and moving between companies or projects you'll probably relearn everything in a different framework. For me this is just to chaotic and unstable.

I see no difference. PHP has a billion FWs and a billion more CMSs. Python is the same way. Rails is the only example you give that has merit. I mean PHP is a terrible example. I've been coding PHP since around 2007, PHP has Zend FW, Laravel, Cake, Ignitor, Symphony, Silex... it keeps going and going. All I can see from your comment is some biases against JS. You do you on what you want to learn or use. But its not r…

Laravel is the leading PHP framework by far, I don't think it's up for debate. Ruby also has many frameworks (Padrino, Hanami) but it's obvious Rails is the common choice.

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

#476

Post by jbverschoor »

sodapopcan wrote: post #268
matt_mb wrote: post #248

Earlier quoted context omitted.

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

I was going to say the same thing and figured someone else already had. People would often ask how I knew so much about rails and, ya, the answer is that I read the guides. They are extremely readable and it doesn't take that long. Like a couple of days. You might be surprised how much is retained by just reading through them, even without actually trying things out as you go. I would like to stress: read the guides,…

I did the same for Java, FreeBSD, rails, and in the past the directx docs

Documentation is important. Otherwise you’ll just google for tutorials which are often outdated and still don’t cover the architecture/design.

It’s also fun to see all the little decisions and tools available if you read (properly written) docs

Granted you need to have proper docs

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

#477

Post by WolfOliver »

robertoandred wrote: post #289
WolfOliver wrote: post #13

Earlier quoted context omitted.

The point here is that you do not have to think about choices, there is a "rails way" for every problem. There is no such thing as "the node way". They are hundreds of ways, some of them are dead ends.

Is there a such thing as "the ruby way"?

no, but there is the "rails way" see: https://www.amazon.com/Rails-Way-Obie-Fernandez/dp/032144561...

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

#478

Post by anm89 »

jmondi wrote: post #228
MakerSam wrote: post #192

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…

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…

this does not match my experience. the official rails docs are extremely comprehensive and are totally up to date.

this is also true for a majority of the popular gems in the community

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

#479

Post by branko_d »

com2kid wrote: post #219
EnKopVand wrote: post #60

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…

React is great until you have non-trivial state management then life starts to suck again. The # of react apps I've seen where every key press entered into a form takes 200-500ms is super high. Heck the first version of Work At A Startup here on HN had input box latency problems that looked a lot like what I see in React all the time. It is funny because Redux's religious adherence to a const store makes no sense. Su…

I found MobX working wonders for React UI responsiveness. You can cut-off large parts of rerendering more-less for free, without worrying you'll cut-off too much.

I just wish MobX was statically typed, so I could know what has been observed by just looking at the usage site, instead of hunting for where the corresponding makeObservable is.

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

#480

Post by 3pt14159 »

mrtranscendence wrote: post #162
3pt14159 wrote: post #55

Earlier quoted context omitted.

Rails does, but Ruby is so close to Python and Python has the numerical crowd so you're eventually going to need it anyway if you're successful. I know it sucks, because Rails is better than Django, but at the end of the day I love Ruby but my day job is Python. Also, even though I can never remember capitalization, underscores , pluralization, interfaces in Python[0] at least I don't have to think when I type `and`…

Ruby's not as consistent as you think. I can pull single examples out too -- is it 1.upto or 1.up_to? And I've never had a problem with Python's pluralization. > In Ruby it's Time.now, come on people. YMMV, but I don't find it terribly burdensome to import datetime and call datetime.now().

My milage does vary.

Because is it datetime.datetime.now? or date_time.date_time.now? or datetime.Datetime.now? Or datetime.DateTime.now? Or DateTime.now? or dt.datetime.now?

Because it could be any of those. Some people import datetime like numpy (import numpy as np) so they can call timedelta like dt.timedelta and this is fine and everything, but the combination of no standard in python for how to do this, plus the hard to remember interfaces, plus the multiple libraries that try to do the same thing and the different way they differ in capitalization, etc. Means there is just way too much to remember off the top of your head.

In ruby it's Time.now and I never forget it and I never have to import it and that is honestly awesome. If I open a shell anywhere in any project for any version of Ruby I've used the current time is just eight chars away, and even though I love Python, that has never been the case on any Python project I've worked on and I've worked on more than a few.

Post reply on HN