If only we had a tool to transpile our ES6 Code to ES5
I think we should consider writing our framework tools using ES6 instead of sticking to ES5. I have grown accustomed to the convenience and signal-to-noise ratio of ES6 features and when working on our OS stuff I find our adherence to ES5 syntax makes our code harder to follow and lacking conveniences like arrow function and the spread operator. It’s 2017 now, it’s time to use ES2015. We can transpile with steal to keep browser support.
(One exception might be aysnc/await and generators, as the transpiled code gets very very large quickly)
Stache should take an ES Observable by default
After watching Justin’s kefir-stream demo I was amazed to see we could just use the .value helper to get a value out of a kefir-stream. Which got me thinking, what if streams, or specifically the proposed ES Observables, were the default way of using stache, aka not the .value thing, and we just made a special case to easily recognize can-observables?
Then anyone could use stache for a view layer / template, with any observable/stream (Rx, Kefir, xstream… etc), with just a simple adapter to and from ES observables (Kevin has written all these adapters already, I think). Stache would no longer be only usable by can-js and I think could open up more possibilities and maybe get more contributors.
We wouldn’t lose anything either as we could just have the special could just have the special case be our can-observables
Interop with a standard (proposed at least) would be great, as well as defining a nice isolation boundry for stache and view stuff within can.
@bigab, this has been a common discussion topic. Transpiling would be fine for “single export” packages. For example, packages like can-observation where no one should be importing can-observation/something-else. However, packages like can-connect would be tricky. We’d keep everything in a src folder, but on publish, need to “build” to the root folder. I think this would get messy.
This gets even trickier with tests, all of which are imported like package-name/some-module.
Some care would need to be taken to make sure all of these parts work together.
Yeah, I’m not saying we should bundle them necessarily, just use babel (one way or anther) so we can use ES2015 features and maybe convert the ESM imports to CJS imports