Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add fastboot to the default package.json #579

Closed
wants to merge 2 commits into from

Conversation

mehulkar
Copy link
Contributor

@Gaurav0
Copy link
Contributor

Gaurav0 commented Jan 11, 2020

FastBoot is generally not worth it for any authenticated (behind a login) B2B application because search engines cannot access them, and all advantages besides performance are moot. Performance is less of a concern to these types of applications as well as they can expect business users to have fast connections.

I really do like the alternative of making server side rendering a top level section of the guides. It would massively increase the visibility of FastBoot and encourage its use. Can we try this first?

@NullVoxPopuli
Copy link
Contributor

In general I disagree with fastboot usage.
However, I think LinkedIn had some use for it

@mehulkar
Copy link
Contributor Author

FastBoot is generally not worth it for any authenticated (behind a login) B2B application because search engines cannot access them, and all advantages besides performance are moot.
Performance is less of a concern to these types of applications as well as they can expect business users to have fast connections.

Are you suggesting that Ember has a preference towards B2B / authenticated apps? Or are you saying that Ember is not a good fit for unauthenticated pages? Now more than ever, I think Ember should be working on (1) a better experience for simpler apps (that's been a big selling point of Octane) and (2) setting itself apart from other component libraries like React or Vue or even Web Components. I don't think these are mutually exclusive of still being great for dashboard B2B apps.

SEO and performance aside, I've worked on several dashboard apps with Ember and I do have anecdotal evidence where easily getting sharing previews would have made an app much more useful.

I really do like the alternative of making server side rendering a top level section of the guides. It would massively increase the visibility of FastBoot and encourage its use. Can we try this first?

I'm open to that if that's where the community wants to go as a first step, but I worry that it's putting the cart before the horse. Forcing documentation by way of enabling a feature seems better than adding documentation that gets ignored.

Note that the default experience in the RFC is with FastBoot turned OFF, so it shouldn't impact any users who want to skip it.

In general I disagree with fastboot usage.

Why? To clarify do you disagree disagree with FastBoot or with SSR in general?

However, I think LinkedIn had some use for it

Apple has some use for it too :). But I think that's part of the point here. I posit that Ember should be encouraging more SSR. If it's not an easy feature to use and right there for you, fewer people will use it, and we perpetuate the perception that "it's not worth it".


## Unresolved questions

- Should `ember-cli-fastboot` be integrated with `fastboot-app-server` before it is integrated into Ember as a default?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if it's not integrated with ember-cli-fastboot, would it be worth it to add fastboot-app-server to the default blueprint as well? I've switched my fastboot app to use it for some time now and it's been a great experience.

@mcfiredrill
Copy link

FastBoot is generally not worth it for any authenticated (behind a login) B2B application because search engines cannot access them, and all advantages besides performance are moot. Performance is less of a concern to these types of applications as well as they can expect business users to have fast connections.

SEO and performance aside, I've worked on several dashboard apps with Ember and I do have anecdotal evidence where easily getting sharing previews would have made an app much more useful.

I understand the concern for SSR not being very beneficial for these kind of apps. However in the case of these apps, all they really need to do is remove fastboot from package.json. Even if it is not removed, it will be disabled by default.

Compare this to someone who actually wants to use fastboot, the hurdle is huge. Documentation lives on another domain (ember-fastboot.com), there are multiple pieces (fastboot-app-server), the status of features like re-hydration are unclear (to me at least). Having fastboot in the guides, and even in the default blueprint sounds like a great way to increase awareness and development.

@Gaurav0
Copy link
Contributor

Gaurav0 commented Jan 13, 2020

FastBoot is generally not worth it for any authenticated (behind a login) B2B application because search engines cannot access them, and all advantages besides performance are moot.
Performance is less of a concern to these types of applications as well as they can expect business users to have fast connections.

Are you suggesting that Ember has a preference towards B2B / authenticated apps? Or are you saying that Ember is not a good fit for unauthenticated pages?

I am only suggesting that there are types of applications for which FastBoot is not a good fit. Just like Ember Data, pushing Ember FastBoot in situations where it is not appropriate may continue the perception that Ember is too complex.

@mehulkar
Copy link
Contributor Author

mehulkar commented Jan 15, 2020

I am only suggesting that there are types of applications for which FastBoot is not a good fit

I don't agree with this. The reasons you cited earlier were about certain advantages of FB (SEO and personalization) not being as beneficial for enterprise apps. Stretching that to "it's not a good fit" seems more about it adding more complexity than benefits. Reducing that complexity is exactly what this RFC aims to do.

may continue the perception that Ember is too complex.

I do agree with this though. A larger package.json does signal "bloated" to me too. Personally I wish the blueprint package.json was 2-3 dependencies total, purely for marketing reasons. I'm not sure where that leaves us, given the current state of things :/

@lupestro
Copy link
Contributor

lupestro commented Jan 16, 2020

FastBoot is only useful if it is used in a way that is backed by caching, reload detection, and state rehydration. Even though getting pieces into the initial page solves a number of useful problems for accessibility and SEO without these other things, time-to-first-interaction determines how many people walk away from a site, and SSR is never cheap those times you actually have to do the work. With FastBoot alone, you will do worse overall than without FastBoot. To have a viable solution, unless you're rendering at build time, you need caching, reload, and rehydration.

The family of stuff around FastBoot provides the needed pieces, and each of the add-ons of the FastBoot puzzle is documented. The problem is that it isn't usefully documented how to pull them together into a repeatable, cohesive solution. If we can document a FastBoot solution using combinations of middleware to accomplish a baseline solution in a single server instance, more people will use it. Providing an add-on that orchestrates the existing add-ons and other libraries to provide a caching, reloading, rehydrating SSR out of the box would be a better use of time than bringing FastBoot into the base kit. (Think of all the pieces that ember-cli-typescript coordinates to make TypeScript a part of the experience.)

Maybe a year or two down the line, after an integrated solution has proven itself, that package could become part of the shipping baseline, but right now, it takes a lot of expertise just to set up, let alone the strictures it places on your code, and incorporating it into Ember feels premature to me.

@mehulkar
Copy link
Contributor Author

mehulkar commented Jan 16, 2020

@lupestro thanks for the reply. Your suggestion to make an addon that provides a cohesive solution is a good alternative approach, but I do not think it will move the community forward. I'm also not sure this statement is true for everyone:

With FastBoot alone, you will do worse overall than without FastBoot."

But the tradeoffs of enabling FastBoot are sort of irrelevant to this RFC. We already tried the "publish an addon" approach for 2 years, which is when 1.0.0 was published (npmjs says 0.0.1 was published 5 years ago). As far as I can tell, documentation is still sparse and disconnected from Ember, usage is still uncertain, the comments in this RFC make it clear that the developer story (and perhaps user benefit for some/many apps) is still questionable.

The goal of this RFC is not to make ember new apps served with FastBoot. Rather, the goal is to change the approach to getting to the happy path. Perhaps what we need first is a marketing storey for releasing "alpha" software as part of core?

@Ravenstine
Copy link

Ravenstine commented Jan 17, 2020

This RFC proposes adding FastBoot into the default Application blueprint, turned off by default. [...] Adding a SSR experience into Ember would nudge developers in the right direction.

I don't understand how that follows. If it's turned off by default, how does that make SSR more of a first class citizen besides making FastBoot yet another package that gets pulled in? Adding another package in node_modules/ just in case someone wants to use it seems like a waste. There's probably a better case to include other add-ons like Ember Concurrency in case people want it, since that add-on sees far more use than FastBoot.

The way I see it, a person learning about FastBoot and wanting to use it already has the option to:

ember install ember-cli-fastboot

And now we're talking about essentially them setting:

FASTBOOT_ENABLED=true

Both are one step, but the latter means downloading more packages prematurely that likely won't be touched in most apps. If someone can't figure out the first method, they probably shouldn't be using FastBoot.

FastBoot, in its current state, is an expert tool. An expert is going to know to go looking for an add-on that does SSR, and I really don't know of any serious contenders to FastBoot for Ember. People new to Ember usually aren't going to be concerned with SSR, and by the time they are it's too late anyway if it's just disabled. In fact, it will be disabled the majority of the time unless FastBoot becomes more seamless(easy to debug, no need to use guards, Shoebox is fully automated).

I posit that Ember should be encouraging more SSR.

Is there something preventing Ember developers from knowing about SSR or finding out about FastBoot when they believe they need SSR?

