Rough meeting notes:
Attendees: @BigAB, @chasen, @ilyavf, @pYr0x, @justinbmeyer, @phillipskevin, @marshallswain, @matthewp, & @obaid
Directional shift with CanJS 3:
- Previous misson: simple and efficient web framework for complex apps
- New direction: handling the progressive march of technology enhancement
- How do we make it so developers can deal with tech changes?
-- Make upgrading easier
-- Forward-compatibility: the code that you write will be valuable as possible over time
-- Open to experimentation: explore new ideas; enable mixin behavior; embrace decorators
- First step: smaller, independent repositories
-- More isolation and packages
- Question: what will 4.0 look like?
-- Answer: Justin will probably write a roadmap article
- Concerns: people don’t like to upgrade, so they’ll rewrite instead; how long do apps stick around?
-- Upgrades have been hard, so if we make it easy then we’ll get more people to upgrade
-- Keep the current users happy! We want to continually increase our user base.
-- Some people don’t upgrade old code because of lack of test coverage
-- Opt to use native technologies from the browser; custom elements for components, etc.
-- Less of a need to completely rewrite if you follow best-practices
Topic: same dependency at different versions
- Problem with the npm approach: duplicate loading of packages at different versions
-- Keep infrastructure modules very stable and as small as possible to combat that issue
Topic: custom generators
- Solutions are not mutually exclusive
- Solution 1a could use a
templates.json file or read from the filesystem
- Codemods are more complex but allow for greater flexibility/transforms