![]() ![]() Front-end testing is universally terrible. I’ve set up nightwatch, jest, enzyme, cypress, and probably 5-10 other frameworks. I’ve tried to test front-end applications. But what, you ask, of words with uneven pluralization rules? Rails actually does the right thing, almost always. Rails is famous for doing pluralization - you name a model Post and you automatically get an interface called posts. This applies to a lot of other parts of the system too. Maybe impure, vaguely risky techniques are just a net positive over time, and making everything fully explicit isn’t really necessary? Now when I’m using other systems, I wonder - what if I could just mention one of my React components and it would just… be there? Sure, the system would have to complain if there were two components with the same name, and it would have to make assumptions about directory structure, but overall, wouldn’t this be nice? What if you accidentally import something just by mentioning it? What if two things have the same name and you import the wrong one? How do you really know what’s happening? Sure, you’re happy now, with all of that annoying importing and exporting taken care of, but the sky might fall. This kind of system was terrifying to me before. You mention a module’s name, and it’s automatically included, using Zeitwerk, a tool that comes standard with Rails. Our Rails app didn’t have any require statements. Rarely will you need to use puts to print something to the console because this debugging system is so good. Like the byebug interface, this REPL actually works and is consistently helpful in finding root causes. With an automatically cleaned-up stacktrace that excludes Rails’s own frames. If a page crashes unexpectedly, you get a similar REPL experience, in your browser, automatically. The whole system is paused at that moment, and you can actually interact with it, using all of the Rails utilities and your installed gems. It works in views, controllers, database migrations, everywhere. You write byebug in your source code, and you get an interactive REPL right there. This applies even to Node.js, where one of the debugging stories is to connect Chrome’s debugger to a Node.js instance: a finicky solution that doesn’t consistently work. Sure, you can learn better techniques for diagnosing and debugging errors, but it’s not just you - the debugging story in JavaScript is pretty bad. Subtle abstractions like React hooks and advanced transpiler stuff like Regenerator mean that your code’s stacktrace probably looks nothing like what you expect, with lots of internal garbage. You have to deal with code that might not have the right sourcemap to translate from bundled & minified code to original source. ![]() But throwing a debugger statement in some React code is dodgy as hell. The Chrome debugger’s automatic pause on caught exceptions is amazing, sometimes. The real reason why javascript developers don’t use breakpoints and use console.log is that breakpoints don’t workĪfter years of working in JavaScript, I’m used to bad debugging experiences. Plus, Rails-like projects in JavaScript are ramping up quickly, and it’s fun to know the origins. For their benefit, and to debrief from 2020, here are some notes on the experience. And I bet a lot of people are like that - they came of age in the world of React and Go, and haven’t tried anything even remotely similar to Rails. I won’t implement everything in Rails, but it’ll be part of the toolbox.īefore this, I hadn’t touched the stuff. Other communities could learn a bit from the Ruby & Rails culture and wisdom. Another part of the product would be the hard, innovative part, so it made no sense to grapple with bleeding-edge web frameworks. ![]() Rails fit perfectly into the ideology of Choosing boring technology. What helped Rails win was that the team had a little more experience in Ruby (with the exception of myself), and we found plenty of resources for developing and deploying the stack. There are multiple acceptable solutions to a problem, and this was more a matter of choosing the right kind of solution than pursuing some kind of perfect choice and burning hours and motivation doing the window-shopping. They’re similar, not radically better or worse. We didn’t do competitive analysis against Laravel, Django, or Phoenix. My earlier post on Second-guessing the modern web was inspired by this experience, that for the product we were building, a ‘modern’ stack was not working as well as a traditional one. ![]() I moved a project from Next.js + Rust to… Rails, baby! Back to the future. I spent most of 2020 working with Ruby on Rails. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |