[RFC] Important Discussion On Possible Blitz Pivot

[flybayer]

Hello to all my friends :)

I have some important and weighty things to discuss.

TLDR: I’m proposing to pivot Blitz to a framework agnostic toolkit that preserves the world-class DX and features we adore but brings it to all Next.js users and optionally Remix, SvelteKit, Nuxt, etc.

I’ve been taking stock of where we are with Blitz and of what we’ve accomplished in the almost 2 year journey together. What we have done is incredible. We invented a fullstack developer experience that is unmatched, enabled by our zero-API RPC data layer. So many tell us it makes them 5-10x more productive 🤯 Nearly 100,000 Blitz projects have been created. No doubt many of those are throwaway tests, but still, that's a ton!! We recently passed the 10,000 Github Stars milestone that so few reach. Our community has grown to 2,500 Discord members and is absolutely incredible. We’ve had almost zero negative incidents. Everyone is so kind and generous.

We’ve also achieved incredible awareness. Tons of people are really impressed with what we’ve made. But at the end of the day, 99% go back to Next.js to build their production apps.

The reality is that we are, and always will, play second fiddle to Next.js. And so sadly, 99% of people never get to benefit from what we've built.

Growth has totally stagnated this year. Our weekly npm downloads is a perfectly flat line this year with around 5,000/week meanwhile Next.js downloads are growing exponentially and is now at 2.2 million per week. When we made the decision to fork Next.js, I expected that Blitz would start to carve out a small portion of Next.js users. But that absolutely hasn't happened. In fact, I think the fork has actually hurt adoption. That said, I still feel trying the fork was the right decision. I have a way better vision for what a Blitz toolkit should be now than I did then.

The Next.js fork has nearly killed our feature momentum. And we are no longer executing on the vision we set out to solve. Instead we spend so much time spinning our wheels fixing weird package manager things, keeping up with nextjs changes (we have no inside knowledge of nextjs plans), etc. Lack of momentum and lack of growth really hampers our motivation.

At the end of the day, I can't see anything that would significantly change our growth trajectory without a pivot.

If we’re always going to play second fiddle to Next.js, the best solution is to find another instrument no one is already playing :)

Proposal

First let me say that the thought of not having Blitz is terrifying. I’m building the Flightcontrol dashboard with it, and I can’t imagine having to do it all from scratch without the Blitz DX.

And I know I'm not alone in this. Many of you have told me the massive impact it has had on the productivity at your companies, your ability to hire and onboard developers, etc.

So whatever would come next, it absolutely must preserve the DX and huge productivity wins that current Blitz has.

Objectives

• Preserve the DX and features we currently have
• Make it easy for millions more of developers to benefit from Blitz
• Decouple Blitz from any specific framework

Therefore I’m proposing to pivot Blitz to a framework agnostic toolkit that preserves the world-class DX and features we adore but brings it to all Next.js users and optionally Remix, SvelteKit, Nuxt, etc.

A toolkit for building anything with a database, from side projects to massive enterprise apps. A toolkit that both enhances fullstack DX and provides the missing backend components for JS that Rails and Laravel enjoy.

Keep reading, I flesh out the vision more below.

Trust & Transition

I really care about you all, the time and effort you’ve invested into Blitz, and your involvement in the community. It’s been a super fun journey, and we’ve come a long ways. But I truly feel we have reached the peak. I don’t see any possible way to go from here to the future we imagined and dreamed of, without a significant change. It’s time to face some realities and decide what is best for us all

You all have put incredible trust in me, building many thousands of production apps on an alpha and then beta status framework. So I feel a heavy responsibility to not damage that.

You have my word that, should we choose to pivot, I will do everything we can to make for a smooth transition from current Blitz to Next.js + Blitz Toolkit. This means preserving APIs as much as possible and heavy reliance on codemods to automate almost all changes including renaming imports from blitz to next , etc.

It would be very sad to lose Blitz as we currently know it (I’ve shed some tears). But many times in life we have to make difficult decisions to lose some things in order to gain even greater things.

I’ve already discussed this privately with a sampling of folks from our community, and all of them have basically been like “yeah it would suck to have some sort of migration, it would be sad to lose what we have, but also it makes sense that this would be the best for us.”

What The New Blitz Toolkit Could Look Like

The New Future, Features, and Possibilities

I originally set out to make the Ruby on Rails equivalent for Javascript and React. But I’m now of the opinion that the surface area for something like this is too massive for one framework to do well. Using a JS UI library like React or Vue adds so much more complexity to the problem. Complexity that Rails and Laravel knowing smirk :) However, I want to give huge props to RedwoodJS. They have done a way better job at executing on that very Rails-y flavor, at least in part because they've built everything from scratch. They also had ~1 year head start.

If we take a look at the entire JS ecosystem, most of the money and effort is going into frontend frameworks, but very little into backend functionality like queues, cron jobs, etc. There are Nestjs and Adonis, but they aren’t exactly designed to work with frameworks like Next.js/Nuxt/Remix.

This means there’s a huge opportunity for us to provide all of the backend features that Rails and Laravel enjoy, and do it in a way that all JS frameworks will love. It was always my intention to build these features for Blitz, but got bogged down too much to get to them.

My vision for the new thing is an enterprise-ready fullstack toolkit with an emphasis on backend components.

Blitz would be a DX booster pack you can add to anything to ship faster and have more fun.

Features

I believe the core value that Blitz currently provides is 1) the zero-api data layer, 2) authentication, 3) authorization, 4) conventions, 5) new app templates & code scaffolding.

A new toolkit would start with these as the foundation. I think almost everything Blitz currently adds would be migrated to the toolkit including recipes, typesafe Routes manifest, etc.

Then we’d start shipping a ton more awesome things. Here’s the features I want to build. And all them would be standalone modules that you can use independent of the others.

	Current	New Toolkit
Zero-API Data Layer	✅	✅
Authentication - cookie based	✅	✅
Authentication - JWT		🚀
Authorization - basic RBAC	✅	✅
Authorization - advanced, permission-based RBAC		🚀
New app templates	✅	✅
Code scaffolding	✅	✅
Recipes	✅	✅
Fullstack logging		🚀
Fullstack environment variable management		🚀
Websockets		🚀
Cron jobs		🚀
Scheduled jobs		🚀
Job queues		🚀
Data migrations		🚀
Mailers/Email integration		🚀
File uploads		🚀
Caching layer		🚀
Billing integration		🚀
Better support for service oriented architecture		🚀
GraphQL data layer		🚀 (if desired)

New Zero-API Data Layer Setup