mcfiredrill: Compare this to someone who actually wants to use fastboot, the hurdle is huge. [...] Documentation lives on another domain (ember-fastboot.com), there are multiple pieces
(fastboot-app-server)

Referencing it more in the docs seems like a good idea, so people know that SSR with Ember is a thing.

While I don't think there's really harm in adding a server.js file to the blueprint that uses fastboot-app-server, it, like FastBoot itself, is an expert tool. Under most circumstances, you can't just start using fastboot-app-server and expect it to do what you want out of the box. It will usually require configuration and knowledge of the server requirements and what it takes to make an HTTP server publicly accessible. Someone who knows that they want to set up a FastBoot'd Ember app is going to have to figure out whether they need fastboot-app-server, install it, and configure the server.js file to what they need, making putting it there in the first place unnecessary. In other words, they're not really being helped, I think.

@mehulkar
Copy link
Contributor Author

If it's turned off by default, how does that make SSR more of a first class citizen

It (1) forces adding documentation to emberjs.com (2) sends a signal that this is a worthwhile thing to try (3) is food for the curious (e.g. I wasn't interested in trying out glimmer components until they were part of the blueprint).

Is there something preventing Ember developers from knowing about SSR or finding out about FastBoot when they believe they need SSR?

Personally, I didn't know that client side frameworks could be rendered on the server until FastBoot was announced. I would not be surprised if new developers who start with frameworks like Ember or React don't know this either, but maybe it's a common enough point of conversation these days that every developer knows.

downloading more packages prematurely that likely won't be touched in most apps. If someone can't figure out the first method, they probably shouldn't be using FastBoot.

I don't think this is a fair assessment. Developers who don't know that SSR is an option will not know to look for it.


I think SSR opens doors to other things that can happen on the server that would make Ember so much more compelling as a productivity tool. None of this experimentation will happen if FastBoot remains a distant, scary cousin.

Although the comments in this RFC are mostly against, its heartening to hear that the general sentiment is that "FastBoot needs a lot of improvement". That was why I wrote this RFC. I'd love to see other suggestions of how to accomplish this as well.

@Panman82
Copy link

Having not used FastBoot, what are the "happy path" constraints this would introduce? I know of the DOM access thing, but as the RFC mentioned, I think {{modifiers}} will help guide folks in the right direction anyway.

The majority of these caveats relate to object initialization, and there may be a clever way of teaching this in one place.

Details?

This means creating generators for Node-style tests that make requests directly to the server

Although unrelated, I would like an easy solution for node tests for addons, to help test build config stuff.

@luxzeitlos
Copy link

If we do this I think we need ember new my-app --no-fastboot! But maybe we should talk a bit more about ember new in general? ember new my-app --yarn --no-welcome --no-fastboot becomes a bit long.

@Gaurav0
Copy link
Contributor

Gaurav0 commented Jan 21, 2020

Reducing that complexity is exactly what this RFC aims to do.

This RFC by itself does nothing to reduce complexity.

As far as I can tell, documentation is still sparse and disconnected from Ember, usage is still uncertain, the comments in this RFC make it clear that the developer story (and perhaps user benefit for some/many apps) is still questionable.

Efforts would be better spent fixing these issues.

Developers who don't know that SSR is an option will not know to look for it.

Adding FastBoot as a top level section to the guides would fix this issue.

One more thing I'd like to add: FastBoot is not currently a well maintained library. Also, LinkedIn does not sponsor FastBoot development. See https://github.com/ember-fastboot/ember-cli-fastboot/pulls. No pull requests have been merged since November 4. Adding more members to the FastBoot team could help here.

@NullVoxPopuli
Copy link
Contributor

We could add SSR docs to to emberatlas.com

@webark
Copy link

webark commented Jan 22, 2020

Currently, the set of Ember applications supported is extremely limited. As we fix more issues, we expect that set to grow rapidly. See Known Limitations below for a full-list.

The bottom line is that you should not (yet) expect to install this add-on in your production app and have FastBoot work.

This (coming directly from the readme of fastboot) is evidence enough why this should not be included by default, or even heavily documented. Any efforts that are spent should be in making this a viable solution, or even just getting a few dedicated maintainers, before we try to include it in any kind of “happy path”.

@mcfiredrill
Copy link

Currently, the set of Ember applications supported is extremely limited. As we fix more issues, we expect that set to grow rapidly. See Known Limitations below for a full-list.

Is this still true? If you check out the known limitations you will see No didInsertElement, which I believe is being superseded by modifiers, and No jQuery, well, jQuery is not included by default anymore, although I'm sure a lot of apps still use it.

Not sure about prototype extensions.

@Gaurav0
Copy link
Contributor

Gaurav0 commented Jan 22, 2020

Currently, the set of Ember applications supported is extremely limited. As we fix more issues, we expect that set to grow rapidly. See Known Limitations below for a full-list.

Is this still true? If you check out the known limitations you will see No didInsertElement, which I believe is being superseded by modifiers, and No jQuery, well, jQuery is not included by default anymore, although I'm sure a lot of apps still use it.

Not sure about prototype extensions.

Modifiers are not run in FastBoot either. AFAIK, prototype extensions issues still exist in FastBoot.

@Ravenstine
Copy link

Ravenstine commented Jan 22, 2020

Is this still true? If you check out the known limitations you will see No didInsertElement, which I believe is being superseded by modifiers, and No jQuery, well, jQuery is not included by default anymore, although I'm sure a lot of apps still use it.

Not sure about prototype extensions.

I just did a test and {{did-insert}} definitely never invokes anything in FastBoot. This means the README for FastBoot should be updated.

This is only one problem I think needs to be fixed before FastBoot should be heavily suggested or come installed by default. Here are some others I'm thinking of:

  • Errors on the backend shouldn't prevent the app from booting in the browser. It currently results in a white screen with an error message that isn't easily debuggable. There's an argument to be made for why it works this way, which is that a developer needs to resolve a problem on the backend before they continue developing, rather than letting backend problems pile up and fester. The problem here is that very minor issues can break the flow of development, causing the developer to resort to ?fastboot=false in order to fix them, even if it's also occurring in the browser in the first place. What I think needs to happen is that, at the very least, the app should be allowed to boot in the browser and any errors that occur in FastBootLand should be serialized and thrown in the browser as a "FastBoot Error". Some more advanced detection might be able to make the distinction between an error that can be debugged in the browser and one that only happens in FastBootLand, but perhaps that'd be fragile. IDK. (EDIT: This is already partly possible through the use of the resilient option, but that's basically sweeping the error under the rug)

  • Shoeboxing of HTTP responses should be done automatically by default. Right now, part of the purpose of FastBoot is defeated by the fact that, unless you intervene somewhere in your code, the app running in the frontend will make duplicate HTTP responses to the ones that already happen in FastBootLand. The app running in FastBootLand can store responses and other data in a "Shoebox", which is just a script tag with stringified JSON, which gets used in the frontend after boot. This feature isn't the easiest thing in the world to use. FastBoot, or perhaps ember-cli-fastboot, should come with automatic shoeboxing so that requests are already de-duped by default, meaning one fewer thing the developer will need to think about.

  • The sandbox in FastBoot needs to support more basic DOM and Browser APIs. What I'm about to say is blasphemous, but I think the idea that everything can and should be done using Ember APIs is too restrictive and it's also a fantasy. I don't think I've worked on a single Ember app that didn't use things like querySelector or requestAnimationFrame, or XMLHTTPRequest rather than fetch, accessing the document global or document.body, etc. This is where the philosophy behind FastBoot is hard to reconcile with reality; your Ember app code might be made to be FastBoot compatible by using guards everywhere, but your FastBoot output might end up being very different especially if you are bringing in outside code, React.js components, or custom elements. Even if you can guard everything and use placeholder elements, that can end up being a lot of work and isn't fun to do. I don't necessarily mind FastBoot being very minimalistic, but let's not kid ourselves into believing that it's plug-n-play.

  • Script tags should be evaluated, but never are are(as far as I know), which can be a problem for apps that load a 3rd-party dependency through a script tag. We are, of course, not supposed to do this with Ember, but the reality is that organizations have shared libraries that are used in this way. This problem can be solved by jumping through an extra hoop in ember-cli-build.js, but this doesn't seem ideal, especially if the dependency is being regularly updated outside of the Ember app's own release cycle.

