Lets embrace chaos and make division easy

CanJS
1

The following are some random ideas on the future of CanJS (and likely DoneJS).

CanJS 3.0 was largely about long term cost of ownership. We did nearly everything we could to make CanJS accomplish this goal. While I don’t think many people value this, it has at least resulted in improved code quality and faster releases.

But people don’t value this. It’s important to find something they do value.

I’m a big believer in compose-able and federated construction of applications. However, there’s been a substantial blow-back to these forms of applications with things like:

  • the global reducer (reduce pattern)
  • immutable data structures or languages (elm)

These things represent an understanding that dynamic code is difficult to understand. But while reducer type patterns simplify code-flow, they don’t lend themselves to compose-able state mechanisms.

I think CanJS has an opportunity here to make dynamic code that supports mutations easy to understand. Multiplication with roman numerals was hard, division was almost impossible without an abacus. With decimal places, elementary school students can multiply and divide. The tooling made it possible to understand.

I think CanJS could be the tool that makes object-oriented and mutable code scale. We can accomplish this by:

Finally, I think we should return to a simplified can package with a small set of utilities:

var age = can.value(5),
     me = can.Object({first: "justin", last: "Meyer"})
     hobbies = can.Array(["hip-hop","wrastlin","typing"]

Plus a can.element and can.jsx that create custom elements. We should still encourage people to use the packages individually, but when “getting started”, we can show can.

1 Like
2

I like the thoughts about CanJS 5.0
I just wonder what it means: “But people don’t value this”?

3

I just wonder what it means: “But people don’t value this”?

I mean that people don’t pick frameworks based on how well they provide “longevity”.

4

Yes you are right, for example here in my country people pick frameworks based on popularity, they like to find tones of tutorials and stackoverflow answers instead of thinking about engineering stuffs, I always found this silly.

5

I’m going to disagree on this:

I mean that people don’t pick frameworks based on how well they provide “longevity”.

I had a bit of a discussion on gitter (Kevin caught some of it) and my previous employer that I left 2 years ago come end of Jan 2018 are still on v1.6.1 of Ember js since moving is a nightmare. I verified by going to the application site and then opening up the dev tools and checking Ember.VERSION:

image

I have been using Log4Net for ages and there have been the odd bunch that have complained because there has been no movement on the project for years. Yet this is exactly something I strive for in my own projects. When I make changes I try to keep them manageable but sometimes a design decision really does need a rethink. Other times technology forces us in a direction such as .Net Core.

Just a note on the visualisation. It is fine for displaying what is happening but having visual tools for design is not something I would recommend. The service bus I was using way back went commercial and that led to me writing my own that was a FOSS. However, NServiceBus tried to implement a visual design tool and eventually canned the idea.

All the changes in Ember really annoyed everyone on our project and we would spend weeks on upgrading at times since we needed to refactor the breaking changes and then we were back to a cycle of regression testing. This was a system that brought together SAP, MS CRM, and a customer Billing System. It really was no fun and it is the reason why it has not been upgraded from that old Ember version.

I think they implemented some Polymer components.

Anyway, I, for one, do value stability with incremental changes. It takes me quite a while upgrading my simple solutions when CanJS changes and I know that companies would rather spend money on functionality than upgrading front-end frameworks.

1 Like
6

Changing with the times essentially? Seems like there is a lot of new ideas on the horizon…

Even stuff like this: https://www.arxiv-vanity.com/papers/1712.01208v1/

Might not be avoidable right now, but maybe easy upgrades will be the focus again when things calm down in the future. Perhaps by then code upgrades will all be automated by AI (only kind of joking).

Anyways, any dynamic, smart, or self-aware system will need to come with good tooling probably. I feel like CanJS and StealJS are the most dynamic/self-aware and would benefit the most from some sort of custom inspector or high-level overview visualizer that helps the user see the dynamic/mutating nature of the system and key objects.

I do believe there is a lot of value in robust micro patterns that can live independent of a global facility, but it can be very hard to comprehend how everything mingles.