CanJS after 6.0

Now that the dust has settled after the CanJS 6.0 release, I wanted to start a discussion around the goals for CanJS in 2020.

The goal of this post is to start a discussion, not to make any final decisions. We’ll likely do follow-up surveys and discussions and of course we’ll be user testing and looking for feedback as we start bulding things.

This post is pretty long, but not all of the ideas are really fleshed out. Feel free to skim it or skip around to things you find interesting.

Below are some ideas that I have to start the conversation, but please feel free to post whatever ideas you have to make CanJS more fun to use, better at solving problems you have, or make you more likely to recommend CanJS to other developers.

Focus on web components that integrate with any framework

With StacheElement, CanJS has a compelling solution for building web components. This sets it apart from other frameworks that might have a way to create web components using a build tool, but primarily focus on building components using framework-specific APIs and not true web components.

We could continue to build on this strength by improving the experience of building web components with CanJS. This would probably include reducing the size of StacheElement by either removing parts of stache that are used less often or completely replacing stache with another templating solution that isn’t as large. We could also build tools to make it easier to integrate our web components with popular frameworks.

Focus on the unique features of CanJS observables

The metadata built in to CanJS observables allows unique features like the dependency graph in CanJS Devtools. We should continue improving this feature, but we could also build other tools like this that are only possible because of information our observables contain. This might be tools for visualizing which data requested from the service layer is actually being used and where it is displayed in the UI. This could also be things like tools for automatically generating unit tests.

Focus on first-time Developer Experience

DoneJS allows you to scaffold out an app that uses CanJS and has generators for components, models, and other things. But many apps don’t need everything that DoneJS provides and some users are confused about the relationship between CanJS and DoneJS. We could provide a much simpler tool for scaffolding CanJS applications, a-la create-react-app.

Focus on integration with popular backend frameworks

One of the things that really helped VueJS gain popularity (at least from my outside perspective) is its close relationship with Laravel, a very popular PHP framework.

There are many other backend frameworks that don’t have “go to” JavaScript frameworks. Building tools to easily integrate with these backends and marketing to those communities could really help build the CanJS community.

Focus on making CanJS easier to learn

Over the past several years, we’ve really put a lot of focus into CanJS’s documentation, but there is a lot and it can be overwhelming for new users. We should continue to simplify canjs.com and we could also build integrations between the demos we show in our documentation and our API docs. This could allow you to build a guide step-by-step, but also see inline documentation when you hover over one of the APIs you are using.

What do you think?

These are just some ideas that I have. We might pick one and start writing up proposals and sending surveys. We might take pieces of many of them to build out a roadmap. Maybe this conversation will surface much better ideas and we’ll do none of these.

Please feel free to comment below with your thoughts on these or any other ideas you have for what the CanJS core team should be focusing on.

1 Like

There’s a proposal opened by @matthewp for scaffolding canjs applications https://github.com/canjs/canjs/issues/5383

1 Like