FastBoot should be made a killer-feature of Ember if possible, rather than another thing people can use to say that "Ember sucks".

@tleperou
Copy link

From a business perspective, the SSR is a key feature to pick up Ember or another one. Indeed, referencing websites is critical. Generating an SSR ready application (FastBoot) and serving it (FB app service) sounds inseparable to me.

Does it make sense to ask users to pick up SSR or SPA when starting an Ember project?

The documentation can focus on those two different usages to teach developers the SSR capabilities and limitations of both worlds.

@webark
Copy link

webark commented Jan 24, 2020

I’m fully on board with adopting SSR out of the box, it’s just comments like

Only the most brave should even consider deploying this to production.

in the readme of the project don’t give me confidence in its current state, nor does the lack or recent development on it, nor the lack of recent RFC’s around improvements that could be made to it. I feel focusing on improving fastboot would have to be done before any kind of effort to include it by default can be done. It’s something that could be a focus now that octane is done, but didn’t see it in any official items to tackle next.

Copy link
Member

@rwjblue rwjblue left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm generally in favor of moving forward here, but this RFC doesn't address the primary issues with making FastBoot part of the default experience. Some examples:

  • Currently, the default system for rendering client side after FastBoot is to completely delete the DOM and render from scratch. Rehydration is a thing that we can use, but has "issues" that need to be ironed out in order for it to be enabled by default (and IMHO it must be enabled by default before we move forward with this RFC).
  • Interaction with the DOM prior to the application booting in the browser needs to be addressed. My personal proposal is to mark all interactive elements (buttons, input, textarea, etc) as disabled by default (with a way to opt-out if you have made your form work properly with "normal" HTML form post) and then reenable once rehydration has completed. Without this, users will have a very bad experience of attempting to interact with an element that will become something highly interactive, but anything they did before rehydration completed would be lost.

