51–57 of 57 posts
Earlier quoted context omitted.
react_on_rails is even better.
Not really. Depends completely on what you need. Not integrating with your existing asset pipeline isn't necessarily a plus depending on what your goals are. There's also a weird amount of self promotion going on with that repo. Not sure what it is about that but it's kind of been a turn off to me.
Slightly off-topic: is learning Rails still a good career choice? I'm not particularly keen on JavaScript on the server and I think I am slightly tired using .NET on a daily basis.
There are plenty of stable companies out there running Rails apps and I'd venture a guess that a lot of start-ups probably still use it as it's great for small teams and rapid-prototyping.
On a side note, we also have hired devs who don't have Ruby experience but who are generally smart, experienced people, who know more than one programming language and are willing to learn whatever stack they need to for getting the job done.
How is Rails still doing in the world of NodeJS, Microservices and React?
Slightly off-topic: is learning Rails still a good career choice? I'm not particularly keen on JavaScript on the server and I think I am slightly tired using .NET on a daily basis.
Earlier quoted context omitted.
Interesting, my experience is the opposite: liberal use of ruby's dirty tricks often makes code hard to understand and thus debug.
That's a separate statement, and they are not contradictory. Using Ruby's dirty tricks on shipped code -> hard for debugging/understanding. Using Ruby's dirty tricks while debugging -> boon. The grandparent didn't claim the former to be false, only the later to be true.
Still I plead guilty to having occasionally monkey-patched prod code out of urgent necessity. My recommendation is to view it like an advanced and undesirable form of configuration; for my rails apps, each such hack always goes in an initializer file named for the library it is patching. If you are replacing third-party methods (or undermining the behaviour of a third-party method) and those methods are not called very frequently then judicious use of log noise e.g. through the deprecation mechanism will help at debug time.
Earlier quoted context omitted.
> IMHO these fixes address dozens of bugs that could cause major puzzlement for a typical Rails developer. That has been the reason I always avoid huge frameworks like RoR. If I was to hit a bug like this, I wouldn't know where to start debugging. How do people deal with obscure bugs in the framework with something like RoR?
> That has been the reason I always avoid > huge frameworks like RoR. For others it is the reason to use huge frameworks like RoR. Because alternative is to hunt obscure bugs in the framework you built yourself.
Anyways, I unfortunately work with Rails and I hate it. To me Rails stresses and encourages bad practices, everything has an implicit environment inherited from a massive hierarchy of classes with their own implicit environment that will only work if the current state of the app matches what each classes assumes it will be.
Data changes and morphs during the initialization and creation of class instances causing shitty bugs. EVERYTHING needs careful consideration of all of these relations and class hierarchies before writing simple things.
Everything is highly coupled and interwoven making a change one place break something somewhere else. Rails should be taught in Universities as a case study in the pitfalls of Object Oriented Design
Also essentially all of the major players have left and moved on to new things. Most Ruby Gems haven't been updated in years!
How is Rails still doing in the world of NodeJS, Microservices and React?