Every Django/Rails app with any significant business complexity I've worked on has been quick to start but becomes more and more difficult to change over time. The reason Rich Hickey's "Simple Made Easy" talk hit so hard for me was precisely the pain from working with Django apps (and Rails to a lesser extent).
It's nice to get started on a project quickly, but often that quick start is purchased at the cost of a system that is tied together in such a way that it's very difficult to change. Human beings naturally prioritize short term benefits over long term benefits. But developers have a responsibility to their employers / clients not to pick something that makes the dev's life easier in the short term by significantly raising the cost of adapting to changing requirements in the long run.
My life has been a lot simpler since I've moved away from Django to Clojure. It's less evident in weekend projects or in the first few months of a project. But I never find myself saying to a client request "unfortunately, the way Django works, it's hard to [retroactively produce reports/get the state of the application at previous point in time/fix application logic then correct a corrupted table/upgrade just by bumping version numbers/use multiple databases/not systematically overwrite data/etc]."
Yep, that's true, should have clarify that I was talking more about fire and forget CRUD apps (small business stuff).
OTOH, there a huge companies with successful rails(github,airbnb)/django(instagram) apps, but maybe they get away with it because the have big teams to re-architect anything.
What is your preference to interact with databases in Clojure? hugsql, honeysql, clojure.java.jdbc ?
Adept with JavaScript and Python. Recently, I've been working mostly in full stack JavaScript using Meteor and React.
Some previous projects:
- Lead creation of a platform to facilitate transfers of patients between hospitals on contract with Signal Health Partners. (https://signalhealthpartners.com)
- Lead creation of an athlete management system that uses established sports science protocols to gauge athlete readiness. (www.pycoach.com)
- Revamped a college application platform front-end to handle complex logic based on user input
- Quite a few projects patching up old Rails applications.
I'm a full stack web developer. I'm experienced with React, Angular, and Backbone. I enjoy full stack JavaScript, but I've also worked with Django, Flask, and Ruby on Rails. Big fan of Meteor.js.
I've worked on SaaS products in a number of fields: law (have a law license), sports science, education, and medical/health. I do work as an individual freelancer, and I have two other developers I team up with to scale to larger jobs.
SEEKING WORK - Remote - Lexington, KY, Louisville, KY, and Cincinnati, OH - USA (EST)
We are two freelance full stack developers who work under the aegis of Ventre Tech. Our primary interest is in developing MVPs for startups, and we have a particular interest in the health and sports spaces.
Languages: JavaScript, Python, Ruby. Web Frameworks: Meteor.js, Django, Flask, Rails, Angular, and React.
A recent project: PyCoach (https://www.pycoach.com), an athlete management system. Primarily a platform to collect data about athletes and chart that data to coaches and trainers. Built with Django on the backend, Angular on the front, Gulp and Webpack for the build system.
We are two freelance full stack developers who work under the aegis of Ventre Tech. Our primary interest is in developing MVP for startups, and we have a particular interest in the health and sports spaces.
Languages: JavaScript, Python, Ruby. Web Frameworks: Meteor.js, Django, Flask, Rails, Angular, and React.
A recent project: PyCoach (https://www.pycoach.com), an athlete management system. Primarily a platform to collect data about athletes and chart that data to coaches and trainers. Built with Django on the backend, Angular on the front, Gulp and Webpack for the build system.
It's nice to get started on a project quickly, but often that quick start is purchased at the cost of a system that is tied together in such a way that it's very difficult to change. Human beings naturally prioritize short term benefits over long term benefits. But developers have a responsibility to their employers / clients not to pick something that makes the dev's life easier in the short term by significantly raising the cost of adapting to changing requirements in the long run.
My life has been a lot simpler since I've moved away from Django to Clojure. It's less evident in weekend projects or in the first few months of a project. But I never find myself saying to a client request "unfortunately, the way Django works, it's hard to [retroactively produce reports/get the state of the application at previous point in time/fix application logic then correct a corrupted table/upgrade just by bumping version numbers/use multiple databases/not systematically overwrite data/etc]."