@mehulkar
Copy link
Contributor Author

mehulkar commented Feb 8, 2020

Most of the responses are about "this is why SSR doesn't work out of box". This is not relevant to this RFC as far as I'm concerned. For example, all apps installs Ember Data, but it does nothing if you don't use it, and it's not appropriate for all apps. And it can easily be uninstalled. The purpose of this RFC was to do the same for FastBoot. Maybe I'm overlooking something major, but it's not clear to me why the imperfections of FastBoot need to be addressed before it can be included in the blueprint.

As long as FastBoot is sold as a third party addon, it will remain one.

I'm happy to close this down if that is the general consensus, but to be honest, I haven't seen too many valid arguments against.

@webark
Copy link

webark commented Feb 8, 2020

@mehulkar ember-ajax was included by default, was basically a defunct product by the time it was removed, was never supported much outside of a single individual, and it’s use was in many ways discouraged for the past few years. Meanwhile, ember-concurrency is one of the most downloaded ember addons, has wide adoption, and still is mainly the product of a single individual.

Basically, I don’t think adding it by default would have any positive impact on its progression of adoption, or over all view of it as a viable solution, if anything it could simply turn people off more to it. And just cause it’s an “official addon”, doesn’t mean any extra time or effort will be put into it.

It, like all oss, needs champions and backers who are willing and able to take on some of the more hairy aspects of the project.

@mehulkar
Copy link
Contributor Author

There’s always going to be a counter example.

In any case, seems like the community has spoken here. I’m going to withdraw this RFC so I can focus my attention elsewhere. Thanks all!

@mehulkar mehulkar closed this Feb 10, 2020
@pzuraq
Copy link
Contributor

pzuraq commented Feb 10, 2020

I’m sorry you felt that way @mehulkar, just want to say I am strongly in favor of this RFC. We’re currently working out a staging system for RFCs, and my intention was to propose moving this into stage 1 as soon as that became available.

I believe like you that this should be the standard. I also think its premature to merge the RFC in this state, and we need to finish up a few things before that is possible. This is exactly how TC39 stages work, as they allow advancement before something is “finished”, and I think would be a massive benefit here.

@mehulkar
Copy link
Contributor Author

No hard feelings @pzuraq. If you want to keep this open or re-open this when the new system is in place, let me know.

@NullVoxPopuli
Copy link
Contributor

I think we should resurrect this RFC. Probably under a new number, so we can have a clean slate of discussion.

The thing is,

  • we don't have other ssr solutions
  • we need to make adopting SSR as easy as possible

I don't think it's reasonable to delay good ideas because other RFCs would make things easier, or whatever. It kills motivation and momentum.

I think a --ssr flag during ember new would be great.
And a new command to add features post-ember-new,
ember apply ssr
Or generically: ember apply <optional feature>

