Scaffolds are a dead end. Learn to work without them as quickly as possible. Idiomatic modern Rails code is simple and lightweight and doesn't require boilerplate.
The full scaffolds yes, but the generators are really nice. Like so many things in programming, the real value is for those that don't need it though. Yes, I could cd into the models directory and create the test file and then jump out and create a matching one under app. Or "rails g model User name:string"
The scaffold boilerplate did a lot of extra work, but didn't seem to overstep its bounds with extra code too much. Does Rails encourage me to eventually complexify the application's routes and methods to a point that the scaffold won't make any sense at all?
It's not so much 'any sense' as it is that you aren't always going to need all 7 basic routes/actions, and by that point, it's overkill, and possibly a security hazard.
So does idiomatic modern rails not use generators? I believe the way to begin a new rails project is with the command "rails new {insert project name} ", which umm....generates a ton of boilerplate code.
He didn't say anything about generators, just boilerplate, which is what scaffolding does. Most other generators are quick, easy and don't generate boilerplate.
There's a bit of Rails terminology that you'll need to understand in order to grok what's going on here. Rails has two distinct commands: generate and scaffold. Generators create files with very basic contents. The scaffold command generates files with contents that fit a "typical" use case. Scaffolds aren't used much once you know what you're doing.
Well, development speed has always been its primary selling point. The reason folks like it is because "Here is common task that you expect to take two hours, and in Rails it's 2 lines of code and you're done."
It's pretty damn awesome to spend all day writing business code rather than support code.
> It's pretty damn awesome to spend all day writing business code rather than support code.
One-thousand times this. I've had some headaches with gems (chronicled earlier), but if you're building an app with minimal add-on gems then development speed is incredibly fast compared to other frameworks.
You're still in the "not-yet-over-the-hump" phase, but my experience with Rails has been that you'll hit this point where it all just clicks, and suddenly you're off to the races.
It's fun to see you chronicle your journeys from the perspective of someone totally new to the language and framework. Please keep it up.
I am by no means a Microsoft fan or Windows developer, but if auto-generated code is that big of a deal to the author then he really needs to spend some time playing with Visual Studio...
Rails generators create the code you would write anyways. The MS generators created technical debt. Highly duplicated, ridiculous inclusions, questionable formatting and regions by default. It literally generates a code sample of what not to do if you want to write good code in C# (presumably VB as well).
ASP.NET MVC is really lights years ahead of other ways of building .NET apps, and is conceptually close to Rails in many ways. (Alas, its backstory is very OSS and un-Microsoft)
Some of the generators for MVC are getting closer to rails. They are still pretty painful. T4 templates (commonly used in some of the nicer generators from nuget pacakges) requires EntityFramework. Furthermore, the templates themselves are very temperamental to create (tabs are not adhered to, nor spaces).
The real reason rails generators work so nicely is that most of the components are known. MS pushes entity framework hard, but it isn't included by default. If you don't know what IOC is being used you cannot generate a controller. If you don't know the ORM, you cannot generate a model. Don't even get me started on the fact that most of the community doesn't even use either of those two.
Auto-generated code is great - I'm more questioning if it's causing learning gaps when people try to move to languages that don't have the community or commonality as Ruby/Rails.
Ruby seems to be an anomaly in that you can pretty much obscure away the hard parts of building a web application, but have it still be programming. If a programmer starts with Rails, does that impact their ability to eventually go on to other things?
Actually, I started with Django, then got pissed off because trying to twist Django around to do something non-traditional gets messy fast. webapp2 is spartan by comparison and makes you do more extra work, but at least you know what you're getting into because you have to write a lot of it yourself.
I use Django to do all kinds of "non-traditional" stuff (key-based API authentication, automatic object-level caching, custom form fields, using Postgres features such as UUID fields and fulltext search) and none of it took me that much work. But then, I've been using Django for a few years now and know the ins and outs quite well.
I can see how you'd be enticed by a simpler framework such as webapp2 or Flask as a starting point. But I've found that Django is as flexible if you just consider that most of the built-in features that Django provides (even the awesome ORM) are optional if you know what apps and middleware to disable.
> if you know what apps and middleware to disable.
And when I was learning Django, I didn't know this. I moved to webapp2 because I could put only what I wanted in an application. I'm sure that if I sat down and re-dedicated myself to learning Django like I'm doing with Rails, I might have a better time at it the second go-around.
Yes, I know. It took me a long time to understand Django the way I do today. A great starting point was James Bennett's 'How Django processes a request' blogpost [1]. From there you'll see how Django is just a tiny wrapper calling a bunch of increasingly complex applications that build on top of each other.
There should probably be a chapter on the tutorial with a simplified version of that. It'd help newcomers understand where everything fits.
In any case, I'm glad you found a tool that does what you need as long as it isn't written in PHP :P
Django provides a set of tools and a unique methodology for creating apps. Overall, you end up writing less code in a djnago app in order to do more, for that reason, it requires greater understanding of the framework.
For simpler frameworks, they require less understanding but greater amount of code, which may end up being more complicated.
I, personally, used to do it all by myself as a PHP developer, where I wrote raw sql queries and handled the raw HTTP request. Once I figured out ORM in django and its custom templating system, everything becomes so much less code and easy to implement.
So let me get this straight. You didn't like Django because after not taking the time to learn it, you couldn't get it to do what you wanted. So you switched to a very lightweight model (webapp2), and loved the learning curve and flexibility. And then you tried out Rails (about as Django as you can get in terms of steep learning curve and having to contort to do non-traditional things) and loved it.
Nothing in that logic adds up. And for the record, I've yet to do a "traditional" web app in Django. Having taken the time to learn it inside and out I get all the benefits of flexibility that I would with something like Flask/webapp2, but retain the convention and mindshare for the rest of the project that does fit into common usecases.
As I stated in an earlier comment, I would likely have a different experience with Django now. Django was the first framework I attempted to learn, so I'll wholeheartedly admit that some of that was inexperience with web applications (started programming with non-web VB and Java).
I could write much of the same post and have it apply to Django as well. Django is designed to abstract away work, which means that it's difficult to really see what your application should be doing if you don't already know. If you've learned how to manage user authentication manually, you can appreciate and tweak what Django/Rails are doing. If your first experience with a web framework is having Django manage all of that for you, then you have no idea how to tweak it or debug it.
Ultimately, this is not a Django versus Rails debate - I just used my current Rails experience and prior Django experience as anecdote. I can't claim enough knowledge of Django or Rails to even advise someone on which to learn; all I can do is talk about my own experience and raise questions.
I started programming python with webapp2 also, after coming from a php, java, and node.js background. I found it to be a bit more low-level and manual as far as frameworks are concerned, but I discovered that to be enjoyable. While it did force me to write a bit more scaffolding, request, and model/caching code I know that I have a MUCH deeper understanding of the frameworks works as a whole and communicates end-to-end. It might have forced me to do more work initially but I find now that I have a deep knowledge of the framework (not just it's APIs and methods) I am able to iterate faster and stretch and bend the framework to work outside of it's traditional modeling - very much unlike other similar frameworks I have worked with in PHP/node.js
Have you tried any web development with Django? Under some light, it may be helpful to develop an app using webapp2, but normally you want to abstract most of it away.
Django has done it very nicely. I encourage you to explore it for it may save you countless hours you may end up spending in future.
interestingly enough, this is how i felt when going from rails to python/django.
i felt like i had much more control and the admin section really sold me.
rails always felt a bit "too magical" for me. I could get anything done, but I didn't know why or how. I didn't feel like I was getting much better as a programmer. With Python, I felt like I was getting better after the first day.
I started to love Rails because of this and I still do. I get my bread and butter with Rails and I love my work because of it (and of course for the challenges). Four years and counting...
One of my biggest annoyances though is the really REALLY hard upgrades between different Rails versions. 2.x to 3.x was several days project including testing etc. 3.0 to 3.1 or 3.2 adds the nice assets pipeline, which of course might brake some javascript if you have lots of legacy there.
A minor change in ActiveRecord (and minor Rails upgrade) changed the behaviour to use SHOW INDEX instead of describe before loading data. The result was hazardous. So when you start to have lots of traffic, be very careful when upgrading Rails itself. And read the changelogs and the diffs.
I would honestly rather have this than the situation with python and django. While its awesome they're supporting python3 in 1.5 that took longer than I'm comfortable with.
What I've learned with rails is that the minor version you start a project with should stay the same for the sake of your sanity, until after project completion. Concerning yourself with incremental improvements should be avoided until you are between major versions of your own codebase.
When I first started Rails I too was impressed by the scaffold generator. Now, as a more advanced Rails developer, I find myself only really generating Models, Migrations and Resources. View and Controllers are almost entirely written from scratch. As per the point about the speed of development - I found that I continued to get faster and faster as I started to understand the configuration magic of Rails and how to harness the power of gems as part of my workflow.
I must admit that Ruby on Rails was the first web framework I learned. Since then, I have dabbled with Python's Django, PHP's CakePHP and even Express on Node.js. What I tend to find is that other MVC web frameworks seem to be imitating Rails - so rather than use a follower I just stuck with the leader, Ruby on Rails. Until there is a much better alternative (looking at you Meteor/Node.js frameworks) I will be a happy Rails dev.
Scaffolds show you the conventions, and its up to you to expand from there.
You quickly end up having to push the boundaries of what scaffolds can do for you as you work on the finer details of a project.
I'd also like to give credit to bundler for making my life simple and saving me from dependency hell. It was a life altering experience coming from .jar file management to meet the magic of bundler.
Django too seems to make things specially hard for beginners, I'm not sure why that is. I don't mean the getting started part, the doing something useful by yourself part after the tutorial.
I think Django's 'sin' is trying to create an almost production-ready CMS when you invoke startproject. The default project comes with authentication, admin, CSRF protection, sessions, content types... the whole nine yards.
Maybe there should be a second option "barebones" that created a settings file with most features disabled by default (yes, even the Admin.) Users who just needed a simple WSGI-compliant framework could start from there instead of figuring out what stuff to disable. You'd basically be on pair with Flask, with the advantage of having access to the advanced features just by dropping stuff in your INSTALLED_APPS and MIDDLEWARE_CLASSES settings.
I don't see django as a cms or production ready thingy at all. It might generate some default settings but everything else you build from the ground up.
IMO, Django's great if you want to make something regularly published (i.e., blog, news site, etc.). But you have to get creative quickly if you want to do something else.
I eventually jumped to doing more webapp2, and I know there's a devout Flask community as a Django alternative. Haven't played with enough Flask to say anything yea or nay for beginners, though.
I have built real applications in rails and django, and find them to be fairly similar in philosophy and power.
What would be an example of something you encountered with django that required getting creative quickly, that rails handles more routinely?
For me, the trickiest thing in either ecosystem to get a handle on was probably rspec. I tried to learn it by osmosis and that was probably the wrong way to go. In the end, it's worth having a DSL for writing tests and leads to nice clean readable code.
When people are trying to learn rails, I point them to Rails 3 in Action and Michael Hartl's online tutorial, but still need a better reference for learning rspec. suggestions are appreciated.
> and I know there's a devout Flask community as a Django alternative
Really? Tell me where the Flask community is.
I actually regretted my decision of choosing Flask over Django after 2 months of working with it precisely for that very reason.
You can find tons and tons of tutorials, docs, writings about best practices from others, crowded IRC discussions, etc. for Django -- not so for Flask. But maybe I'm mistaken? I'd love it if you clue me in as to where all the Flask people are hiding.
The way I see it, Flask is a library, while Django is a framework. Flask only serves to handle requests. Flask doesn't impose a design architecture on the webapp, which makes it a great way to turn any module into an online API.
On the other hand, Django's 'batteries included' philosophy means you can deploy a generic CMS application very quickly.
josephmosby: In my comments to your previous article I said that my efficiency in Rails smokes my efficiency in everything else.
Now you know why. A lot of people zeroed in on your admiration of scaffolds - I really liked scaffolds when I first started out too, but I don't use them very much anymore. The other features of Rails that you will eventually discover are equally fantastic, and much less controversial
