Earlier quoted context omitted.
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
Don't make me think, or why I switched to Rails from JavaScript SPAs
451–460 of 490 posts
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#452Earlier quoted context omitted.
> it's better to take the less opinionated road (SPA in this case), so you can be more specific later Can you elaborate on this a bit? Are you saying that an SPA with React (+ other server-side pieces in NodeJS?) would have been the better choice than the Rails + some React mess you wound up with? What about sticking with just Rails, no React? Thanks for your time.
Yeah, SPA approach would separate the frontend and backend conceptually to different microservices. Frontend is served separately off CDNs, backend isn't involved with it. When frontend team decides on a different framework/approach, they can switch, and the frontend just consumes the backend API. Backend focuses on building an API, doesn't have to deal with templates etc. The other server side piece doesn't necessar…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#453Am I the only one who simply looks at the business requirements when considering an SPA? Ive built music players, games, real-time chat apps, etc that would be very difficult or impossible with a server side rendering app.
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…
I like to see myself in this group. The problem is, however: requirements creep. Especially when consulting. The customer doesn’t know the full extent of their needs, and they always want more and more. Which in the end often invalidates the initial decision of «going simple and lean». Then you’ll have trouble explaining why incremental changes start to take so much time.
So I think there is some merit to the approach of getting really good at a particular powerful and generalizable set of tools (even if they have flaws, such as not being lean, a bit complex, and shipping more JS to the client). I think that’s why React and NextJS’ is so enormously popular, even though they’re overkill for most sites and webapps.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#454Earlier quoted context omitted.
Programming language is not natural language, think more how did you learn math?
By having stuff demonstrated by a teacher and then repeatedly solving small problems. Not once did I read a textbook front to back.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#455Google 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…
I would suspect searches are overwhelmingly weighted to beginners to a particular environment.
Advanced users just move their searches from Google to the reference docs page.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#456Earlier quoted context omitted.
No - typing is still basically a complete after-thought in Rails. Sorbet is trying, but it's... not there yet (although getting better).
If you want typing in Rails, you're in reality itching to try Crystal lang and most likely Amber framework. Much faster too as it's a systems language.
But Crystal has around 468 open bugs at the time of writing :(
https://github.com/crystal-lang/crystal/labels/kind%3Abug
Issues are well over 1k…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#457Earlier 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…
E.g. for ORMs ActiveRecord which is Rails default is in my opinions nowhere near good enough compared to e.g. Sequel, and there are several others.
Sometimes those projects involve wrapping stuff - including Python - or porting Python, but most of what I use is pure Ruby.
With respect to Python, to a lot of the Ruby community Python is in many ways the antithesis of what we want in a language. Python looks horrendous to me. It matters - I stare at code most of my day. If I were to switch languages, Python wouldn't make the shortlist even. It's not that I think Python is objectively worse, but subjectively to me it's unreadable and messy and I can afford to avoid using it most of the time.
EDIT: To expand on some of what I use or have used Ruby for: web dev with Sinatra and Padrino (my main reason for avoiding Rails here is that most of what I do is mostly API driven, and because I prefer Sequel as the ORM), financial modelling (I work for a VC), my text editor of the last few years is written in Ruby (but not packaged up to be useful for others yet - I'm gradually splitting parts of it out into gems, though), DevOps by generating terraform, service orchestration (proprietary pre-Kubernetes orchestration of containers and vms across on-prem, colocated, managed servers and VPSs split between openvz, docker and KVM), system to auto-deploy replicated sets of Postgres servers with logs and backup dumps automatically distributed to a Ruby storage service (pre-RDS, and running on the aforementioned orchestrator), PDF generation, messaging middleware, scraping, large scale crawlers, trading bots. And many more.
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#458Earlier 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#459What 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…
Re: Don't make me think, or why I switched to Rails from JavaScript SPAs
#460What 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…
Been working with Rails close to a decade now. I've built several, non-trivial products using Rails for the API, by myself. What I and my coworkers dislike about Rails is the sheer amount of magic. Oh and concerns, let's not forget that pattern. Rails is amazing at standing up a CRUD app (really API) in a matter of minutes. I can have a basic CRUD app with authentication, authorization, API, caching, background jobs,…
And your dismissive comment attempts to imply that I haven't done "real" work with Rails, but I can assure you that, with 25 years of professional development experience, 13 of which using Rails as my primary stack, I have integrated with many legacy systems, and I find Rails works really well for that, actually. And, while I admit there's usually a place or two in an application to have to "shell out" to hand-coded SQL -- and even more tellingly -- that's usually some of the most-important functions of the application, it's hardly a reason to throw the baby out with the bathwater.