Live data from Hacker News

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

reviewbunny.app

351–360 of 490 posts

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

#351
post #270

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.

Call me crazy, I’d just rather read the relevant section of code I am working on and be able to understand it from there, rather than first having to understand the entire universe.

A framework is a social contract, if you will. The framework authors are taking on the onus of some complexity to give you a cleaner and easier to grok codebase. The tradeoff is that you do need to read the guides or you will be diving deep into framework internals whenever you want to understand some app level code.

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

#352
post #347

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.

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 dictionary written in that language is both stupid and inapplicable here, so I'm not going to try to further address that aspect of your comment (especially since you don't seem inclined to directly respond to anything in my comment).

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

#353
post #346

This is exactly the problem I am facing now! I thought picking up and building things with Vue should be a breeze but boy what a nightmare its turning out to be. There is so much room for improvement in the JS ecosystem.

Have you looked at Svelte? We've been migrating over to it from Redux/React, and it's so far been a great experience. It's greatly simplified a lot of our code, and eliminated a whole lot of redux/state boilerplate.

Haven't tried Svelte yet. Do you think its mature enough? Just hoping it is a relatively less painful can of worms to explore :)

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

#354
post #102

Earlier quoted context omitted.

Agreed with everything you say here. Really want there to be a go-to Rails-like framework for JS, but nothing has reached that point yet. I'm very bullish on SvelteKit — hits all the points you mention above and outputs a minimal, performant full-stack app. https://kit.svelte.dev/ Still in beta and changing a lot but really really lovely to use. Heck, to scratch my own itch I'm even making a Rails-like SaaS boilerpla…

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.

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

#356
post #170
post #121

Earlier quoted context omitted.

Agree, and to go further (from the point-of-view of an outsider who is forced to do JS occasionally): * should I use npm or yarn? Why do I see most package authors recommending yarn when npm is the default as far as I know? * should I introduce Typescript to be able to handle complexity better? * which module system? I see lots of "require" VS "import", if it needs to work on browser/node.js/deno, which one?!?! * whi…

I think these are great questions. As someone who has been doing Golang for a couple of years and just got back to doing Node.js development again, I can answer some of these questions. I'll add that most JavaScript developers never think about these questions btw. * Should I use npm or yarn? This is one area where JavaScript is notoriously weak. As another comment mentioned, the answer might be different a couple of…

Thanks, this was helpful.

I looked at pnpm and I like it... so it's bringing the Maven strategy of having ONE place where dependencies are downloaded to and shared between projects to JavaScript!?.. which has been used since early 2000's in Java land... :D good.

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

#357

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.

tRPC is a good choice for TypeScript: https://trpc.io/

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

#358

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

The rails guides document about 10% of the problem domain. That's mostly ok, because the problem domain exists in the wider world, and there's lots of documentation elsewhere. The problem is that the rails guides document about 1% of the solution space. And that's an issue, because rails claims to be the solution space.

Rails routing is done by passing a block into the framework that's instance_exec'd on... Something. Want to know what, so that you know what API is available to you? Too bad. Here are a list of recipes for the couple most common things you might want to do. Want to do anything more sophisticated, or just understand what your options are? Uh, sorry.

Oh, you want to set and read cookies? Here's a recipe for how to read cookies and how to set them with lots of options. You changed how you're setting cookies and now browsers are returning two cookies of the same name and you want to know how to detect and fix this? Silence from the rails guides! (In fairness, the rack documentation actually included enough information to solve that. But it wasn't mentioned in the rails guides about cookie handling. And the rack documentation was a specification, not a guide. It actually tells you what pieces there are and describes their semantics.)

And it just goes on and on. Rails has about one hundred options for every one actually mentioned in the guides. In some sense that's a good thing. The guides only give you an incredibly limited set of tools. It's very good that the rest exist. But it means that the guides are a very bad way to learn rails, because they don't give you enough information to solve unforeseen problems yourself, or even enough information to understand code someone else wrote to solve those issues.

They put you in the position of hoping someone else anticipated your weird problem and already told you how to solve it. They don't equip you for solving anything weird by yourself.

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

#359

Earlier quoted context omitted.

I've interviewed a lot of web devs over the years. The distribution on this question is surprisingly bimodal. One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it. The other group of web devs has learned one very specific tool and they want to build their career around that to…

"One group of web devs is great at picking the right tool for the job. Simple web applications get simple solutions. The complex SPA solutions only get brought out for applications that require it." You could replace SPAs with almost any technology (Queues, Kubernetes, an RDMS as opposed to BaaS, Servers as opposed to lambdas) and it would be correct depending on your own background and personal bias.

at least for me, that's the difference between someone on a senior level and someone that is not on that level yet. sometimes you just need to be pragmatic and say "this should be on an ec2 server with a simple html page -- no need for a react frontend that talks to a graphql endpoint that sends message to rabbitmq so another microservice can consume it".

also, being able to accept that a simple solution is good without putting too many barriers in front of that.

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

#360
post #341
post #4

I used to write Rails professionally for many years This comparison isn't a good one. Rails is an all-encompasing framework. If you compare Rails to something like Nest.js, there's not much you're missing. Nest is one of the best application frameworks I've used in any language, and it comes with all this stuff you say JS doesn't have. --- EDIT: To clarify (because it is confusingly named), NestJS is a framework mode…

Interesting, why is Nestjs used by so many online casinos? Is that random or is there some specific feature or approach used that is particularly valuable for that use case?

Online casinos have usually been very aggressively sponsoring anything and anyone willing to take their money (and the usual reputation hit that can come with the perceived shadiness of gambling). That's especially true for newcomers who just burn as much money as they can, trying to establish a foothold. I'd say, being on the front page of a popular, credible project like that is probably sought after, hence the unusual amount of casino sponsorships
Post reply on HN