3 ms·
A lot. For personal projects, I'm going with RoR (though I'll be giving a shot at Phoenix in the near future). Sometimes I also miss static type checking and ma
by Pmop 6y ago
A lot. For personal projects, I'm going with RoR (though I'll be giving a shot at Phoenix in the near future). Sometimes I also miss static type checking and many other things Java enforces, but I feel compensated when I don't have to compile/recompile when I change something small. JUnit is faster, but RSpec looks better (just have a look at it). About template engines, HTML/ERB is the default but you can use HAML, or even better, Slim. I don't think there's something similar to replace Thymeleaf with. About ORM, I have mixed feelings, Active Record feels too magic, but this magic enables you to easily integrate your models with the database and not worry much about it. Finally, securing Rails applications is pretty straightforward. Rails doesn't bring in by default something like Spring Security for authentication but the Devise gem is good enough in this regard. IMO, Bundler and Ruby Gems is better than Maven/Maven Central. Also, IMO, when comparing major dynamic and interpreted languages, Ruby has the best OO model, Python feels lacking in this regard.
In general, IMO, RoR is about going fast while producing a good product in the end, and having enjoyable experience in the process. RoR is great for prototyping, but its good enough for a final product too. Java/Spring is rock-solid and time tested, feels better suited for really big projects with really big teams, as Java strictness and verbosity begins to help instead of eating productivity.
For my average web development needs, RoR is better, at least for now.
- tomerbd 6y agoTake an average personal project you created how much time would it take you with Java/Spring Vs RoR taking into account you know both?
- The_rationalist 6y agofeel compensated when I don't have to compile/recompile when I change something small. This is the biggest argument I see. but RSpec looks better The modern stack would prescribe kotlin instead of java, as such you would benefit from Junit idiomatic Kotlin wrappers which use beautiful, declarative custom DSLs such as https://github.com/kotest/kotest/blob/master/doc/styles.md https://github.com/kotest/kotest/blob/master/doc/styles.md I wonder if RSpec looks better than that I must definitely take a look at active records Vs spring data + JPA/hibernate Ruby Gems is better than Maven/Maven Central. but is it better than gradle with groovy or kotlin scripts? I lack experience in alternatives but to me, spring has well thought abstractions and could be unmatched in that regard if we consider the compromise of simplicity / expressiveness and code reuse - decoupling Does the lack? of dependency injection in ROR is missing? I also think opinionately that Kotlin is the best/cleanest statically typed language out there. In addition to all of that, I strongly feel that the JVM libraries ecosystem is by order of magnitude the most complete / mature / well though / with the most human resources, ecosystem to exist. Even the js/ts platform which has more registered packages than maven central has I think packages of far lower engeenering quality. As an example, the apache foundation (valuated at 20 billions dollars[1]) is unmatched. [1] Iff I remember well
- mercer 6y agoI'd definitely encourage you to look into Phoenix. For many things, Rails might still be the better option. The ecosystem is larger, for one, and it's perhaps a bit easier to 'grok' because it's OO. And I suppose an argument could be made that if you need help, it's easier to find Rails developers or resources (although Phoenix does suprisingly well in the latter category). But if you're thinking of building projects that involve real-time functionality, whether just websockets-style stuff (Phoenix Channels), or full-on apps (Phoenix LiveView), I'd say the stuff that Phoenix offer are worth the downsides of a smaller, younger, functional-programming ecosystem. Also it never hurts to learn something different :).