Blitz.js is a new Javascript framework for building monolithic, full-stack, serverless React apps with zero data-fetching and zero client-side state management.
Background
Technology follows a repeating cycle of bundling and unbundling. Created in 2005, Ruby on Rails became a major bundling force, making web application development easier and more accessible than ever before. This benefited everyone, from those learning programming to seniors building production systems.
A major unbundling happened in 2013 with the release of React, a hyper focused rendering layer without any opinions for things like styling, state management, and routing. As React grew in popularity, so did the choices for all the other parts, leaving developers with hundreds of decisions to make when starting a new app. While this has contributed to JavaScript Fatigue, it's been a powerful driving force for rapid frontend innovation.
Now, in 2020, is the perfect time for another major bundling. Developers are yearning for an easier, simpler way to build web applications. Beginners want a guiding hand for building a robust app, and seniors want a framework that removes mundane tasks while providing a highly scalable architecture with all the right escape hatches.
Hence the creation of Blitz.
What is Blitz For?
Blitz is for building tiny to large database-backed web applications (and in the future, mobile apps). It's not for building extremely large web apps, like Facebook.com. It's not for building content sites, although you can easily add fully static pages to a Blitz app so you don't need a separate host for your marketing site.
Foundational Principles
- Fullstack & Monolithic
- Backend API Optional
- Convention over Configuration
- Loose Opinions
- Easy to Start, Easy to Scale
- Stability
- Community over Code
1. Fullstack & Monolithic
A fullstack, monolithic application is simpler than an application where frontend and backend are developed and deployed separately. Monolithic doesn't mean it will be slow or hard to scale to large teams. Monolithic doesn't mean there isn't separation of concerns. Monolithic means you can reason about your app as a single entity.
2. Backend API Optional
Choosing React for your view layer should not force you to build a backend API. Usually you only need an API to get data to your frontend, unless you need a public API for third-parties or a mobile app. It's extremely expensive to build and maintain an API that's only used by your frontend because it adds a lot of unnecessary complexity, making development slower, maintenance harder, and deployment more complex.
In a Blitz app, you write server-side controllers for all your CRUD operations. These controllers have direct access to your database. You connect them to the pages that need that data, and then Blitz automatically and securely gets your data from the backend controller to your frontend components. You don't make any client-side fetch calls, deal with global state management, or mess with client-side data caching. Mutations work in a similar fashion.
You develop Blitz apps similar to a traditional server rendered framework like Rails, but the end-user experience is as a React Single Page App.
If at some point you actually do need an API, you can easily add a GraphQL API with auto generated resolvers. Or if REST is your jam, you can add that to your Blitz app instead.
3. Convention over Configuration
When starting a new app, you should be able to immediately start developing core app features instead of spending days to configure eslint, prettier, husky git hooks, jest, cypress, typescript, deciding on a file structure, setting up a database, adding authentication and authorization, setting up a router, defining routing conventions, setting up your styling library, and all the other menial tasks for initial app setup.
Blitz will make as many decisions and do as much work for you as possible. This makes it lightning fast to start real development. It also greatly benefits the community. Common project structure and architectural patterns make it easy to move from Blitz app to Blitz app and immediately feel at home.
Convention over configuration doesn't mean no configuration. It means configuration is optional. Blitz will provide all the escape hatches and configuration options you need for bespoke customization.
4. Loose Opinions
Blitz is opinionated. The out-of-the-box experience guides you on a path perfect for most applications. However, Blitz isn't arrogant. It totally understands there are very good reasons for deviating from convention, and it allows you to do so easily. For example, Blitz has a conventional file structure, but, with few exceptions, doesn't enforce it.
And when there's not consensus among the React community for a thing, blitz new will prompt you to choose the approach you want, such as Tailwind CSS, Theme UI, or styled-components.
5. Easy to Start, Easy to Scale
A framework that's only easy for one end of an application lifecycle is not a good framework. Both starting and scaling must be easy.
Easy to start includes being easy for beginners and being easy to migrate existing Next.js apps to Blitz.
Scaling is important in all forms: lines of code, number of people working in the codebase, and code execution in production.
6. Stability
In the fast-paced world of Javascript, a stable, predictable release cycle is a breath of fresh air. A stable release cycle ensures minimal breaking changes and ensures you know exactly what and when a breaking change will occur. It also minimizes bugs in stable releases by ensuring features are in beta for a minimum amount of time. Ember is the model citizen in this regard.
The exact details of the Blitz release cycle are to be determined, but we'll follow a pattern similar to Ember which strictly follows SemVer with stable releases every 6 weeks and LTS releases every 6 months.
Blitz will follow a public RFC (request for comments) process so all users and companies can participate in proposing and evaluating new features.
If a Blitz API needs to be removed, it will be deprecated in a minor release. Major releases will simply remove APIs already deprecated in a previous release.
7. Community over Code
The Blitz community is the most important aspect of the framework, by far.
We have a comprehensive Code of Conduct. LGBTQ+, women, and minorities are especially welcome.
We are all in this together, from the youngest to the oldest. We are all more similar than we are different. We can and should solve problems together. We should learn from other communities, not compete against them.
Now Accepting Sponsorships and Donations
Funds will be used to replace my consulting revenue so I can work more on Blitz and get it production ready asap (probably late Q2). With sufficient funds, other contributors will be supported too!
This is a great chance to get your business in front of early adopters!
Top comments (14)
I'm actually excited about Blitz.js! I think it's a step towards right direction in the land of SPA and JavaScript development and I'm glad to see a lot rails veteran leading the charge here.
I have feeling 4-5 years from now when people are talking about the Battle of the Titans. They are not longer going to refer to Django vs Ruby on Rails instead I think people will talk about Redwood.js & Blitz.js when they are greenfield or bootstrapping a startup!
The problem I have had in the past with react.js, has always been the massive hole where React doesn't have an opinion. Like what routing should i use? Form builder? Auth? Database?
Yeah, totally!
To play devil's advocate, why should I choose Blitz over Next.js?
There seems to be a lot of common functionality. What really sets Blitz apart?
EDIT: Nevermind, this just essentially sits on top of Next.js, so it isn't really much different and rather you just create a pattern for handling data fetching. As far as I can see anyway?
Correct me if I'm wrong.
Next has zero opinions for anything other than routing.
Blitz provides conventions, file structure, data handling, background processing, data validation, db schema and migrations, code generation and scaffolding, project REPL for easily running and testing all your code, built in (and swappable) authn & authz, etc.
Additionally, Blitz removes the Next limitation of having all pages in a single folder. With Blitz, you can place your routes throughout the files structure as needed.
First: Blitz looks like an awesome project! I really hope it grows in popularity, because a sane convention over configuration approach is extremely welcome in the JS world, imho.
But say you do want to be able to become an extremely large web app in the long run. How would you go about decoupling from Blitz.js? Would it be an easy path, or a nightmare? Does Blitz.js take this into account, so that decoupling from it it is made easy (or atleast easier than with Rails)? I’m thinking especially about the potential to decouple from Blitz.js architecturally, to enforce modularity and separation of concerns as an app evolves.
I’m thinking about situations companies have run into with Rails such as:
avdi.codes/jim-weirich-on-decoupli...
engineering.shopify.com/blogs/engi...
I think every developers wet dream is to build something which would at least be able to become the next facebook. So having to make an up front decision that would preclude that possibility, or knowingly set oneself up for a potential decoupling or scaling nightmare, would be a barrier to adoption for Blitz. Especially since people have learned from experiences with Rails.
I think a sweet spot would be if Blitz gave startups a good architecture to start with, which could also be extended and remodelled later when the scaling phase (and multiple independent teams/microservices) necessitated it.
Would it be easy to «date Blitz but not marry it» (like Uncle Bob advised in general for frameworks)?
If the (gradual/total) exit is made easy, I think there would be no reason not to start off with Blitz.js!
Hey! Great questions!!
It will take time to tell, but I fully expect Blitz to scale much easier and further than Rails.
1) By default we organize code by domain context (as shown in that Shopify blog post). So all your pages, queries, mutations, etc for a specific model or domain context all live together. And you can can easily reorganize these folders without any code changes.
2) You can certainly isolate domain contexts from each other with a defined public API, similar to the Shopify blog post. However we don't have this by default. But it is something we could explore adding in the future, perhaps as code scaffolding.
3) You can deploy a Blitz monolith via serverless. So each page, query, mutation, etc has it's own serverless function so everything can scale automatically and independently of each other!
The majority of your code is not tightly coupled to Blitz. Most of your code are normal react pages, and queries and mutations. Queries and mutations are plain async javascript functions, so they can be used anywhere by anything.
If a company gets really large, they will almost certainly want to use GraphQL. In this case, you would probably use less and less Blitz queries and mutations and instead use your GraphQL API in your pages. You can do this without having to move away from Blitz. A blitz app without any blitz queries and mutations is simply a glorified Next.js app that allows you to organize your code by domain context (Next.js doesn't allow you to do that)
Hopefully that helps answer your questions! :)
Sounds fun man! Happy to see you on this journey and looking forward to see how it turns out!
I'll definitely be more interested to dive into SPAs & JS world with a tool like this instead of building separate projects for frontend, api, backoffice, etc.
If you want to get inspired you could also check Yii Framework (PHP) if you don't know it.
yiiframework.com/doc/guide/2.0/en
yiiframework.com/doc/guide/1.1/en
In terms of ease of use / get started for beginner developers and also in terms of application "components" that provide valuable tools to quickly develop: Url generation, Code generation, Forms/Validation, AR/DB.
Awesome! Blitz will for sure be the easiest way to build fullstack React apps
Just found out about Blitz, looks pretty cool!
Facebook was once a small web app too - what do you envision businesses doing as their product grows larger and larger? I would be worried of the risk that one day you'd have to switch off Blitz onto something else.
Thank you for your efforts!
I see that all the examples are using typescript!
Do you do this for a reason?
So we can test our own types and so people see we support TS out of the box. Plain Javascript will have first class support too, so it's up to you whether you want to use Blitz with TS or not.
It's been really exciting to hear what you have done so far and to find out more about your plans! Looking forward to seeing it grow.
The web app that I'm planning to build needs a public API for the mobile app, the desktop app and for third-party developers. So building an API is mandatory in my case.
Eventually with Blitz, you'll be able to run the same app on web, mobile, and desktop, all without building an API. So then you only need an API for third-parties. Building a dedicated third-party API is often desirable anyways.