1. Query/Mutation resolver API would stay exactly the same.
2. Queries/Mutations folders are no longer magic, so you import into a server setup file
3. Instead of importing resolvers into the components for useQuery, you will specify the name of the query/mutation
4. Everything will be explicit, so you’ll need to wrap everything for which you need Blitz functionality, like getServerSideProps, api routes, etc.

Server setup file

// blitz.server.ts
import { setupServer, sessionMiddleware } from "@blitzjs/next"

// queries/mutations folders are no longer "magic".
// You know have to explicitly import into this setup file
import createProject from "app/projects/mutations/createProject"
import updateProject from "app/projects/mutations/updateProject"
// You can now have multiple resolvers in a single file
import * as projectQueries from "app/projects/queries"

// api, gSSP, gSP will be used to wrap everything for auth and middleware
export const { api, gSSP, gSP, Server } = setupServer({
  middleware: [sessionMiddleware],

  queries: {
    ...projectQueries,
  },
  mutations: {
    createProject,
    updateProject,
    deleteProject,
  },
})

export type Server = typeof Server

Expose your server in an API route

// pages/api/rpc/[...path].ts
export { Server as default } from "blitz.server";

Client setup file

// blitz.client.ts
import { setupClient, clientSessionMiddleware } from "@blitzjs/next";
import type { Server } from "./blitz.server";

export const {
  useQuery,
  useQueries,
  useInfiniteQuery,
  useMutation,
  queryClient,
  BlitzProvider,
} = setupClient<Server>({
  middleware: [clientSessionMiddleware],
})

Using Queries/Mutations on Client

// some component or page
import {useQuery, useMutation} from 'blitz.client'

// Option 1 (strongly typed)
const [project] = useQuery.getProject({ id: 1 });
cosnt [createProjectMutation] = useMutation.createProject()

// Option 2 (also strongly typed)
const [project] = useQuery("getProject", { id: 1 });
cosnt [createProjectMutation] = useMutation('createProject')

Wrap getServerSideProps

// pages/ssr.tsx
import {gSSP} from 'blitz.server'
import getProject from 'app/project/queries/getProject'

// fully typed automatically
export const getServerSideProps = gSSP(async ({req, res, ctx}) => {
  // access session
  ctx.session.userId

  // Directly call query fn, pass `ctx` through
  const project = getProject({id: 1}, ctx)

  return {
    props: {}
  }
})

Wrap getStaticProps

// pages/static.tsx
import {gSP} from 'blitz.server'
import getProject from 'app/project/queries/getProject'

// fully typed automatically
export const getStaticProps = gSP(async ({queryClient}) => {

  // Easily prefetch query to fill client side cache
  await queryClient.prefetchQuery('getProject', {id: 1})

  return {props: {}}
})

Wrap API routes

// pages/api/hello.ts
import {api} from 'blitz.server'
import {trackEvent} from 'app/events/mutations'

const handler = api((req, res, ctx) => {
  // access ctx and session
  ctx.session.$authorize()

  // Call query/mutation directly, pass ctx through
  await trackEvent('api', ctx)

  res.statusCode = 200
  res.setHeader("Content-Type", "application/json")
  res.end(JSON.stringify({ name: "Secured Agent" }))
})
export default handler

Cons

• Some migration work for anyone currently using Blitz (but again, we’ll make this as seamless as possible)
• Lose ability to have multiple pages folders and pages folders inside app/
• Lose local middleware for queries/mutations (very few, if anyone, uses this)
• Can no longer fine-tune every aspect of DX since we wouldn’t be the entire framework (but we basically haven’t been able to do this anyways because of staying compatible with nextjs)

Pros

• Almost everyone can now use Blitz without framework lock in
• Reduce framework fatigue in the ecosystem
• Less scope, so less bugs, less flakiness, less responsibility
• Way more motivation for Blitz core team and maintainers
• Will ship at a way faster pace
• More modular and decoupled. For example other frameworks could use new standalone blitz-auth package
• Mobile app/multi-client will work right away without custom compiler work!

Few Misc Notes

• Next.js + Blitz Toolkit would still function as a monolith (if you want). So no major changes to your regular workflow or deployments.
• Multi-framework support: we’d focus on Next.js initially but architect the new packages to easily other framework adapters if we want to.
• Existing uses of things like Page.authenticate would continue to work.

So What Now?

Decision

First thing is to get all your feedback and make a decision on whether to move forward with this or not. Aiming to make a decision next week.

We can also spawn off other RFC discussions to discuss feature and API specifics.

Building The New Blitz Toolkit

If we move forward, there’s different paths to take, but I think the best is for Aleksandra and I to pause any new work on existing Blitz and focusing on shipping new Blitz Toolkit in January. At which point people could start building new apps with it or manually migrating existing Blitz apps. Then finish codemods etc that are needed to automate migrations as much as possible for everyone else.

I would petition the Next.js team with all my might to accept as many of the current Blitz-only features as possible like app env loading with next -e staging, onServerStart hook, fully typed Routes manifest, etc. Whatever they refuse, we can find a way to solve it with the new toolkit. But I trust they will be flexible and willing to work with us.

Status of Current Blitz

Your existing Blitz apps will continue to run as they always have, and we will fix any critical bugs the come up.

The current blitz codebase will remain. It may move to a different repo, but it will be preserved and we can continue to make releases as needed.

Your Feedback

I know this is a big deal and has a big effect on all of us. You are probably feeling a number of emotions right now. So I invite you to avoid a knee-jerk reaction, take a little time to process it, and then please share your perspective on what we should do. 💜

[jjhiggz]

A) Thanks so much for the honesty! I really love the product you made and feel confident that your future contributions (technological and cultural ) will help transform the Javascript ecosystem for the better.

B) I'm fairly new to blitz ( 2 years developing as a whole ), but I just spent two months on a project that we were about to deploy (it's not a continual improvement thing, it's just done). Should I be putting effort into converting it to a NextJS project for future maintainability before delivering this product, or should I be good to deploy it as is?

[flybayer]

Thank you! I would definitely deploy as is. We'll make the transition way easier if you wait a bit for us to develop those tools.

[felixyeboah]

Thank you for putting in much work all these years to create a beast tool for us all. I came from NextJS because I had an issue with the server-side in production and I started looking at other frameworks and I saw blitz. It's been 3 weeks since I started using Blitz and I have been able to move my project to Blitz seamlessly. I have had my fair share of the stress working with another framework but it's really helped me a lot. I have moved both backend and frontend to Blitz without regret and I will feel sad if this wonderful framework goes away. I totally understand the stress that comes with maintaining this framework and how frustrating it can be when you create a tool and lots of people don't use it. I am doing my best as a developer who loves Blitz to promote Blitz to my peers and also make sure we use this framework in our next project at the office. I will feel very sad to move back to NextJS, to be honest.

