Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Consider making the can package the recommended way of using CanJS #3849
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
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.
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.
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.