Related discord discussion: https://discord.com/channels/480462759797063690/927566118456008785/927585404213932043

@mehulkar mehulkar reopened this Jan 4, 2022
@mehulkar
Copy link
Contributor Author

mehulkar commented Jan 4, 2022

Re-opening this to continue the conversation, but probably won't be able to start an entirely new RFC. If anyone is interested in addressing some of the pre-reqs as smaller RFCs (if that's what's required), feel free to reference this in your work!

@webark
Copy link

webark commented Jan 4, 2022

I think a --ssr flag during ember new would be great.

What would this do?

we need to make adopting SSR as easy as possible

Then shouldn't the priority be ironing out the kinks in fastboot? It looks like some progress on a beta has been done recently, but there hasn't been an official release in 2 years.

Why is making adding a broken experience easier a higher priority then fixing the experience?

And a new command to add features post-ember-new

Isn't this what ember install does? What is it that apply would do that install doesn't?

@mehulkar
Copy link
Contributor Author

mehulkar commented Jan 4, 2022

Then shouldn't the priority be ironing out the kinks in fastboot?

We're using FB successfully for years now. Sure there are "kinks", but they haven't blocked anything from getting to production. Moreover, I think it's time to admit that the current plan of record isn't working / hasn't worked. I still believe (as I did when I first wrote this RFC) that it is more likely that "kinks" in a core feature get ironed out more quickly than in a community addon.

@mcfiredrill
Copy link

Just wondering if anything ever came of this?

staging system for RFCs

@NullVoxPopuli
Copy link
Contributor

What would this do? ( --ssr )

apply the partial blueprint to add SSR support to an existing app (alias for running ember apply ssr (which... apply should probably be a pre RFC, which... I need for work anyway)

Isn't this what ember install does? What is it that apply would do that install doesn't?

ember install does the post-install hooks, yes, so, I suppose we could implement the above --ssr flag to be an alias for ember install ember-fastboot post app generation, but that'll be slower than apply a diffs and codemods.

We have options, I'm happy with whatever is implemented first, because their path blocks the other, and they're cross-compatible, so I think we should prioritize shipping whatever makes sense when we get to implementation.

@mcfiredrill
Copy link

#579 (review)
Should we make RFCs to address the issues brought up by @rwjblue and others regarding fastboot functionality, or should this just be handled in the fastboot repos? (maybe this is another argument for including fastboot in core, we can create RFCs for fastboot related projects more easily? 🙃 )

@webark
Copy link

webark commented Jan 5, 2022

We're using FB successfully for years now. Sure there are "kinks", but they haven't blocked anything from getting to production.

Then the documentation and read me for fastboot should be updated. Part of the desire for this was to spur adoption. So this is for people starting a new application, not augmenting an existing one. And people who have experience with ember, will know to just install the addon. So the main target for this will be people who have less familiarity, and are starting something new.

If that is the “target audience” for this feature, then having one of their first impressions of a core feature being “Don’t use this in production, and the use cases are quite limited” doesn’t seem like a positive one.

If this is not the case, and it can be wildly adopted, then the fastboot repo should be updated to reflect that reality, and documentation added to the main ember docs.

If the purpose of this is just to force warts upon people so they will get more attention, that runs contradictory to the “ease adoption” reasoning. And something like ember data is a core package, but it’s warts had/have been known for years, but not much progress was made regardless of it being a core integration.

Perhaps the 3.x version that is currently in beta addresses this, and if so i think it is a great idea to easily enable. But until that project is ready, i would advise against against trying to use it as a tool to direct effort towards fastboot.

@mehulkar mehulkar changed the title SSR by default Add fastboot to the default package.json Jul 15, 2022
@wagenet
Copy link
Member

wagenet commented Jul 25, 2022

It seems to me that we definitely could use some better messaging around the state of Fastboot. So we can at least use this as a place to discuss that.

@mehulkar
Copy link
Contributor Author

mehulkar commented Nov 3, 2023

Going to close this down as I'm not sure when I'll ever be able to follow up on this. Feel free to take this branch/text of this RFC and open again if anyone else is inclined.

@mehulkar mehulkar closed this Nov 3, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-Proposed In the Proposed Stage
Projects
None yet
Development

Successfully merging this pull request may close these issues.