[jjhiggz]

-- major sigh of relief ---

Again thanks so much for the whole framework in general! I had a blast working on this project.

[mghizzo]

Honestly everyone takes a risk using such a new framework but we all knew. I found out blitzJS while creating a website so I had to move all the nextJS project to blitzJS. I literally took me 2 weeks to do what it would have done in probably months with a lot of things to manage. Web development is constantly evolving, today the most used JS frontend framework is NextJS but I see a future for Svelte and probably there will be also a new one soon. I think that having an independent toolkit is the right path to take and take this project to the next level.
Thanks.

[dillondotzip]

At first I was sad. Now this makes total sense.

Currently prisma is the default orm for blitz. Would this continue being the case?

[flybayer]

Yes, Prisma is incredible

[claudiojulioferraz]

We could alternatively have Objection which is based on Knex.

[brillout]

How about using Vite? I believe Vite is the future. Not only is it a very well-designed piece of Software but also a welcoming community. I've got to know the Vite folks while contributing to the Vite ecosystem and they are lovely people 😊.

[flybayer]

Vite is a build tool, not a framework, right? We would need to pick a build tool for the new toolkit package development — am looking at Vite as an option.

[ajcwebdev]

Yeah, Vite is comparable to Webpack but way, way faster and more ESM compatible. Snowpack was its main competitor but that project is essentially dead now that all the frameworks that were using it have migrated to Vite.

[bredfield]

+1 on vite

[wh1337]

Vite is powerful and could greatly reduce the build and HMR times on the new blitz kit!

[claudiojulioferraz]

In Parcel you don't have to worry about CJS or ESM modules. The code just works the way it is.

[bredfield]

Hey @flybayer, I appreciate the detailed write-up.

A few months ago I decided to use blitz as the production framework for a new product I'm building. It's large codebase, it was a bit of a risk (with it not being at 1.0), but I was so compelled by the design decisions + community, that I took a chance on it. I had a slight recoil to the announcement, but in reflection, I think this is a strong move. And, I really respect the transparency and fortitude to suggest such a large pivot (especially so close to 1.0!).

I'm not excited about a migration, but I'm happy to do it to be back on the nextjs release path as well as take advantage of the compelling feature list that you specify above. I'm pulling together various tools to accomplish many of the things that Blitz does not, I would love for things like queueing, mailers, etc. to be out-of-the-box.

I'm confident continuing to deploy with Blitz in its current state. I'd love to punt on a migration until Q2 of next year, so would be greatly indebted to y'all for staying up with critical fixes in the meantime. I'll be starting a monthly contribution!

Pausing on feature releases makes sense. Please let the community know where involvement / contribution could be helpful -- I'd love to take part.

[markhughes]

Thanks for the honest post @flybayer

I am in the same boat here. We have blitz in quite a large codebase w/ a medium-sized team, and we knew it was a risk too - but we took the word of "there is a 1.0 coming in 1 month.." which has been constantly pushed back, although blitz has remained fairly stable we did take a large gamble ourselves here.

Using blitz allowed me to build an application in 1-2 weeks that would usually take 1-2 months. If anything, a move to this toolkit should increase the development speed for developers using it and provide an even better DX otherwise it really does not seem worthwhile.

Side note, the DX does seem a little "odd" in the new spec.. I don't mind the additional server and client files, however having to specify all the existing queries and mutations in the blitz server, and the additional wrappers seem to counter the DX that blitz was striving for.

One of the things that made blitz so fantastic was the "magic" it provided, to remove the magic (e.g. require wrappers, forced file path structures, specifying every query and mutation in a list, etc) would increase developers time in a project.

[paulm17]

The query and mutation issue may have been solved: #3083 (comment)

[MrLeebo]

I am 💯% on board with this idea

I agree with the premise of this proposal, blitz has grown into something that is very difficult to track and contribute to. I have been recently drawn to Remix, so I love the idea that going in that direction doesn't have to mean ditching Blitz. Plus it's great for Blitz to have such a clearly defined scope going forward. The foundational change in scope here is that Blitz can defer to the best practices and guidelines of your chosen host framework instead of trying to reinvent the wheel on everything.

Some implications of this that I want to call attention to:

• Loss of support for multiple pages folders. I don't think this will be a big deal.

The main drawback to losing this is when you run a recipe that adds multiple pages/queries/mutations/utility files it was nice to have a single folder you could delete if you wanted to not use that recipe anymore vs having to find all the individual files it created. But that's a relatively minor complaint, overall getting rid of this will simplify matters for blitz.

• Blitz can defer to the host framework's best practices. Focusing on backend features frees Blitz from spending so much time and energy mucking around with everybody's preferences for what the frontend should look like.

Right now Blitz asks you which form library you want to use immediately when you create a new project. That always struck me as bad timing/a trick question. Possibly the user doesn't know what form library they should use and so they just have to guess. With this proposal, you can stick with whatever the host framework recommends for you. If you are doing Blitz + Remix, then the best form option is Remix's <Form> component because Remix is the host framework.

• I am not crazy about the proposal that all queries/mutations should be explicitly registered. Doing that tarnishes the Rails-y flavor, if you will.

It feels like there ought to be a default convention or DSL (probably tailored to the host framework) that I could work from, without having to manually register every query and mutation. Sort of like routes.rb in Rails. However, if that can't be shipped out-of-the-box, that's an opportunity for contributors to build and publish as an add-on package.

[JuanM04]

Loss of support for multiple pages folders.

Personally, I really like it

[MartinMuzatko]

I personally also really like to group my project into domains, and put everything related there. In that regard, Blitz is doing a marvelous job!

[markhughes]

Loss of support for multiple pages folders

This is something quite important to us and has allowed to us to keep concerns properly separated. It was actually one of the original reasons I looked at blitz.

I am not crazy about the proposal that all queries/mutations should be explicitly registered

It's not a killer thing, but I do think you could add a babel/swc handler to automatically scan in and add it all on build time or something like that.

On top of that, Remix has zero ability to hook into the compiler.

I don't think it's worthwhile to lose DX just to support a new framework. Remix should expose something, I'm sure if a proposal was made they'd open that up.

[paulm17]

I don't think it's worthwhile to lose DX just to support a new framework. Remix should expose something, I'm sure if a proposal was made they'd open that up.

To be honest. I don't know why people are so excited about using other libraries. Remix is just too new and doesn't have much to offer over NextJS. Nuxt is terribad. Vue is awful. I know because I've used them both in anger to create projects. NextJS/React is so much better. Svelte's ecosystem is just too small right now.

