Blitz.js is a new Javascript framework for building monolithic, full-stack, serverless React apps with zero data-fetching and zero client-side stat...
For further actions, you may consider blocking this person and/or reporting abuse
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.