-
-
Notifications
You must be signed in to change notification settings - Fork 407
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
Conversation
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? |
In general I disagree with fastboot usage. |
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'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.
Why? To clarify do you disagree disagree with FastBoot or with SSR in general?
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? |
There was a problem hiding this comment.
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.
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. |
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. |
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.
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 :/ |
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. |
@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:
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 |
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 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).
Is there something preventing Ember developers from knowing about SSR or finding out about FastBoot when they believe they need SSR?
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 |
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).
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.
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. |
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
Details?
Although unrelated, I would like an easy solution for node tests for addons, to help test build config stuff. |
If we do this I think we need |
This RFC by itself does nothing to reduce complexity.
Efforts would be better spent fixing these issues.
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. |
We could add SSR docs to to emberatlas.com |
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”. |
Is this still true? If you check out the known limitations you will see Not sure about |
Modifiers are not run in FastBoot either. AFAIK, prototype extensions issues still exist in FastBoot. |
I just did a test and 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:
FastBoot should be made a killer-feature of Ember if possible, rather than another thing people can use to say that "Ember sucks". |
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. |
I’m fully on board with adopting SSR out of the box, it’s just comments like
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. |
There was a problem hiding this 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.
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. |
@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. |
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! |
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. |
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. |
I think we should resurrect this RFC. Probably under a new number, so we can have a clean slate of discussion. The thing is,
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 Related discord discussion: https://discord.com/channels/480462759797063690/927566118456008785/927585404213932043 |
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! |
What would this do?
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?
Isn't this what ember install does? What is it that apply would do that install doesn't? |
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. |
Just wondering if anything ever came of this?
|
apply the partial blueprint to add SSR support to an existing app (alias for running
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. |
#579 (review) |
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. |
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. |
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. |
Rendered