Totally understand about Django, Laravel etc. but typically if I'm building in Node/JS I'm pulling all of that extra stuff in from npm piecing it together myself.
[1] - https://nodewood.com
I find that having to dig to find out how things are done and trying to hack around the framework is the cause of bugs and frustrations.
I still manage two services based on Django and they're a continue cause of pain.
I'd rather spend a week at the beginning of the project and set things up the way I want them with minimal dependencies. Then evolving things is fairly easy, just a matter of skimming through the code.
Same.
The only time that I've gone away from this strategy is when I need to get other developers to buy-in to a framework (or hell just a "system of work"). In leadership roles, I've found that a highly-opinionated framework with lots of batteries included really helps keep people coloring inside the lines. For me anecdotally that's more important than having a low-dependency codebase that's very appropriately sized to the problem it's solving.
I've found it's way easier to dodge the inevitable "X way sucks" from my colleagues/subordinates by using "full framework" tools that I can pitch to non-technical management vs. a bespoke solution.
Batteries included frameworks solve people problems more than they do software problems.
---
Just want to reiterate that I absolutely agree with you and the only time I find tools like Django appropriate is when other developers need tooling that keeps them "in the lines," and/or when I'm expecting to have to pitch my solution to non-technical peers/leadership.
Me too. I don't use create-react-app or anything else to set up my Node.js/React/TypeScript/SWC projects. I install each package I need manually, and configure each item precisely how I want it (tsconfig.json, webpack.config.ts, .swcrc, even .eslintrc.json). Makes for a nice, lean project every time.
The benefits of frameworks is that there's shared knowledge on how to use it, lots of documentation and they are more battle proven.
There's a reason people are not writing assembler. Reinventing the wheel every single time has its trade offs too.
There term has definitely become more amorphous and ambiguous. I spent a few years mostly working with physical hardware, networking, virtualization, scripting deploys for DBs and OSs, and handling the DNS alongside some business oriented C#. Then I moved over to working with AWS and Azure.
Now I primarily work with Node, Golang and Python.
With modern tooling and a team that supports it, I've found myself mostly working on services, APIs and React front-ends. Even with Next.js, it's hard to know where the line on what "full stack" is.
It's sort of come to encompass the frontend and backend of an application, less so the architecture of it. Mentally, however, I still lump it all together when I think of what qualifies for "full stack", as I personally think the term represents an understanding of how everything works together, which definitely helps when troubleshooting the source of a problem.
> But again, that's just me confused about what is "full stack"
Me too because it's grown into an amorphous definition =/
You should check out Fastify.
It does solve a lot of stuff for you. Either included in the core or with official plugins.
To me, "full stack" would entail having responsibility for logic on both the front-end and back-end, which Fresh does.
Personally, I would not consider Laravel a full stack framework (Although it can work well with front-end frameworks to make a full-stack application). Instead I'd consider it a back-end framework.
To me Laravels is pretty more close to a "full stack" framework than Fresh to be honest.
> I think that having by default a pretty awesome templating system (which even allows for components), a webpack based build system for frontend assets
Fresh literally does that "by default" without having to include any library/dependency.
> easy way to serve, cache and bust assets, and a trivially easy way to submit forms and validate user input.
It's almost the same effort in Fresh.
> makes it pretty full stack
Define fullstack, but even defining it, Fresh totally covers what you said.
To be "fullstack" to me means to be filling in all stacks, being in web? Frontend and Backend. To me, having a templating system and having things rendered in backend can be "frontend", but you saying "Laravels is pretty more close to a fullstack framework than Fresh" is not something very logic here.
You need to ship at least a few MBs of JS to prove you are a real frontend engineer.
Normally it's used this way to describe a job, but that meaning has circled around and is now used to describe libraries/frameworks too
You could have something incredibly intensive on the front end using a bunch of modern frameworks and visualization tools. Or something incredibly intensive on the back end with some of the features you mentioned in your post. But neither is strictly required and many apps will function with just the basics on either or both ends.
But, when I think of a "all in one" / "full stack" langauge, there needs to be an existing ORM inside the framework. That works across the View/Communication/Model.
These frameworks have you needing other tools to do this.
When I hear of a full-stack framework (in a modern setting), I think of stuff like Meteor, Redwood, and Wasp-lang (disclaimer: I am one of the authors of that one). RoR also always comes to mind, although it's more commonly used as an API server nowadays.
Today, I have the opposite impression. Nowadays everyone is a react tool who want to learn backend so they can call themselves full stack.
People see react, Facebook and their eyes turn into dollar signs.
Rails, Laravel, or Django are completely agnostic about the frontend side of the full stack though :-) Well, maybe Rails will have an opinion about Stimulus; but this fresh thing continues the journey after the response has reached the client.
My productivity with Rails 7 and Turbo has never been higher.
I don't think Django counts as full-stack, as you don't have a default front-end framework, like Rail's Stimulus.
If you get to ignore threads/forks and number of workers as well as memory management of them because it's someone (or something) else's responsibility, then that's not full stack. The stack is OS (slightly, and can often be ignored), webserver, application, and client (HTML/JS). If you hand off responsibility of any of that then it isn't "full".
The term originally came from referring to people that handled all these things. You could be a back-end developer, dealing with the OS and webserver and maybe application, front-end developer where you dealt with HTML, JS and maybe some application code, or you could do both and be a "full stack" developer.
Aren't those back-end frameworks? I always undestood full-stack to mean "front-end + back-end".
There's enough confusion here I suppose I'll start using the term "batteries included framework" for the technologies you listed.
However... it's definitely closer to what I want "full stack" to mean than... this. Or a pile of bash scripts.
Most other frameworks don’t include things like websockets and Web Push notifications, as well as support for WebRTC, payments etc. So where do you draw the line?
For me "full stack" is something like Rails, Laravel, Django, etc.
Or is it just being able to run code on the server enough to be "full stack"?
I'm missing the translations system, the validations, the background jobs, the authentication system, authorization helpers, email sending, ORM or data access layer, testing framework, CSRF and related security protections, logging, error handling framework, etc, etc, etc.
To me that's a "full stack" framework. If just running code on the backend and on the frontend is enough, then I can make a bash script a full stack framework, right?