DEV Community

Cover image for Could Blitz.js be the next big JS framework?

Could Blitz.js be the next big JS framework?

Simon Pfeiffer on August 16, 2021

It can seem like every few weeks there's another new game-changer when it comes to JS frameworks, but Blitz.js boasts some powerful features that...
Collapse
 
ivan_jrmc profile image
Ivan Jeremic

Just wanted to mention you can in Nextjs also access your db from your conponents.

Collapse
 
flybayer profile image
Brandon Bayer • Edited

Not like in Blitz. In Next you have to use getServerSideProps or getStaticProps (those also work in Blitz) which isn't actually "in your component".

In Blitz, you can use queries and mutations from anywhere in your tree, not just the top level page hooks mentioned above.

Here's more details on the differences: blitzjs.com/docs/why-blitz

Collapse
 
ivan_jrmc profile image
Ivan Jeremic • Edited

I mean sure blitz needs to have a bit more if its a framework built on top Nextjs. But in general in nextjs it works in the root components.

Collapse
 
juberjj profile image
Juber Nunes

Very nice article. Not my cup of tea, zero API layer and monolith approach can really be a problem.

Collapse
 
flybayer profile image
Brandon Bayer • Edited

We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.

That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!

And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.

To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.

Collapse
 
arizonatribe profile image
David Nunez

Most apps should not start as a monolith. However the first time a senior engineer is attempting to grok microservice design patterns, definitely they should go that route of decomposing monolith into microservices. Training wheels aren't needed forever unless they're doing a poor job implementing those patterns, training/selling their teammates on it, or failing to convince their bosses on the efficacy of microservice architecture.

If that's the case, monolith away: let the team balloon around that beast, increase the cost of technical debt, increase the ramp-up time for new engineers, slow down & formalize those release cycles & code freezes, and let's party like it's 2011!!

Thread Thread
 
imthedeveloper profile image
ImTheDeveloper

Microservices is a pattern to solving a particular problem. It's not the hammer for every nail.

Collapse
 
hashiromer profile image
hashiromer • Edited

I think the title is a bit misleading which is inviting some unwarranted criticism. Blitz.js is not a framework comparable to Next js, Gatsby or Svelte kit. It is sort of a starter kit for SAAS apps so it is not meant to replace these frameworks. It is meant to quickly scaffold a SAAS web app with batteries included.

Regarding the monolith vs microservice architecture, microservices are not inherently better than monolith. When finding product market fit, we need a monolith architecture to rapidly make sweeping changes to codebase which would be extremely difficult with a microservice based architecture.

And this is what Martin Fowler has said about the topic.

"1) Almost all the successful microservice stories have started with a monolith that got too big and was broken up

2) Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble.

This pattern has led many of my colleagues to argue that you shouldn't start a new project with microservices, even if you're sure your application will be big enough to make it worthwhile. ."

martinfowler.com/bliki/MonolithFir...

Collapse
 
flybayer profile image
Brandon Bayer

Blitz is not a starter kit. Blitz is a full-on framework meant to replace Nextjs, Gatsby, etc. Blitz is a fork of Nextjs that adds many fullstack power features and has a much more open governance structure than nextjs. For the foreseeable future (as long as the blitz community wants) we are merging in all new nextjs releases.

Collapse
 
hashiromer profile image
hashiromer

I don't see how can it replace application level frameworks like Sveltekit or Next.js since Blitz comes with a lot of decisions baked in and a lot of features some apps might not need and require customized functionality which would be easier to build with application which is not monolith.

Thread Thread
 
flybayer profile image
Brandon Bayer

comes with a lot of decisions baked in

Not accurate. One of our foundational principles is "loose opinions". We have recommendations for most people, but it's easy to ignore. There's almost no decisions we have baked in.

a lot of features some apps might not need

You can say this about anything, including Javascript itself. Not a great argument my friend :)

Blitz is literally way better that you are imagining :)

Thread Thread
 
hashiromer profile image
hashiromer

One of our foundational principles is "loose opinions". We have recommendations for most people, but it's easy to ignore. There's almost no decisions we have baked in.

How can something be monolith and have loose opinions/coupling between subsystems? Both of them cannot be true simultaneously.

a lot of features some apps might not need

You can say this about anything, including JavaScript itself. Not a great argument my friend :)

Yeah, it is not a good argument, that is why I didn't make it :) . I made this comment within the context of a monolith framework. If it contains many features, necessarily there must be tight coupling between subsystems at some layer to provide a more cohesive experience. I think this is actually a tradeoff we need to make.

Secondly you kind of misquoted me probably by mistake, this is my full comment which makes more sense given statement that comes after and.

a lot of features some apps might not need and require customized functionality which would be easier to build with application which is not monolith

Blitz is literally way better that you are imagining :)

Probably, but I am not a fan of React, this is the primary reason for me not using it, its not your fault though. I think React is a sane choice for a lot of people due to its vast ecosystem.

Collapse
 
drmacsika profile image
Nsikak Imoh

The fact that this article promotes having a monolithic app as against API is problematic. Where does blitz stand in the future of micro services and severless architecture? How do you integrate it with a headless CMS?

Collapse
 
flybayer profile image
Brandon Bayer • Edited

We believe most apps should start as a monolith. In the early days of an app, fast development speed and getting users is way more important than having a perfectly, infinitely scalable architecture from day 1.

That said, Blitz already greatly improves on monoliths like Rails because Blitz can be ran serverless where each API endpoint is its own serverless function. So it's already serverless ready!

And over time we will be making Blitz more powerful, flexible, and well suited for enterprise environments and more complex backend architectures.

To clarify, there is an API, it's just abstracted into a compile step. So there's some magic there, but it's very minimal and easily inspected.

