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

Consider making the can package the recommended way of using CanJS #3849

Closed
chasenlehara opened this Issue Jan 19, 2018 · 3 comments

Comments

Projects
None yet
2 participants
@chasenlehara
Copy link
Member

chasenlehara commented Jan 19, 2018

This was mentioned in a forum post by Justin and came up during our usability study; users are sometimes confused and intimidated by the number of packages needed to get started with CanJS. Additionally, our guides typically use the can package because they use JS Bin, but we explicitly tell people that’s not how they should build apps, which creates a disparity between how we show CanJS vs. how we want people to use it.

This issue is for more thoroughly considering the above problems and enumerating potential solutions. Note that this is not a proposal for anything in particular, but a starting point for our conversation.

@frank-dspeed

This comment has been minimized.

Copy link
Contributor

frank-dspeed commented Feb 11, 2018

I think the current module way is great we could simply write tutorials about how to compile a custom canjs can version or how to use can global namespace stuff to get a can object.

That means we change near nothing but make clear how the can.* gets build. Then we Also introduce can.all as the general way to use canjs and in donejs we introduce the modules. and reference there how they could get a global can.* from the modules

then stealjs tree shaking can strip down the main canjs build to only the used functions in production builds.

Consideration

It saves no learning effort if we bundle to can.* as every new user still needs then to learn defineMap defineList connect set-algebra and stache. there is near no extra effort to learn that this are diffrent packages it makes no diff if i need to remember the function name or the package name which i assign a name on import.

@frank-dspeed

This comment has been minimized.

Copy link
Contributor

frank-dspeed commented Feb 11, 2018

i think a new can.all plus can.Component alone in tutorials is a nice reduction from using stache and defineMap for basic examples

@chasenlehara

This comment has been minimized.

Copy link
Member Author

chasenlehara commented Feb 8, 2019

We’ve done this as of CanJS 5.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.