Live data from Hacker News

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

reviewbunny.app

361–370 of 490 posts

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

#361
post #275

Earlier quoted context omitted.

If you want to make an app from scratch, you must first understand the universe. This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.

> This is a ludicrous approach for most. there are about 35 guides in the rails guide list and half of those are digging deep into the framework... reading the first 10 of them would get you about 95% of what you really need to know in rails so that you can look up stuff later. hell even just doing the getting started guide walks you through a fairly complete rails application. https://guides.rubyonrails.org/

yah, that's what i did when i first got into rails (~3.0/3.1): read 5-10 of the guides while working through michael hartl's tutorial and reading/watching a number of railscasts (which are dated now, but still have good basic info).

i'm working (slowly) on a personal project in rails 7 using all the hotwire with importmaps newness, and so far, it's been so much better than recent rails' diversion into all that node/yarn/webpacker mess.

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

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

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

#363
post #300

Earlier quoted context omitted.

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

>The great thing about the web is that you are allowed to do this.

The truth is that for desktop(no idea about iOS or Android) I can also customize things as much as I want and I can do it faster and get better results. Desktop GUIs can give you pixel level access so you can have a button that plays a video inside it and rotates around while jump[ing and changing opacity.

About the Web I don't want to remove the option for everyone to invent their own menus if they want, I wish Mozilla,Google and Apple provide native options or as a stand alone library that you optionally include in your project.

For SPA this browser makers could colaborate to provide a standard framework, optional to use but would have all the basic features, bugs fixed and security updates, but it would be done by professional developers not as a side project by some Google dev with 0 experience in GUI toolkits.

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

#364
post #135

Earlier quoted context omitted.

Remix feels a bit like Ember routing, but with SSR and React.

I think almost all modern SPA routers took a lot of lessons from the Ember router to be fair.

I wish!

While I liked the React approach to UI modularization much more than that convulted MVC interpretation Ember had, Ember's routing was quite awesome, and I missed it switching to React.

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

#365

Earlier quoted context omitted.

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.

So you have to wait for a page refresh any time you do something on the page?

Yep, it's like every other MVC or server side framework. You can still send client side JS for interactivity, and these days there are small jquery-like micro frameworks like petite-vue, alpinejs, stimulus, etc. that are made to sprinkle in interactions where necessary. If you want the smooth SPA-like experience there are systems like hotwire or htmx which effectively hide all the page reloading.

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

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

The problem with RoR is that it's an all-encompassing framework. It gives you a huge collection of things you typically don't need — entire major layers like the database are frequently completely irrelevant to projects. This isn't just true of small projects, but can often extend to a large part of a career.

One of the grave dangers that older/wiser programmers have learned is to stop trying to pathologically "drink the entire river". Programming has a constant deluge of new frameworks, tools, and publications coming out, and it's easy to fall into the trap of thinking you need to know, well, everything. I know a lot of 'aspiring programmers' who accomplish next to nothing precisely because they waste most of their time reading about programming instead of actually practicing it. It's sadly rather similar to 'aspiring writers', or any other craft — some reading is helpful, but not when it crowds out the actual task it's meant to teach. Life is short, and you have a choice between "actually making things" and "doing prep work for making things". That's all reading the docs is — it's just prep work. It's completely useless unless it parlays into actually accomplishing things.

There are semi-rare cases where some language/framework is actually teaching you new fundamentals and is worth deep-reading to gain core skills as a programmer. Haskell broke new ground. Lisp was enlightening. Smalltalk was a worthy historical study. Rust is genuinely changing things. Unfortunately, Rails just isn't special.

When I was considerably younger, I used to pathologically do this — I used to buy books on programming, and read them like a school textbook "exam cram". I read entire books on languages (like Perl) that ended up exiting the zeitgeist before I ever did any work in them — and I now have no reason to do so (I feel sorry for Perl, because Larry Wall seems like a cool guy, but perhaps it's a testament to its influence on other languages that it no longer has uniquely redeeming features). I even read books on various applications. Naively, at the time, I looked at learning as a pure, unalloyed good — rather than a dangerous spend of lifetime I'll never get back.

I deeply regret wasting that time on that instead of learning a meaningful skill.

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

#367

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

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…

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.

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

#368
post #347

Earlier quoted context omitted.

Did you learn English by reading the dictionary top to bottom? I’m gonna go ahead and guess that no, you didn’t. You learned English by being surrounded in it and practicing.

You're being strangely combative in this thread, as though you are personally offended by something. What's your problem, and why are you letting it drive you to make such weak arguments? Do you have some past trauma related to being forced to read, or is it just bad experiences with Rails specifically? It really doesn't take more than a few seconds to figure out why your analogy of learning a language by reading a d…

You’re right, I apologize. You are right that my analogy is stupid on a bunch of different levels.

I’ve been surrounded by so many rails fans who use it for every possible problem. “If all you have is a hammer, everything is a nail” was the epitome of what was happening. Then being left with trying to sift through old versions of documentation, trying to figure out what is the “current” way of doing things in rails vs the previous ways, aye yi yi. Rails has definitely left me with a sour taste in my mouth.

I’m not saying rails is bad, it is great in so many situations. I’m just saying it is not a silver bullet, and the cult behind it has some real blinders on.

I stand by my original argument though that for most people, reading documentation top to bottom isn’t the best way to learn. If it works for you, great.

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

#369
post #197

Earlier quoted context omitted.

Have you noticed a difference depending on when they got into web development/whether they trained for it? One thing I'm noticing as I'm looking for tech jobs as a tech person who hasn't ever been a tech employee before is that a lot of the job listings are very heavily tool focused. I wonder if newer/junior devs are reacting to what the market is presenting (as you hinted at with 'The more complex they can make some…

Junior dev here (but a career changer at aged 35), I initially learned Ruby/Rails at bootcamp 80% of the market is looking for some React + backend and there's a huge pressure to learn such an SPA framework but I've steadfastly refused and have stuck to 'full-stack' Rails. Luckily there's a resurgence going on for Rails and I think it's going to last. Boring always wins in the end

I'm your polar inverse: I'm 33 but started coding when I was 4, I've just never worked as a developer (at least not on a team; I've done freelance), and I'm debating making the jump as inflation starts creeping up. I run into the opposite problem: I've played around in frameworks but I don't have the 'years of experience' with them so I worry my resume is going straight in the trash.

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

#370
post #275

Earlier quoted context omitted.

When people ask me how to improve their programming this is my first advice - speed read docs/stdlib top to bottom and keep writing a lot of little things. It’s amazing how many people choose painful path of learning through osmosis.

If you want to make an app from scratch, you must first understand the universe. This is a ludicrous approach for most. Sure, if you learn from reading and love to read technical manuals, go for it. But to imply this is the best way for most to learn is completely ridiculous.

You don't need to understand universe, just the tools you'll be using to make an app.
Post reply on HN