Basically, good luck trying to push into prod an enterprise app not built in React.

[StitiFatah]

I don't think it's worthwhile to lose DX just to support a new framework. Remix should expose something, I'm sure if a proposal was made they'd open that up.

To be honest. I don't know why people are so excited about using other libraries. Remix is just too new and doesn't have much to offer over NextJS. Nuxt is terribad. Vue is awful. I know because I've used them both in anger to create projects. NextJS/React is so much better. Svelte's ecosystem is just too small right now.

Basically, good luck trying to push into prod an enterprise app not built in React.

I don't understand either how Remix suddenly became a go to library for people in such a short period of time but maybe they're confident about the power of advertising it's benefiting from with big frontend names being behind it.

For Vue I also prefer the React way of doing things but it still seems to be pretty popular + alternative to trillion dollars company's frameworks, so it'a understandable.

[leerob]

👋 Happy to work with you to understand changes that could be pushed upstream to Next.js from the Blitz fork.

This was well-written and very clear, kudos 🙏

[flybayer]

Awesome, I appreciate it!

[tmcw]

👏 Congrats on having the guts to see this situation and make this post. Couldn't have been easy.

My thoughts:

• This seems like a smart call! It'll let Blitz users rely on the parent framework and its support channels without wondering if Blitz is slightly different. And it'll be nice to be able to run bleeding-edge Next.js.
• I do wonder, or worry, about supporting many frameworks. Given how things are going, these frameworks are going to have very mixed parts. Next is going swc, Svelte has its own thing, Remix is esbuild, and they're taking different approaches to splitting out API routes in serverless environments, etc etc. I worry that that supporting many frameworks would make support burden higher and lead to lesser guarantees.
• Given the proposed query/mutation system above, I also wonder if a compiler-free solution (like trpc) would be viable, which would remove some of the 'bad' magic while, possibly, keeping most of the niceness of the query system. Especially with swc, having a unique build step feels like a risk. In this case, a little boilerplate in exchange for less compiler magic feels like a good exchange.

[flybayer]

Regarding your last 2 points: the new zero-api layer will absolutely be compiler-free, similar to trpc. So that allows us to work seamlessly with any framework regardless of their build tooling. I took a hard look at using trpc for the new thing, but it's too far away from the DX we currently have (and will have) to use it directly.

[MartinMuzatko]

Before I got to know Blitz, I was setting up exactly what Blitz would do for me. So I had my prisma server and nextjs app just about ready in order to build the app. Then I got to know about Blitz and my development experience and productivity drastically picked up.

Blitz encompasses exactly these best practices I love in Prisma and Next, and the glue that connects it. I'd be sad to see Blitz lose its focus on what made me move to React and all its related tooling. At the same time I can understand wanting to break free from the dependency hell you have built. However I fear you are plunging yourself into the next hell.
I wish you the best of luck that everything turns out fine :) Can't wait to see the new features!

[flybayer]

@MartinMuzatko the vision and features that attracted you will totally remain and exist in the new toolkit. The only difference is a bit more explicitness (bit less magic) and using next apis directly instead of all wrapped by Blitz. But nothing will change with the glue that connects Prisma to Next.

[Swapnull]

Hey!
Given we have about 4000h of dev time into our current blitz project, this is quite upsetting.

I understand where you are coming from. Competing with a powerhouse like Next (especially when Vercel seem to be hiring half of the best react talent out there at the moment) is daunting so I respect the reason you are looking to do this.

Although I probably don't have much use for the toolkits proposed features right now - I have tried to work with some of this stuff in a previous role and it was a nightmare, so it would be cool to see what the blitz team can do in this space.

I am not as happy about this as other people seem to be - but I understand the reasonings, and that will have to do for now :D

[ajcwebdev]

Based on this:

Your existing Blitz apps will continue to run as they always have, and we will fix any critical bugs the come up.

The current blitz codebase will remain. It may move to a different repo, but it will be preserved and we can continue to make releases as needed.

It sounds like if people wanted to continue maintaining and building on the current codebase that will be an option.

[flybayer]

@Swapnull thank you for sharing this — I totally get it. It's folks like yourself that I have in mind for developing the migration tooling. I'm hoping that you'll be pleasantly surprised at how seamless it will be.

[S-Burns]

You have invest about 4000X what most Next JS Stars have into this project, Why? More prospective value than Next offers or has offered correct? Who invests 4000 hrs on Next?

[Swapnull]

You have invest about 4000X what most Next JS Stars have into this project, Why? More prospective value than Next offers or has offered correct? Who invests 4000 hrs on Next?

I think you may misunderstand what I said (on re-reading, it wasn't phrased the best). The project I am building has 4000h of time into it, and it is build using blitz - not 4000h contributing to blitz. I imagine some of the team have put about that, if not more, into building and maintaining blitz though.

To explain the 4000h. It comes to 100 work weeks. I have a team of 3 and we started working on our blitz project in Feb, so about 48 weeks ago. (48 * 40) * 3 = 5760h. Take out meetings/holidays, etc - about 4000h is not a crazy guess.

To be clear, the more I look around the ecosystem, the more this new framework makes complete sense to me 🙏 Can't wait to try it out!

[alexanderson1993]

I love this proposal, especially the plan to possibly support frameworks other than Next.js. In light of that, I recommend you do everything you can to make this backend-agnostic. In Remix especially, some folks deploy to Cloudflare Workers, and they'll soon support Deno. Supporting those non-Node.js runtimes will even more important as time goes on and more compute happens at the edge.

[flybayer]

Yes, that was already my plan :)

[nopitown]

Oh! Just to be clear, do we refer to some kind to runtime agnostic compatibility? Or “backend agnostic” per se? I’m a bit confused 🤔

[flybayer]

By "backend-agnostic" I think he means "runtime-agnostic". I.e. aim to work with Deno, cloudflare workers, etc, not just Node.

[nopitown]

Got it! Thanks 😊

[doncicuto]

Hi @flybayer, I'd like first to thank you and the rest of contributors for your dedication to this project and also I appreciate the chance you give us to participate in this discussion. I'd try to focus on these two paragraphs. Forgive me if my English is not too good.

Growth has totally stagnated this year. Our weekly npm downloads is a perfectly flat line this year with around 5,000/week meanwhile Next.js downloads are growing exponentially and is now at 2.2 million per week.