And you can integrate with a headless CMS in exactly the same way as any other React or Nextjs app.

Collapse
 
karanpratapsingh profile image
Karan Pratap Singh

I've been following Blitz since I watched it on Prisma day 2020, glad that it has come so far. Personally I find it really cool to quickly prototype apps and get things out there without worrying about setting up db, css-in-js stuff etc

Only issue I have is that it's another framework on top of already a "meta-framework" on top of React, so two layers of abstraction make it quite tightly coupled but that's not the issue Blitz team is trying to solve (I think)

But overall, it's a really cool project!

Collapse
 
flybayer profile image
Brandon Bayer

Thanks Karan!

We are transitioning into a fork of nextjs, so it'll no longer be three frameworks deep :)

More details here: github.com/blitz-js/blitz/discussi...

Collapse
 
karanpratapsingh profile image
Karan Pratap Singh

Nice!

Collapse
 
dillonraphael profile image
Dillon Raphael

I released a SaaS starter for blitz 1upblitz.com

I’ve made 2 SaaS products with blitz and it’s safe to say blitz is the most productive framework.

Collapse
 
berkerd profile image
Berker Demirer

I don't get why people worried over monolithic architecture for early stage startups. Do you really want to implement all kinds of enterprise application architectural patterns for an idea that you would like to ship to market as fast as possible? I really don't want to create a seperate Node.js server and do all of the configurations for different environment. Why do I need that seperate REST layer if I only have one FE to communicate and what I do is basically a CRUD app? I think it really depends what you are trying to achieve but I will definitely give it a go to this framework. I have some side projects in my mind and I want to ship them as fast as possible, I don't really care about scalability at this point.

Collapse
 
arizonatribe profile image
David Nunez

You lost me and (probably) others at "Ruby on rails inspired..."

Collapse
 
dillonraphael profile image
Dillon Raphael

It’s what sold me.

Collapse
 
jjhiggz profile image
Jonathan Higger

What about rails makes you uninterested in blitz?

Collapse
 
jjhiggz profile image
Jonathan Higger

I haven't tried blitz, but I love the idea of a batteries included framework for Javascript. Coming from a rails background, even just the niceties of a framework having backend preferences( database, ORM, testing libraries etc...) could be a huge win for productivity.

I've always liked Javascript more than Ruby, but I also like Rails more than _____. <-- left blank intentionally

Collapse
 
xunnamius profile image
Bernard

A framework on top of Next.js itself? And we're already so far away from the metal as it is :) I can't see a real advantage to adopting Blitz.js yet, but I'll keep an eye on its progress.

As for "microservice vs monolith", Next.js after version 9 (and really the whole serverless movement / JAMstack in general) really obviates the whole debate in my experience. And with Next.js 11, Atlas/DynamoDB/Firebase/Headless CMS, and Vercel/AWS Lambda/Azure Functions, whatever remaining delineation between the two evaporates. Modern Next.js apps can be deployed as a "monolith" (e.g. npx next start) or as a series of managed microservices (e.g. npx next start with custom server) or as unmanaged serverless functions in the cloud (e.g. npx vercel) with little cognitive overhead.

Then again, maybe it's because of my prior experience with FastCGI Process Managers; I'm used to building backends (both monolith and distributed) that handle each request as a short-lived isolated process with any shared/persistent state pulled from some database (hello, PHP).

Collapse
 
khrisl33t profile image
kHRISl33t

I don't know to be honest, a framework that was built on top of another is not really a good thing in my opinion.

You mentioned in other comments that "every app should start as a monolith" is not really my thing. If you start as a monolith in a startup and it starts to grow insanely you won't have the time to refactor everything and you end up with a mess no one wants to touch. Been there, done that. :)

Also, I think learning a new framework is more time-consuming than using an already established framework or library in an early stage of a product.

Nowadays everyone tries to support or design the structure to be scaleable and to be honest with an experienced team, it's not time-consuming at all. I would not spend much time to learn yet another framework just because I can quickly prototype an MVP, which no other person will understand and it won't scale in the long run. I like to give myself the opportunity to not shot myself in the knee a few months later. If you follow good design patterns, that matters the most and will save you some headaches. Libraries or frameworks will come and go..

Collapse
 
flybayer profile image
Brandon Bayer

What already established framework or libraries do you use to build a new app?

Collapse
 
danielballardp profile image
Daniel

I really fail to see the point in just adding another abstraction layer on top of an already tried&tested framework such as NextJS and selling it as a completely new framework.. plus the monolithic approach doesn't sell too well to corporates in the age of cloud scaling and microservices.. sure, startups might give it a try to get to speed ASAP to secure some funding rounds to survive, but i doubt Blitz is here to stay in the long run.. just my 2 cents, would love to be proved wrong..

Collapse
 
hasnaindev profile image
Muhammad Hasnain

Thanks for writing this article. At this point, I don't really think we need or care for a new framework. They all look and perform the same. Just a few KBs and milliseconds of difference. Blitz must be nice but I'd never know because I'll never give it a try.

Collapse
 
vladi160 profile image
vladi160

It is based on NextJS, but with a custom server: blitzjs.com/docs/what-is-nextjs

Collapse
 
flybayer profile image
Brandon Bayer

Yep. And we are now in transition to be a fork of Next.js.

More details here: github.com/blitz-js/blitz/discussi...

Collapse
 
netlancer profile image
Ellie

Yeah, seems like one of the best modern fullstack tools out there, two thumbs up !))

Collapse
 
atharvaahankarahvad profile image
Atharva Shankar Ahvad

should i try

Collapse
 
jjhiggz profile image
Jonathan Higger

After a week with blitz I freakin love it. I know there might be some concerns with like "Hey only X people use this", so I'm really hoping blitz explodes in popularity like it deserves to.