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

371–380 of 490 posts

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

#371

Post by robertoandred »

qbasic_forever wrote: post #365
robertoandred wrote: post #321

Earlier quoted context omitted.

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.

That sounds like a terrible user experience.

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

#372

Post by sodapopcan »

chowells wrote: post #358
sodapopcan wrote: post #268

Earlier quoted context omitted.

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've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…

This feels pretty stawman-y to me. They are meant to be highly digestible examples of everything the framework has to offer. They can be read through quite quickly, yet people still fail to and then you have people who don't know what scopes are or reinvent ways to do enums and what-have-you just because they weren't aware this stuff exists already. If you need to drill down into a specific topic, that's what the docs and blog posts are for. Having the level of detail you describe in the guides would only turn-off newcomers even more.

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

#373

Post by dgb23 »

pupppet wrote: post #86

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.

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.

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

#374

Post by mirekrusin »

jmondi wrote: post #347
wtallis wrote: post #309

Earlier quoted context omitted.

"Best way to learn" seems too vague to have a productive conversation about. If your goal is to become proficient with a framework, then reading the docs top to bottom is probably a great thing to do, but if you merely want to hack together a one-off project over a weekend then it's probably not worth investing the time to exhaustively learn about all the features and paradigms of that framework.

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.

Programming language is not natural language, think more how did you learn math?

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

#375

Post by com2kid »

blitzd wrote: post #354
com2kid wrote: post #207

Earlier quoted context omitted.

My big problem with sveltekit so far has been how strongly it wants you to use their back end. I already have my own back end, but sveltekit is all about using their back end stuff. And their back end is 100% all in on serverless functions. If you want to write a more traditional back end and do something like grab private API keys when your service starts up, well sorry no easy way to do that, although there is an a…

You can use Svelte completely separate from SvelteKit - we've been using it for a while now and integrating with our pre-existing APIs with no issues, some of those are serverless, and some are just instances behind a load balancer.

You can, but that is obviously not a happy path the svelte devs want you to use. 90%+ of tutorials and docs out there are for doing things with sveltekit.

I eventually beat it into shape of generating a true SPA, generating paths that weren't at the root of the domain, and I convinced express to serve up assets accordingly. Took way too many days to get it working though.

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

#376

Post by multiplegeorges »

chowells wrote: post #358
sodapopcan wrote: post #268

Earlier quoted context omitted.

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've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…

The guides are great for someone doing what most people use Rails for. Recipes with some side cases are very appropriate for that audience.

If you want to know more about an API, there's https://api.rubyonrails.org and the classes are quite will documented. These docs don't show up in the guides and might be what you're looking for. I should also point out that the API docs are directly linked in the header of the Guides.

Specifically for routing, there's lots of additional detail here: https://api.rubyonrails.org/classes/ActionDispatch/Routing/M...

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

#377

Post by midrus »

yawnxyz wrote: post #68

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…

Settling with the latest newest and shiniest doesn't sound like settling at all.

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

#378

Post by ericb »

usrusr wrote: post #291
vidarh wrote: post #253

Earlier quoted context omitted.

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

Thor is gorgeous for command line apps. http://whatisthor.com/

Capybara is fantastic for automated testing

https://github.com/teamcapybara/capybara.

Gosu for 2d Games:

https://www.libgosu.org/

Example 2d game with Gosu:

https://github.com/victords/super-bombinhas

CRuby will be in browsers!

https://bugs.ruby-lang.org/issues/18462

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

#379

Post by multiplegeorges »

Jetrel wrote: post #366
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.

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…

> Unfortunately, Rails just isn't special.

This is why Rails is so good at what it does.

I don't want it to be special. I want it to be mature, work, and allow me to be productive. I have work to do!

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

#380

Post by danielheath »

chowells wrote: post #358
sodapopcan wrote: post #268

Earlier quoted context omitted.

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've skimmed the guides. They never contain anything useful. They're just a bunch of recipes. They don't actually document a darned thing. Programming is not regurgitating recipes without understanding. Copilot can do that. Programming is actually understanding both the problem domain and the solution space, and knowing how to find some permutation of elements in the solution space to address anything in the problem…

Want to know what’s available somewhere? Write “public_methods - {}.public_methods” to stdout.
Post reply on HN