I'd like to tell you why I decided to choose Blitz. I started a project using NextJS but after some weeks I started to struggle with documentation and I found that some things like authentication, convention about project structure... were not there. Then I started to look for an alternative, and I saw Blitz, but you know what? I didn't choose Blitz mainly because I saw "It's on beta". I know that it's silly but I wasn't sure about this bet, so I kept using NextJS once again until I found that I wasn't happy with I was doing so I ended trying Blitz and then I felt relieved. I understood docs, I liked how it was using the tools I added to NextJS like Prisma and thanks to your authentication option I was writing code happier than ever. I'd like that Blitz would come out of beta version as IMHO it would help Blitz to get more users, but I understand that it's not fine to struggle with NextJS as you state later. NextJS is great but Blitz helped me to use it in a better way and I will continue focusing on Blitz.

The Next.js fork has nearly killed our feature momentum. And we are no longer executing on the vision we set out to solve. Instead we spend so much time spinning our wheels fixing weird package manager things, keeping up with nextjs changes (we have no inside knowledge of nextjs plans), etc. Lack of momentum and lack of growth really hampers our motivation.

I'd like to be a better coder so I could help you more with Blitz so I can only give you this advice, if this pivot can reboot your motivation and gain more time for providing new features, please do it. You've shared your time with us and I think it's a thoughtful decision. I know that the community will do their best to migrate current code to the new framework.

[TawalMc]

Really nice your comment, you love your work

[kellvembarbosa]

I also met blitz in a similar situation, I looked at it and I thought, it's based on Next JS I will continue on Next JS…

Finally I decided to give it a try and the amazing documentation for blitz authenticação and useMutation useQuery!

It was perfect, now my biggest question is, when will all this happen?

Do you already have something ready? I'm going to give the new blitz a chance as I didn't the first time I saw it, because if it stays similar it's going to be a hell of a project.

[zenhob]

Thank you for the detailed proposal. I remain glad that I chose Blitz, for the inclusive culture as well as the technology. I once maintained a Rails app that was built during the Rails beta, by a Rails dev. The process of upgrading in those circumstances was painful indeed! I am keen to help find a way to smooth out the path here. Thanks again for all you've done.

[rauchg]

Great writeup. Love the incremental adoption path for Next.js users, and the ability to bring this experience to most people. I've always felt the [..blitz].js extension path would be amazing for Next.js users… great to see this coming into fruition

[Vandivier]

starting w basic data:
I think the next vs blitz graph above is misleading. blitz seems on a clear up trend you would have to measure from the March peak to call it a flat line which doesn't seem correct analysis to me:

I do think it would be interesting if we could find out why the spike in March has come and gone

to me it looks like blitz has gone from 2k/week to 5k/week and next has gone from .8M/week to 2.2M/week. Not a major proportional difference imo. (although we would really want to compare to Next in 2017, not this year)

I can see if you were expecting exponential growth there is a problem but I'm not convinced we have hit the exponential increase part of the S curve yet. Scaffolding seems to be a core value prop imo and we still have plenty of room to go. Kudos on recently merging this feature for example:
https://github.com/blitz-js/blitz/issues/3061

---

beyond the data, to the main discussion: Let me argue in favor of 'playing nice with Next'

Before I do that, let me be clear that 'playing nice with' doesn't need to mean maintaining a fork. However, we all know that Next released some really cool features this year and as a developer I want to be able to use those. As long as Blitz enhances Next, I love Blitz, but as soon as Blitz becomes hard to use with Next, I expect to lose out on the current use case (true, maybe it will find some other use cases)

I see a tradeoff between "wide scope" and "deep scope" and I would personally prefer deep scope. I don't want a CLI tool that can scaffold a single basic form over many languages and frameworks. I want a CLI tool that can generate complex code within React world. Consider the better forms feature mentioned above (#3061). This is an example of increasing depth of scope.

I also worry that becoming framework-agnostic is a step away from the value prop which is to have strong opinions. Next is the go-to SSG+SSR in React world and Blitz enhances Next. If Blitz stops enhancing Next, Next will remain the go-to and Blitz will be what? A competitor? An incentive to use Svelte or Remix? That seems to be a worse situation.

In conclusion, i think it's basically a mistake to change the vision for Blitz. The new vision seems to align with a new and different project. We could simply have two different projects. The cost would be split attention, but the benefit would be A/B testing the growth curve. I'd recommend A/B testing personally.

[flybayer]

thank you!

On the blitz downloads, at the current scale, it's as good as flat. I.e. with the number of new projects being created in general, if we aren't growing faster than this, we are decaying. Also, on average 400 new blitz projects are being generated every day. At that rate, I would expect downloads over time to be growing a lot more.

If Blitz stops enhancing Next, Next will remain the go-to and Blitz will be what?

Blitz will absolutely continue to enhance Next.js. Nextjs will be our primary target. But at the same time, we'll be architecting our new packages to be framework agnostic and have an adapter for Next.

At this time I'm not committing to providing the full Blitz experience for other frameworks, but the possibility is now there. Even if we don't put much effort now into other frameworks, it leaves the door open for us to do so in the future if everyone migrates to Remix for example. Or some new thing coming down the pike.

i think it's basically a mistake to change the vision for Blitz.

The vision remains the same. The DX remains the same. The implementation changes.

[paulm17]

Even if we don't put much effort now into other frameworks, it leaves the door open for us to do so in the future if everyone migrates to Remix for example.

Except that Remix doesn't offer anything significantly new. I've watched 4 videos for Remix and I'm still scratching my head on what it offers over BlitzJS. If anything, it's being touted as an improvement over React CRA.

[Vandivier]

Thanks for the clarification! I'm all for a pivot if we can maintain a focus on deep React-world value compatible with Next. So you are moving me in a positive direction 😄 but I want to do my best to represent an ironman argument for a rationally cautionary approach.

If you visit https://blitzjs.com/ today you see in large letters The Fullstack React Framework and this is the vision as it was communicated to many users through many podcasts and so on.

I think it's a bit more than an implementation change to remove the term React from that statement. Text just under that calls out: Blitz is a batteries-included framework that's inspired by Ruby on Rails, is built on Next.js

Now we see: I’m proposing to pivot Blitz to a framework agnostic toolkit. Again, I think it's more than an implementation change if we remove Next.js from that statement. Once you do that you now suddenly have many competitors that you previously didn't have.

The risk I want to guard against is that support for other frameworks might become a shiny object that distracts from what many perceive as a core value today.

I really can't stress this enough. Blitz will face tradeoffs between depth and breadth of framework support because different frameworks make different assumptions and hold different patterns which are exclusive to one another. Blitz will be forced to:

1. Limit scope to maintain cross-framework support, or
2. Pick a reference framework to go deep with, limiting cross-framework compatibility, or
3. Provide many utilities to support various combinations, limiting the depth of utility for any particular combination at a given velocity of effort

