Readit Newshakunin commented on Please just try HTMX pleasejusttryhtmx.com/... · Posted by u/iNic
For those who build in Ruby on Rails, does htmx have an advantage over Turbo/Stimulus? For me, the sense that it doesn't is why I've been avoiding it. Prefer to stick with vanilla stack unless there's a very compelling reason not to.
hakunin commented on Working quickly is more important than it seems (2015) jsomers.net/blog/speed-ma... · Posted by u/bschne
I like to say that you can either learn to be fast at doing low quality work, or learn to be fast at doing high quality work. It’s your choice really. But the only way to learn the latter is to start by prioritizing quality over speed.
hakunin commented on Don't Build a General Purpose API (4 Years Later) max.engineer/server-infor... · Posted by u/hakunin
Some of you might remember an article from a while back titled "Don’t Build A General Purpose API To Power Your Own Front End". This is a follow up to share how things played out, answer additional questions, and help figure out, discuss, or debate anything else that might have come up based on my advice that not everyone agrees with.
This used to be a blog comment service. It looks like the domain name registration expired yesterday, and nobody seems to be responding to support (likely the email under the same domain is not even working). If the owner decided to abandon the project, I would at least like to get my data export (and ideally partial refund too).
hakunin commented on Lowtype: Elegant Types in Ruby codeberg.org/Iow/type... · Posted by u/birdculture
First time I hear about this, I really like your guard approach. It's just quite plain ruby.
I'd be interested in hearing your opinions on other runtime approaches like contracts.ruby, literal.fun and LowType of course.
Appreciate it.
I wrote this controversial thought[1] once, but for what it's worth, it applied to me just as much as to anyone else. Projects like these type gems are incredibly fun and satisfying to build. Your vision is clear, you've seen types before, you're proficient enough with Ruby to do clever things. The work seems cut out for you. Go nuts!
Problem is, these kinds of solutions (I also see this in "service objects" world) take Ruby away from you, and offer you a whole new vocabulary. With time I started appreciating libraries that avoid solving a problem that plain Ruby can solve, because Ruby is incredibly clear and concise already. If you leave more opportunities for people to write plain Ruby, you will solve everything with much less library code.
I think that's where the fun of building goes against the end developer experience. Builders love "owning" everything. E.g, "No, don't write `&&`, I have a special way for you to compose types!"
These are general thoughts, but I'm happy to get concrete with specific examples too.
hakunin commented on Lowtype: Elegant Types in Ruby codeberg.org/Iow/type... · Posted by u/birdculture
I love it, I liked what dry-initializer and dry-struct do, and I wanted something similar but simpler than RBS or Sorbet.
I tried once myself to implement something like lowtype, but without success.
I built portrayal[1] (a much simpler replacement for those dry libs), and was also experimenting[2] with runtime-enforced types based on this lib.
My general thoughts is that declaring types in Ruby is unnecessarily complicated, because you're basically just running values through pieces of boolean logic, and nothing else. Might as well make that explicit, which is what my experiment did. I didn't however publish the types library, but the concept was proven.