For junior developers reading this: frameworks are great, but they will become an increasing source of technical debt, performance loss, and frustration. They will allow you to ship your first version faster, but every release after that will become harder. Not that it wouldn't be hard without a framework either, but frameworks make us feel that we need to work within their constraints rather than the constraints of our application and our users.
So learn a framework for whatever language you use, that's useful! But also learn to recognize when you are working against the framework and would be better served with a few libraries that you can combine in the way that you need. Frameworks optimize for certain use cases and expectations, and if your project is no longer aligned with those, it's probably a good idea to think about an exit strategy.
However maybe also learn to love a language that embraces them at the same time so you don't come away with a poor experience because of only trying a language that has poor frameworks (Go, JS/TS, etc).
Definitely try something like Python + Django, Ruby + Rails, Java/Kotlin + Spring to get a feel for what a mature framework can really do.
Then if you find you still don't like frameworks and the style of programming associated with them then sure, find a home in one of the ecosystems that are more inclined to roll it your own way.
Frameworks certainly aren't for everyone but using bad frameworks and then pretending all frameworks are therefore bad is highly prevalent among more recent developers. Try the good ones and then make up your own mind.
Also, this shit is harder than it seems, and it is painfully easy to introduce huge vulnerabilities if you don’t know what you are doing. SQL injections, CSRFs, etc can all be a problem if you go down a naive route.
I was fairly new to "modern" web dev, starting a project, and went with Django because I had more Python experience than anything else. But I found templates very lackluster and poor to integrate with all the different JS ecosystem libraries people are creating to do very cool things on the frontend. Unfortunately, hooking React up to Django is a mess and most people doing this are still 5 years behind in React-land. Are you going to hybrid some template and some React? Are you going to containerize your django and react build system together?
Basically, I wanted a robust frontend ecosystem, well integrated to a simple backend (no Spring, Django-Rest-Framework monstrosities).
That led to React -> Next.js -> Typescript backend -> the rest of the niceties around it like Prisma (ORM-ish)
Create T3 App simplifies all the setup into a template and is extremely fast to start building features. No js build system setup, no python virtual envs. tRPC is an optional nicety.
I don't like using frameworks but I feel this comment is really important. I spent years using frameworks in other languages. Understanding why things are structured the way they are and what works for my needs and what doesn't.
Also when working with a team the value of having a lot of documentation, stackoverflow questions a google search away and an obvious way of doing things seems incredible valuable.
Does building your own microframework brings joy and a sense of accomplishment? yes it does. Does that correlate with accomplishing business needs. Not necessarily.
How about offering real counter advice instead of just saying its bad advice?
Going to have to also agree with the OP. Frameworks are great for the majority of real world cases. There are definitely cases where specific optimizations are required and maybe a framework is not best fit but those are rare.
Lets try to steel man your disagreement though. Having worked in larger orgs I believe there is a trap that some fall in when using frameworks. Ignoring what is happening inside of the plumbing of the framework and ignoring why the framework is doing it. From that perspective you can fall in the trap of not having mastery of domain and it can limit your career in the long run.
On the otherside my argument is that frameworks provide immense value to orgs of all sizes. Even for a single person team there is value because you are not wasting your time on problems that are not part of the business. You should understand how the framework works in the long run though. A lot of these patterns carry over between frameworks and languages, mastering your first one will open a lot of doors in the long run.
"Wasting your time on problems that are not part of the business"
How much time?
Sometimes a task that takes X time and seem unrelated to your "main" task, actually increases your productivity when doing the main task.
A prime example is sleeping when trying to build muscle and lose weight.
On a surface level, sleep is a waste of time: you should be in the gym lifting weights or out there running/cycling/swimming. But actually no. Sleeping improves your results, and improves your performance on your workouts.
I'd argue there's a similar dynamic here.
Working on the lower levels of your problem might seem like a waste of time, but it's actually not. If nothing else, you feel more enjoyment from your work. Being engaged with what you do and not being engaged is huge.
Another problem that often occurs when you are always only working in the "high level" is you have no idea how to do anything well unless the framework does the heavy lifting for you. As soon as you step outside of what the framework was designed to help with, you are lost and have no idea how to approach the problem. All your approaches are half-assed solutions. You see this every single day on "big teams".
For junior developers reading this: frameworks introduce additional complexity (especially ones with obscure dependency injection), learn how to use different tools properly and analyze when they should/should not be used. Learning your language properly (and carefully selecting when a framework makes sense vs when it doesn't) will save you much time and stress when shipping real products.
There's a time and place for framework/no framework, though I'd err on the side of not introducing a huge framework until it's actually needed.
Source: I work on a real, shipped for 3 years, SaaS product primarily written in Go (multiple services). The primary applications are framework-less, but some of our operators make use of kubebuilder (which certainly would qualify as a framework).
For junior developers reading this: frameworks are useful if the tradeoffs they make are right for your current situation. They are good tools when used wisely. However, developers who are heavily invested in a specific framework will often try to sell them as "great" but recognize that their investment biases them and may result in "when all you have is a hammer, everything looks like a nail" syndrome, causing these one-trick ponies to advocate their favored framework even in situations where other frameworks or even no framework is a more sensible solution.
- Start with SaaS Pegasus https://www.saaspegasus.com/
- Deploy to Heroku
- Get comfortable with "X-in-HTML" frameworks - Tailwind, HTMX, Alpine
- Deliver your mobile app as a PWA https://web.dev/what-are-pwas/
Not surprisingly, this is also the stack I'd recommend for a solo developer, though I will also sprinkle in React as it makes sense (not as an SPA / decoupled app, but instead embedded in Django as I describe in the JS guides).
Also, I'm pretty agnostic on CSS. Tailwind is nice but I'd use it with a UIkit (Pegasus uses https://daisyui.com/) or TailwindUI. I also think Bootstrap, Material and Bulma are totally fine options if you aren't interested in laying out everything with your own flexes and grids.
Happy SaaS Pegasus customer here! Reasons to love it:
- Cory’s writing on low JS alternatives to single page web apps was game changing for us. And that’s all built in. 10x faster to develop.
- You get access to a wonderful community of Django devs. Any question gets 3+ independent responses.
- The framework is non-opinionated. You get the same examples in both HTMX and React + APIs, many versions of CSS frameworks (Bulma, Tailwind, Bootstrap), multiple deployment methods, etc. This gives you a valuable toolkit to fit your solution around the needs of the problem.
Currently we have 14 destinations available for use.
Salesforce, Hubspot, Intercom, Google Ads, Mailchimp, Google Sheet, Sendgrid, Marketo, ActiveCampaign, Kafka, Customer.io, Google pub/sub, Mixpanel, Rest API.
Many of your integrations talk about “syncing” rather than event collection, which to me sounds like what Fivetran is doing. Does that distinction make sense and how are you thinking about that?
We call it "push" (you send event to Jitsu) and "pull" (Jitsu pulls data) integrations. Technically speaking, push integrations are outnumbered. But that's because we took advantage of other open-source projects (Airbyte and Singer) to implement them.
Our core is push integrations, that's the most complex part of the system. We see "pull" integrations as an additional feature that helps to enrich the data after events made it to DHW
+1 for SaaS Pegasus. In particular, Cory has done a wonderful job in introducing a more pragmatic approach to Javascript with Django [0]. Plus he's built a strong Slack community and is always around to support and listen to any feedback.
We re-built our SaaS product using this boilerplate and wrote about the experience [1]. TL;DR: would recommend!
+1 For this recommendation, an exceptional book. In particular chapters 2-3 demystify how databases work, and provides an intuition on when to use different kinds of databases and query languages without the typical hype (spoiler alert - use an RDBMS!)
We recently started working with "traditional" Django + Hotwire + React wrapped into web components for interactivity.
We've previously tried React+Hasura/Postgraphile and React+DRF/GraphQL, but this is next level productive and a joy to use, and bugs are rare. Particular love for Django CBVs.
> I was surprised that you didn't advocate for using traditional server-rendered HTML for views that don't require significant frontend interactivity/client-side state management?
I don't know that there's one best choice for how to render the front end. I generally like Angular because it's strongly opinionated, and in general, strong opinions in software leads to faster velocity and lower TCO. But I don't think that Angular is the universal best choice.
I do however think having the front end powered by a REST API is 100% the right move, because it draws a line in the sand where if private data or incorrect data are getting returned then there is clearly an issue. Having a specific place (the JSON response) where you can write tests against is a huge win, one big enough that imho it outweighs every possible disadvantage of REST.
To be honest, I was surprised that you advocated writing so many tests for each view, easily 10-20 per view.
Part of the beauty of Django's various class based interfaces is that you can be confident that if you add a validator to a model field, then it will be validated by the corresponding ModelForm in the corresponding CreateView.
But then again, you advocate against OOP in python including CBVs. If you do write all your endpoints as functions, it makes more sense you need to test it because it's easy to forget to include a line of validation or whatever it is.
FWIW I love the fact that various Django classes are like DSLs. DSLs are less powerful by construction, so less buggy. It is almost like using low-code. But I do see your point about tracking inheritance and control flow, it can be a challenge at scale.
i'm currently trying out https://turbo.hotwire.dev/ which is a new library from the basecamp guys, which makes it really easy to create SPA feeling sites with rails, using little to no javascript, and in a very unobtrusive, intuitive way. i'm guessing it's going to be an integral part of the upcoming rails 7 release.