Because I have an interest in deep value within React world (which seems like the original vision to me) I would suggest option 2:
Let Next.js continue to be the gold standard reference framework. Don't really be framework agnostic.

Hope this was constructive! I can see that maintaining a Next fork is problematic and that a library toolkit approach is more flexible and facilitates other use cases.

Nuxt mirrors Next, so probably Nuxt users could consume the toolkit with minimal depth sacrifice, but the next/nuxt paradigm is greatly different compared to the Angular Universal paradigm (which already has a cli tool and strong opinions anyway) and it's also different from the SveltKit paradigm, etc.

These are things you already know I'm just calling them out to hopefully convince you to emphasize Next enhancement over true framework agnosticism.

[ccssmnn]

100% agree with "depth scope" > "wide scope" as well as benefitting from new NextJS features.

BlitzJS being a frameworl allows Platforms like Vercel, Netlify, AWS and others to provide "zero-config" deployments, which improves DX a lot. Being a toolkit will make life harder on the deployment site. Which is a huge DX selling point of NextJS+(you name it) IMO. Blitz could provide its own platform, while having copy-paste configs for other providers. "depth scope" vs "wide scope"

[mitchazj]

Full support on the pivot ❤️🚀

I'm definitely a fringe user who avoided building anything real with blitz because a pivot like this hadn't happened yet. Moving to an add-on for fresh next projects (and perhaps in the future remix etc) would convince me this project is future-proof enough to build stable apps upon. I'd definitely love to see the next ecosystem fully embraced before an over-extension into other ecosystems too :)

[flybayer]

I'd definitely love to see the next ecosystem fully embraced before an over-extension into other ecosystems too

Great way to put it :)

[Albert-Gao]

This is a good move indeed.

