4 ms·
As someone who picked Django over Rails ~10 years ago and has used it for everything since then-- I wouldn't bother. Django and Rails, like Python and Ruby, lo
by bdr 10y ago
As someone who picked Django over Rails ~10 years ago and has used it for everything since then-- I wouldn't bother.
Django and Rails, like Python and Ruby, look more and more similar as time goes on. Not because they are becoming more similar, but because the web ecosystem around them has become a lot more diverse. If you want a break from Rails, learn Phoenix! Or Node, I guess.
Furthermore, with the advent of fat front-ends, the utility of both of these frameworks has gone down in absolute terms. When they first came out, front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. (That's why channels are so important to the future of Django.)
That said, I still like Django a lot and use it all the time. I don't want to discourage you from learning it. But I wouldn't do it because you're trying to make a leap from Rails.
- rufugee 10y agoWhat a refreshingly honest answer...thank you. It's not often you see that sort of candor. I was personally a Rails guy, then switched to learning Django, but had the experience you note...both frameworks solved many problems which aren't as relevant in this age of SPAs. I suppose if you really liked Django's ORM it might be worth it, but doubt there's a huge amount of value to be gained. YMMV.
- hrayr 10y agoI suppose if the framework, community and ecosystem are on par with each other, then the deciding factor would be the language.
- babayega2 10y agoExactly. I've chosen Django because of Python.
- morgante 10y agoIn the age of SPAs, I have actually found Django with DRF to be incredibly invaluable. The efficiency of just having to specify a few models and then getting a full REST API for them with minimal effort is tremendous.
- wandering2 10y ago>front-end features like form generation and HTML templating were really important, but now they're arguably better to avoid. Why is that?
- bdr 10y agoIt's the DRY principle. If you have a single-page app, the frontend needs to know how to render everything (using JS), so rendering on your backend as well is, at best, duplicated work. There may also be complications at the boundary of those regimes, like how your frontend initializes on top of server-rendered HTML.
- brianwawok 10y agoAt most 5% of apps should be a SPA. Seems rash to pick your only web framework on 5% of apps.
- viiralvx 10y agoNot OP but I feel like it's because JavaScript has evolved enough that some of the niceties they offered before doesn't make sense. I like using Ember.js and doing client-side validations is pretty darn easy without complicated JS. Additionally, having inherited a legacy Rails project that uses `remote: true` in it's forms, it is causing more of a headache to fix these legacy issues.
- senko 10y agoValidating data should always be done on the server. You should never, ever, trust the client. That's not to say you can't do (or shouldn't do) form rendering, processing, error/success handling, etc. on the client-side, but the server should always have the last word on the validity of what you send.