So, I'm old, and have done lots of stuff in lots of languages in frameworks. For about a dozen years, Rails was my go-to toolkit. I've written a couple dozen production applications with it. Unfortunately, Rails has really fallen out of favor lately. Even a Rails-specialty shop I worked for briefly has pivoted to using ASP.NET. I've played around in that stack, and found it lacking. (EF just doesn't compete as an ORM.) However, they've moved on to bigger corporate customers, and those places just don't use Rails.
Recently, and because of this same we-don't-"do"-Rails sentiment, I was forced into using Java for a web application. So I prototyped a site with Spring and Angular 6, thinking this -- arguably -- represents the "state of the art" when doing a Java web app. Out of frustration, I also cranked up a prototype with Rails. What was taking me literally 160 lines of Java and JS, to build two related models and a form to edit the relationship, took me 3 lines with Rails. Nothing else I've found allows me to be as productive as Rails for writing web applications.
I can understand criticizing Ruby for being clever. There are still magic tricks you can do with it I've never even tried to understand. I can understand criticizing Rails for being obscure. I realize that it took me MANY years to be REALLY effective with it. But if you're telling me the alternative for web applications is ANYTHING related to Java, I'll call you crazy.
I've just inherited a Laravel-based PHP site, which is so old I can't download the version of the framework it uses. Yikes. I did PHP for about 10 years, 20 years ago. It doesn't feel like a lot has changed.
So, I'm honestly asking, as someone who hates Rails: What framework, out there, somewhere, allows me to be as productive as Rails, but which is are "better," somehow?
I have heard a number of things like chess and go and poker described as easy to learn but impossible to master.
Rails is not like this. Rails is more like bridge where you have to learn the rules as well as this whole bidding system that fills a book before you can actually play the game.
There is no real magic in Rails, and once you learn the tricks yourself it becomes the most pleasant and productive ecosystem to work with that I've experienced. If you don't bother to learn though, it's going to be awful and slow and opaque.
By the way some of the good ideas in Ruby and Rails have made their way to PHP7 and recent versions of Laravel. So much has changed if your last PHP exposure was 12 years ago, it's not bad now.
For most parts of Rails, I agree. There is one very important one where I don't: ActiveRecord's internal behaviors are opaque enough at most levels where you care about your database to be fairly called "magic". Having to reverse-engineer ActiveRecord to make my database stop puking and to generate a make developers who know Rails but not databases not get upset that now the solution is insufficiently "Rails-y" (whether or not it is correct and whether or not it is faster than the "Rails-y" method that's causing them problems) is not great.
Fair enough, I would say that the internals of ActiveRecord/Arel/etc can be complicated but also do a lot of work. I watched a number of presentations by tenderlove and had a bit of background/interest in that area to start with. "Go watch this guy's videos about relational algebra and SQL generation" is probably not what you want to hear when there's a bug though.
By the time you've gotten there though you've certainly more than figured out how method_missing and different filename based conventions work though, you've seen what Rails is and I'd be curious to find out what you like better!
Honestly, these days? Writing my own SQL and using languages with static typing. I'll take a little longer to write code to make thinking about it easier.
I still use Ruby nontrivially for stuff like command line tools, though.
Ruby has the easiest data access tools, between ActiveRecord and Sequel (which I prefer), out there. I don't know too many folks who'd disagree with you about that. But where you're happy with Rails taking a few lines, I am as of late big on Kotlin (because I agree with you regarding Java) encouraging me to be correct. I'm building a new product using Spring Boot, Kotlin, and JDBI and while, yes, there's boilerplate - it's not the thing that slows me down. I liken it to touch typing; I don't worry if a programmer can't touch type because getting text onto a screen is never the slowest part of the process.
The thing that slows me down, as it does whenever I'm programming, is thinking, and I've learned over time that Ruby doesn't really help me with that. (A lot of other toolchains, both statically and dynamically typed--hello, TypeScript!--do.) I just don't worry about writing a query with a join - it forces me to understand my domain while I'm writing it, not when it runs and bombs out with an error because I mistyped something or got the relationship wrong in my head because my IntelliSense doesn't exist.
It depends on what you're prioritizing. I went back to the JVM for this project in part for perf, but also because I have a pretty high bar for correctness and I want to make sure my stuff works without writing in/out tests for something as simple as types.
Horses for courses.
(Also, I would submit that the frontend SOTA for "Java" is React, FWIW, same as almost anywhere else.)
The problem with boilerplate is not the typing of it (that can be automated), but the reading of it (that can't really be automated until programmers are replaced with AI). It hides semantically useful code in mountains of noise.
I agree with you about the usefulness of a language that helps in thinking about a problem, but I feel like boilerplate is a kind of tech debt we tend to underrate.
I agree with you regarding the reading of boilerplate; that's in particular why I like JDBI. It abstracts the boilerplate of building out a data access layer; you write an interface and it automatically builds the implementation from parameterized SQL queries on the classpath.
Between that and Spring Boot (which is fairly batteries-included but makes it clear when you're going off the happy path in ways I can deal with), I feel remarkably good about my choices with this and similar recent projects.
It's not just code bloat, typed languags and frameworks like spring have to dance through hoops to allow for easy testability. Spring is founded on the idea of dependency injection that's supposed to overcome that. In Rails/Python and friends you just don't need that, and consequently things have much less bloat.
...at the cost of globals all over the place and significantly fewer code-to-interface (rather than code-to-implementatation) moments.
I'd rather test a well-factored JVM or .NET application than I would any Ruby application I've ever seen in my life, to be frank. I've never, not once, had to write a mock (awful) for a test in a JVM or a .NET application, and the quality of my tests reflect that.
Yeah you just end up with race conditions everywhere causing corruption and data loss. See active-model-serializers 0.10.8 release that just found a race condition where serializers would share state across threads making the default Rails web server (puma) completely unsafe.
OK, put up. What's better for the kind of quick-to-write, developer-friendly access under discussion? Because I'd like to know; I've used a lot of the options out there.
It's true for me too. While I love ruby for its beauty and elegance, I love Sequel even more. I find Sequel to be the most powerful and most flexible tool to make RDB queries.
> So, I'm honestly asking, as someone who hates Rails: What framework, out there, somewhere, allows me to be as productive as Rails, but which is are "better," somehow?
I'm a former RoR developer (about 5 years) who's now been a full time Elixir developer for two years, so I'll make the obvious suggestion of Phoenix, which is very rails inspired.
It's a little more clunky in the basics, but it has that "magical" feel that hooked me on Rails back in the day, if you want websockets. And there's a new feature coming down the pike, called LiveView[0] that I think could be a total game changer the way Rails was.
For right now, I think of Phoenix as another rails, better in some ways worse in others, but not better enough for most people to switch. But if LiveView pans out the way I think, then it'll absolutely be the killer feature that will get new apps started in Phoenix, and it's only possible due to Elixir/Erlang's concurrency foundation.
Briefly, it takes the React data model – state at the top of the tree, render the tree based on the current state, change the state and the tree re-renders appropriately – and moves it to the server, using websockets to keep the client up to date. So every connected client has its state in a little elixir process, and interacting with the page transparently is calling functions on the server so you can update the DB or whatever with your normal server side code. And if you had a normal server-side rendered view with an `<%= if .... %>` in it, and that condition changed, then voila, that part of the page will change because Phoenix will re-render it, and send down the diff and the page will put in the new HTML.
On all the Rails apps I've worked on we've inevitably added a bit of React here or Angular there to make certain pages a little more dynamic, and then exposed an API for those to hit, and then had frontend and backend development to do. I think what LiveView will provide hits the sweet spot for most apps, so you can stay in your comfortable backend language and get a bit of dynamism for free.
Sounds nice, definitely not a game changer, the way websockets wasn't a game changer. I think being real time can be easily achieved with existing tools and it's somewhat overrated anyways.
It's not the real time nature that makes LiveView a potential breakthrough, for me, but the additional category of interactivity it gives between "server side rendered" CRUD app and full SPA. Most apps in this zone are probably using jQuery or sprinkling in react, the former of which gets pretty messy and buggy in my experience, and the latter of which is overkill and leads to a much more complicated build system and developer environment.
It uses websockets, and I think websockets are probably necessary to implement the feature well, but that's not what I'm excited about here.
I've been using Django for the last three years and no, it's not Rails. It's a very light framework and you're almost on your own for many decisions. More like a router, a test framework, an ORM and templating language put together than a cohesive framework. Easy to end up with something totally different in every project you look at. On the other side all Rails projects look alike, which is much better when taking over from previous developers.
By the way, Django's inflexible templating language kills productivity (templatetags, as with Java 15 years ago) and the ORM is (how to say it kindly?) lacking in elegance. Django's Model.objects.get(pk=1) vs Rail's Model.find(1) is the least of the problems but I'm short on time now. Because (sarcasm on) we might get confused if we omit objects, what could Model.get possibly mean? (sarcasm off)
Everything in Python seems over engineered as if only very large projects are going to use it, and Django makes no exception. Still, I'll take Python and Django all the times over Java and any of its web frameworks. My personal rankings are:
Ruby/Rails > Elixir/Phoenix > Python/Django >>>> Java/* > JavaScript/* which doesn't have any serious server side framework. I have little direct PHP experience but I'd put it between Python and Java (I managed the developers on medium sized Zend project years ago.)
As somebody who was a Rubyist for about a decade but has worked at a Django shop for several years now, I definitely see how they're similar, but I don't think Django is clearly the better of the two. Django is simultaneously less helpful (you have to do more things explicitly, such as specifying routes) and less flexible (for one example, Django doesn't have a public query builder and doesn't have a replaceable ORM — you're basically stuck with either the built-in ORM methods or SQL strings).
For me personally, Rails is the best web framework I've seen — but in an age when static typing and other static guarantees are increasingly popular, Ruby as a language is not what people want. It's an artifact of the old Lisp and Smalltalk school of thought.
Where is the evidence, outside Hacker News, for this increasing popularity of static typing? The fastest growing languages by most metrics are currently Javascript and Python, both of which are dynamically typed.
According to GitHub's 2018 stats, the two fastest-growing programming languages last year were Kotlin and TypeScript. GitHub explicitly pointed out that "type safety" appears to be one of the biggest factors influencing language popularity in 2018. And even Python, the fastest-rising dynamically typed language, has been adding new static typing features in every release for the past three years. The last new Python app I wrote was fully type-annotated and typechecked, and the new data classes feature actually requires type annotations.
python has mypy types and most places are switching to typescript over javascript. If you work with more than a handful of developers (and as such on a project large enough to require them) not having types DRASTICALLY decreases productivity.
Do you have anything to back-up you claim about "most places"? Most of the job ads on Indeed.com/.co.uk for Python and Javascript make no mention of Typescript or mypy.
Django has a lot going for it in terms of simplicity but it lacks most of Rails' advanced features and timesavers. In my experience it sits somewhere between Sinatra and Rails
Also, having to deal with Python packaging is a world of hurt. No thanks. There's about 16 ways to package and distribute Python, and they all are half-complete and a royal pain to deal with. Ruby's packaging isn't perfect, but it's a thousand times better than any of the Python packaging solutions out there.
Package management is a hard problem, but we know that good and adequate package managers do exist. I'm not sure why more effort hasn't been expended by the Python community, particularly since it's often the first thing a new user will encounter when picking up a language for the first time.
I use Pipenv currently, but only because it's the best of a bad lot and would jump in a heartbeat if a serious competitor came along. It has its own set of problems (slow, young and idiosyncratic) but offers me at least two things its predecessor didn't: separation of production/dev dependencies and seamless integration with different versions of Python, both of which have been available in Ruby since I started programming in it.
This is a perfect exemplifies my experience with both languages: I have found while Python might be better at a lot of things, the user experience is invariably superior with Ruby efforts and I wish the Python community would put more effort into this area.
Good question! When I worked at the Rails shop, we had a standard Gemfile which we started with. It had way too many things in it. Some of the absolute requirements would be to start with 'better_errors', 'letter_opener', 'haml-rails', 'simple_form', 'devise', 'cancancan', and (probably controversial, but my favorite) 'cocoon' (i.e., the thing that makes nested models take so little code). You can probably throw in twitter-bootstrap too, but...
Also, I'm still using RVM. I never made "the switch" to rbenv; I never saw the problem with RVM.
MySQL vs PostgreSQL doesn't matter to me. I've done a lot of both. And Oracle. And SQL Server. I've never seen a problem with using any database with ActiveRecord.
Starting a new project, I just install the latest, stable Ruby, install the bundler gem, then grab the latest, stable Rails, add the basic gems, bundle, and start letting rails generate the basics.
I'm bootstrapping my projects with Vue support, because I think that's the JS framework that fits most-nicely in Rails, and there's always a presentation-heavy page that needs that kind of treatment.
(I'm assuming a Mac or Linux here. I've done this on Windows for a time, but WSL has changed the game there, and I've not actually tried to use it in anger.)
Just read through https://guides.rubyonrails.org/ Unlike the sibling comment I suggest staying away from additional gems as much as possible especially if you're a beginner. Do things the officially blessed Rails way and you will run into the least amount of problems. All gems that try to 'fix' something in Rails will often have downsides of their own and can cause hard to debug issues in corner cases.
Recently, and because of this same we-don't-"do"-Rails sentiment, I was forced into using Java for a web application. So I prototyped a site with Spring and Angular 6, thinking this -- arguably -- represents the "state of the art" when doing a Java web app. Out of frustration, I also cranked up a prototype with Rails. What was taking me literally 160 lines of Java and JS, to build two related models and a form to edit the relationship, took me 3 lines with Rails. Nothing else I've found allows me to be as productive as Rails for writing web applications.
I can understand criticizing Ruby for being clever. There are still magic tricks you can do with it I've never even tried to understand. I can understand criticizing Rails for being obscure. I realize that it took me MANY years to be REALLY effective with it. But if you're telling me the alternative for web applications is ANYTHING related to Java, I'll call you crazy.
I've just inherited a Laravel-based PHP site, which is so old I can't download the version of the framework it uses. Yikes. I did PHP for about 10 years, 20 years ago. It doesn't feel like a lot has changed.
So, I'm honestly asking, as someone who hates Rails: What framework, out there, somewhere, allows me to be as productive as Rails, but which is are "better," somehow?