1. Not every project needs React. (OK, I am a React person and won't go anywhere, but this is the reality), this will give Bliztjs more exposure and use case
2. For the project that does need React, for both Blitz & Redwood, I do not need any opinion for the frontend... Unlike the backend, where the way you shape your project is pretty much fixed no matter which language you are using, but for frontend, things diffs every project, of course, I can just skip those FE abstractions, but that always make me feel I have included something I do not need in my project...and, TBH, not every project is using next.js, still loads of projects are using CRA and new projects are using them too,,,
3. there are just too much alternative good libraries for the FE, better to give the FE control back to the user land, or build it in the integration layer
4. this will drive a different but health growth path between blitz and redwood so both will have their own user group and path, rather than previously, the overlap is a bit too much.
5. the nodejs community, despite all its crazy growth these years, is hunger for a top-notch backend framework with the description you have here, probably because the cloud tech is too popular these days. with the current vision of blitz, there will simply be no competition at all...ok, there are some, but they are too old to compete...

just one thing, the new vision for blitz is fantastic, but probably 2x harder than the original one...

I love feathers.js(https://feathersjs.com/) which gives a fantastic protocol-agnostic abstraction. yes, the backend logic can be swapped between ws and http.

just one idea here, is there a way blitzjs can build its own abstraction, such that, we can swap the deployment strategy, like a cron job build for blitz can be run on aws/azure/own server

i know, i know, they each are 100% different than the other, but never afraid of thinking, right?

Congrat on this pivot, you are doing the 100% right thing.

[winner106]

For whatever reason, if we give up a project before it reaches version 1.0, I think it's a pity! In my opinion, we should at least reach blitz 1.0

[fungilation]

My point is there's no objectivity "between" how different projects by different people give it a 1.0 moniker. Use OSS, gauge the community, and make up your own mind.

[ccssmnn]

On the blitz website, it says

Once we reach version 1.0, we'll switch to a stable, predictable release cycle with multiple channels like stable, LTS, and beta.
We are taking a lot inspiration from Ember in this regard.

[ccssmnn]

If you're using 0.x software, the library maintainers tell you, that you need to expect breaking API changes. Of course you can still use it in production, but updates (including security updates) might break your application.

Using 1.2.3 means that updating to 1.2.4 includes no API changes, only bug fixes or security fixes. Updating to 1.3.0 introduces new APIs while not breaking existing ones. Only updating to 2.0 might break backwards compatibility.

That's security for developing and maintaining applications, where you do not want to risk breaking your system for minor updates.

BlitzJS has not reached it. Will not reach it. I expected it to be right around the corner. Now we will have to wait at least several more months (or years?) until the toolkit might become stable.

[muescha]

Put the 1.0 tag on the current state makes it possible to name the new pivot blitz then BlitzJS 2.0 (like the new Angular version 2)

[MartinMuzatko]

Increase in major version also means breaking change. In that regard, staying at 0.x.x would at least provide that semantic safety, as most package json files would stay at blitzjs@^0.44.3. So either way, people wouldn't retrieve it anyway.

[ccssmnn]

We have considered blitz for an application we are developing and didn't choose it. That's because the 0.x version is taken as a message, that the API is not considered stable yet. And that's not just a number. On the blitz website, it says

Once we reach version 1.0, we'll switch to a stable, predictable release cycle with multiple channels like stable, LTS, and beta.
We are taking a lot inspiration from Ember in this regard.

To me, blitz is a full-stack framework. And frameworks tend to make decisions for you.

NextJS as a web-framework decided to build on top of React. They provide their own solutions to analytics, images, APIs, etc. That's many decisions that teams don't need to make any more.

I liked how Blitz as a full-stack framework went further, being based on NextJS. Choosing Prisma for Database connections, providing solutions to sessions and auth. A blitz-toolkit will provide some flexibility while loosing all the advantages of a framework. Also, for the maintainers, supporting all web-frameworks or component libraries will most likely be more complicated to support.

[ccssmnn]

Maybe being loosely coupled to nextjs is a good option?

[claudiojulioferraz]

It would be nice if Blitz were like Nestjs; having fullstack, microservice and serveless capabilities. But without the complication that is Nestjs.

[PixelsCommander]

I totally understand where the idea comes from and I respect your decision if this happens. While I am not a fan of this switch. Our stack is stable (React + Next) and we just launched a product using Blitz. If you increase the codebase to support other frameworks the quality of support for our stack will collapse and the chance is high we have to rewrite the codebase using a more focused framework which I d like to avoid.

Would it not be better and safer to start another project if you feel Blitz is not fun to make anymore?

[andycharles6]

Correction: "Reason is flat growth curve". I hope WebSockets will bring the expected growth curve :)

[flybayer]

Thank you everyone very much for your sharing your heart on this. I'm much more aligned with you than it might first appear!

I can emphatically say that Next.js is our primary and most important target. We love the DX we currently have, and it's very important for us to maintain that with this transition.

What I would like to see. Is NextJS be first party.

I guess it may depend on what "first party" means, but it's absolutely our plan to have nextjs as first party support.

If you increase the codebase to support other frameworks

It seems there's some difference perceptions here of what and how much work is actually involved in supporting other frameworks.

The whole idea with this pivot is to massively reduce our codebase and reduce coupling with nextjs. Reduce coupling with nextjs so that any small change over there doesn't cause tons of work for us, which is what has been the case so far. But at the same time keeping a very awesome Nextjs + Blitz DX.

To accomplish that, we are extracting out our current code like zero-api and auth into standalone packages that have zero framework integration. Then make a tiny adapter for nextjs so you get that sweet, sweet integration without lots of manual work or boilerplate.

This does the following:

• Easier to maintain
• Easier to contribute to
• Makes our nextjs integration less brittle and more resilient to any nextjs changes since the integration is cleanly isolated vs being intertwined all throughout our code.

Therefore this is the right choice even if we never want to support other frameworks.

A side effect is that now people can use our standalone packages with any framework with some manual work and some boilerplate. If usage is growing then it makes sense for either the community or maintainers to make a framework adapter to improve the DX.

When Brandon is working on Remix. Now the issues for NextJS are not being worked on. How long are people who have projects in production and waiting on critical issues to be resolved, supposed to wait. When they see Remix or Svelte release, upon release, upon release and waiting for NextJS impact release?

I totally feel your worry here. We should definitely spend the most maintenance effort on what is being used the most (currently nextjs by far!). I guess it will take some time to see what it's actually like, but I highly expect framework specific issues to be a minority of issues. This metric can help guide us on whether to spend any energy on other frameworks in the future.

I think a point worth emphasizing is that the current Blitz core value (zero-api, authentication, authorization, conventions) has very little to do with nextjs. It's normal JS and web requests which is the same across frameworks.

In summary, I'm keeping on open mind about whether we have first class support for other frameworks or not and if so, how much. I'm not committed to supporting Remix. The only thing I'm currently committed to is the Nextjs integration and having our core components decoupled from any framework.

How do y'all feel after hearing this?

[fungilation]

Sounds great. First class support for Next.js only to start, focus. While having an open architecture to allow for relatively painless support of other frameworks, and those second class support can very much come from community contributions.

[MartinMuzatko]

I believe having the zero api and other tightly-knit/integrated modules extracted would also ease contribution 👍
Thanks for the great write up. I now feel a lot easier now about this.

[nickluger]

To accomplish that, we are extracting out our current code like zero-api and auth into standalone packages that have zero framework integration. Then make a tiny adapter for nextjs so you get that sweet, sweet integration without lots of manual work or boilerplate.

💯 💯 This is the way to go. Thank you Brandon! 💯 💯

Imagine you use multiple frameworks for different use cases, e.g. mostly Next and sometimes Remix and you could bring your Blitz-toolset to the job whatever you work with. That'd be a use case for us at least.

The real implication of this pivot though is, that now millions of Next (!) users are just a npm i @blitz/rpc @blitz/auth ...-away from the delightful DX we all enjoy. This is a major improvement to the current situation, even if not a single Remix-user would use Blitz, the audience would be much larger anyway.

I believe having the zero api and other tightly-knit/integrated modules extracted would also ease contribution

THIS, too! I was once thinking about making some little change to the codebase, then was like: ...uh oh... it's within the Next.js fork... can't touch this! 😄

[nickluger]

There's a lot of truth in these observations @paulm17, @PixelsCommander, especially in comparing this to Prisma and regarding project scope vs available (very limited) resources.

I consider the new Blitz.js (beware, elevator pitch) "the Prisma for frontend".

There's a central difference, though. Prisma needs to wrap and map multiple fundamentally different databases to a single unified interface, to deliver its value. Blitz, as any other JS-library, does not have to do that.

The adaption for frameworks like Next.js or Remix is not comparable to that. That's because web frameworks like Next etc. usually tend to work with other JS-libraries, or at least, with other React libraries.

As long as the common denominator is React, I don't consider the effort in the same league as what Prisma has to do.

I think the effort is in fact far less than maintaining that Next.js fork.

That said - I share your view, that project scope should be super-narrow, sharp and focussed - at least in the beginning.
This means:

1. Zero-API data layer, with best DX on the market + end-to-end type safety
2. Super-easy Session-based auth.
3. Resolver-Helpers & sugar like pipes, validation, auth.

[MartinMuzatko]

If user numbers are one of the biggest concerns of switching to something that promises to be more flexible, then I think a more feature complete Blitz focused on Next/React would help a lot more to have people adopt Blitz, than freedom of choice. I am already choosing a full-stack framework! I expect to make trade-offs to have less to think about. So I don't mind having next and react as solid base to work with. BUT! If there is only one choice, I expect it to be well integrated and somewhat feature complete.

Like with ORMs attempting to focus on all databases, I saw a similar problem and trend with other software. Ionic tried to please everyone at the same time also. Ionic, which first focused on Angular, then went on to invent entire new toolchains like stencil to build their components for vue and react also, had only a slight increase in userbase. The 2020 Survey showed, that of the original userbase, roughly 85% stayed with the only choice Ionic was able to offer previously: Angular.
If I project the same on Blitz, offering a toolkit for vue, svelte and angular could turn out for the same small change in the end.

I do favor the other feature @flybayer proposes, and if switching back to original next provides that, I would very much prefer that, but I would not like to give up the comfort and DX I am having right now with automatic resolution of resolvers and grouping my features into domains with a pages folder sitting inside a user or event folder.

[nickluger]

• 💯 💯 Domain-driven code colocation is an underestimated feature of Blitz! I wonder if that will be even possible with raw Next.js?
• Yes, monetization might be an issue, if business model and code requirements diverge.

[fungilation]

Ionic's example isn't a useful parallel, as it has its own "why Ionic" beyond "adopting React didn't move much of the needle". I know as I was evaluating Ionic and in the end, why? It's still just a mobile Web app wrapper, I might as well go full native with React Native.

[flybayer]

Thank you everyone! I gave a long response in the above thread: #3075 (reply in thread)

the shift from being a project that is "focused on developer needs" to a project "focused on its own needs".

I assure you that my #​1 priority is "developer needs". A key reason for the pivot is that we were failing on our promises to meet developer needs. I've heard from a lot of devs that stopped using Blitz this year because of snail's pace on feature development.

Domain-driven code colocation is an underestimated feature of Blitz! I wonder if that will be even possible with raw Next.js?

The only thing that isn't currently possible with Nextjs is having multiple pages folders. But this is something I can put together a nextjs RFC for possibly they will be open to us adding this into nextjs core.

[nickluger]

The only thing that isn't currently possible with Nextjs is having multiple pages folders.

That's great. IMHO, it's more important to be able to colocate components, queries, libs and mutations, than pages. There are some valid arguments for keeping pages in one folder, as it colocates the complete routing definitions of a website.

But this is something I can put together a nextjs RFC for possibly they will be open to us adding this into nextjs core.

That's why I'm a bit skeptical that this one will make it. 😅

[flybayer]

Update Jan 11, 2022

Thank you everyone for all your input!!

We are moving forward with the toolkit pivot, focusing primarily on nextjs support and a fully seamless migration from current blitz.

I can't promise a timeline, but we're eyeing February. And after a very short beta/preview period, we'll release it as 1.0.

We'll post general updates here. And we'll post zero API updates to the zero API RFC as we have them. And if there's any other things with more than small changes we'll post RFCs for them too.

If/when we get to place where it's easy for y'all to contribute to cleanly scoped issues, we'll let you know.

I hope your January is going well, and you're staying safe!

[KATT]

Heya @flybayer - I'm back online now - how do you want to proceed with the potential of tRPC + Blitz.js partnering up? I'm sure you've given it some thought over the last few weeks. I'm still keen to see it. I think there'll be a way of doing most or all of the things you want without compromising the existing Blitz users.

[flybayer]

@KATT didn't get much time to focus on the zero-api part 😅 . We're currently working on the plugin system. Concerning tRPC collaboration, this is still our current thinking.

[madaxen86]

So how is it going?
You once aimed on Februar but I know you focused on Flightcontrol.
I’m really looking forward this, totally excited 🤩 this could be a game changer in the node dev experience.

[webdeb]

As a Next.js Dev I am thrilled to adopt blitz into my current project and maybe further projects as well. And I think @flybayer has true balls to 1. try to compete with next, but 2. also does not fear to officially stand up and make a pivot in to the direction were most of devs can benefit from. You are my hero bro :)

[paulm17]

Actually he's technically not competing with Vercel. I think I'm right in saying that they have no interest in the backend. They've as much signalled this.

What he is doing. Which is something that is desperately needed, is to provide a "laravel" for the node ecosystem.

Take a look at this example: https://news.ycombinator.com/item?id=29806385

I'm really surprised at how easy anything is considered "full stack". Where is the ORM/data access library? The validation framework? The background jobs? The caching system? The translations/i18n system? And the other 1000 things you do need for a full stack real life application? I definitely do have those things in Laravel, Django and rails. Next.js, nuxt.js, sveltekit etc are far, far from full stack. They can certainly run js in the backend, but that's not full stack, you still need 10s of other packages.

I don't want to get into the contents of the link, this comment says it all 😅 .

If @flybayer can develop a true library independent backend framework, which can then have interoperability with whatever FE framework is in the ecosystem. Then he should get a significant following. I'm sure there will be many people wanting to try out the toolkit in their preferred FE language.

I'm also very happy with his last two statements. I am definitely rooting for him and I hope by the end of this year, there is something significant from all his efforts.

[diontron]

Just wanna say once I can use Blitz with Vue I will jump ship from Laravel immediately. Thanks for all your work.

[siddharthsharma94]

Super excited for this pivot, are there any rough estimates as to when we can expect the newest pivoted version of blitz 🙃?

[paulm17]

I think @flybayer said they were aiming for a Feb release. But I'd rather they hit the target, even if the release is somewhat delayed. Still super excited as well!

[flybayer]

Aiming for March now :) Work is in progress on the main branch in this repo.

[siddharthsharma94]

Amazing! Appreciate all the hard work being done by you @flybayer and the rest of the Blitz JS community! Can't wait for launch.

[thethmuu]

@flybayer @siddharthsharma94 So is the pivot completed now? Just want to confirm as I am new to Blitz. Thank you.

[muescha]

current status you can see here:

https://github.com/blitz-js/blitz/releases

[cloudcompute]

@flybayer

For the proposed new toolkit, is the implementation of the "Zero-API Data Layer" feature 'almost' complete? Could you pl. tell me the names of the folders / files where this code is lying.

I am following Blitz closely since the last one year. When you decided to import the Next code in Blitz and started modifying it, I was like Blitz may fail because of this. Well, you have finally decided to make Blitz framework-agnostic, I appreciate it.

You are looking forward to make Blitz a feature-rich full-stack framework. A suggestion in this regard. Keep it as flexible as possible and try to use the proven, stable Node modules. For example pino and winston are very popular loggers. If possible, create a logger plugin in Blitz and the developers should be able to plug the existing logging module of their choice. Similarly for Message Queues, let them use bull or kafka.

[wh1337]

Greetings,

I was just curious as to the status of the Blitzjs pivot. Mostly, I was just curious as to when we could get our hands on the first build post-pivot 😄

[athammer]

Not just responding to you cryptic but wanted to re-iterate what was said in a few other places as most people will end up here.

• You can find the project board to see what tasks are in flight/worked on here
• The branch it's being worked on is the main branch

I thought the estimate was around March but it may be further in the future.
If you care about the development be sure to sponsor their work if you can; here or here :)

Update:
1.) Looks like April 18th is the hard deadline for the migration at least for it to work internally. Looks like things have speed up considerably 🎉 Source from Blitz.js's discord
2.) Mutations and queries work now :)
3.) Alpha version is now publicly available. Updated docs and more coming soon
4.) Alpha version currently released with beta close behind 🥳 - source - alpha docs
5.) Blitz.js 2.0 docs are now live. Guessing the announcement for Beta will be coming soon

[alexander-mart]

How much work needs to be done to use blitz@alpha with SvelteKit?

[webdeb]

Just recently I've started to use Blitz and I've to admit, that the DX is top. The actual comparison with nextjs is difficult. Next has a solid funding, I am seeing vercel ads on twitter every day. Next.js is there since end 2016 and got support from some influential people like Arunoda Susiripala who was very influential in the Meteor.js community.

So, I would say you need to start a company, which will provide hosting, db, file uploads, image-compression/rendering, real-time features, GDPR conform analytics etc. and provide a full-packaged dev solution to users to get the right funding.

However, you definitely have to sell services and heavily advertise the product, to grow the user base.

[Riz-waan]

Hi, I remember the original post talking about allowing sveltekit. The only thing stopping me from this is having to use react. Are you guys going to work with sveltekit in the timeline?

[alexander-mart]

Someone try to adapt Blitz for SvelteKit:
https://github.com/SBHattarj/svelte-blitz

[Inalegwu]

Honestly didn't want this to happen all together but after considering the entire framework landscape right now , i feel this is more than the right way to go. Make Blitz more of a language tools than a framework tool