Move low-level utilities into another project

[justinbmeyer]

A. In order to have us release low-level utilities that aren't strongly associated with the CanJS brand (and less likely for people using other technology to use), we might come up with a project name for these utilities. This also has the advantage that CanJS can represent a "framework" more cleanly and only focuses on it's core features.
B. I argue that because most of these utilities will still depend on other utilities in this ecosystem, we should name them with some sort of prefix or suffix. For example x-assign or assign-x.
C. My suggestion was assign-4u b/c it's short and catchy.
D. We are open to other ideas. But I'd prefer alternate suggestions instead of criticisms of 4u at this point.

Please provide naming suggestions below. If you'd like to reference one of the points above, feel free to call them Point A, Point B, etc.

[andrejewski]

Alternative suggestion: no prefix or suffix, put it all in the Bitovi org until they get big enough like Done and Steal.

Elaborating:

What happens when there are naming conflicts?
We rename to a more specific name (not prefixed/suffixed for branding purposes, actually useful stratification) or not publish; assign is taken but our assign is no better than object-assign. We have pretty bad NIH syndrome. Naming conflicts will probably makes us reflect on what actually needs to be developed by us to deliver value to our users.

Nested elaboration for #3426 (comment)
If there isn't a good solution we make one, that doesn't change. As far as package alignment, I think that trying to provide everything once with no overlap is not a worthwhile concern. Bundle size does not matter to me as developer. Concerns worth prioritizing are delivering value, runtime performance, and correctness. With jQuery, integrators have very limited options to isolate their dependencies. With such a large surface area / API contract, relying on jQuery would definitely suck, but that's an extreme. A historical extreme.

What does "big enough" mean? Individuals are big enough, the collection is big enough?
Big enough means that for each project there is an ecosystem of tooling around a concrete goal. Steal is big enough for an org and has a clear mission in module loading and bundling. Whereas can-ndjson-steam, can-dom-events, and can-view-model have no relationship and thus should not be grouped together.

How do these get documented?
We can have bitovi.com/os/<project-name>/<doc-page> or os.bitovi.com serve these purposes, note with this centralization would make a lot of sense to have bitovi.com/os/steal direct to the Steal homepage and same with Done.

Why "brand later" instead of immediately?
First, too much branding causes indirection. In order to find out about Bitovi, you have to go through Can/Done/Steal. If our goal is to better funnel new clients to Bitovi, we should not put obstacles in front of people for no reason. When something gets big enough, as defined above, we can know for certain it is worth our efforts to brand (cuz that work is not free) and that it serves a direct user need. Not all projects will be winners, why brand their tombstones?

We generally try to keep our OS out of Bitovi org because its for client projects and it keeps access rights a bit easier for non-bitovi's to contribute.
Make a new org for client projects, with all the heightened security they demand (cough 2FA). Bitovi is a public facing company due to our open-source and when/if projects get big enough then outside contributors can become members of those orgs.

Late Edit: What I am thinking, in terms of marketing is something like this on the footer of every README. It goes a lot further for SEO and brand awareness than can- could ever hope.

[justinbmeyer]

Proposal: 4u 4ujs.com

Examples:

ajax-4u
assign-4u
event-4u
dispatch-4u
drag-event-4u

Identity:

• A bunch of low-to mid-level utilities useful to everyone on any project.

[JaneOri]

-aug short for augmentation, as in: added on top of anything
ndjson-aug
assign-aug
event-aug

[justinbmeyer]

Proposal: JavaScript++ javascriptpp.com

Examples:

ajax-pp
assign-pp
event-pp
dispatch-pp
drag-event-pp

Identity:

• A bunch of low-to mid-level utilities useful to everyone on any project.

Pro:

• This could effectively be a rebrand of jQuery++
• pp sounds funny

Con:

• pp sounds funny

[matthewp]

Can you use ++ as the suffix there? ajax-++ or just ajax++?

[justinbmeyer]

@matthewp I really doubt we can use ++. I know this is something urls normally escape. I bet it would get super weird. Though it would be awesome if we could.

[matthewp]

SEO could be an issue with that name though.

[phillipskevin]

I'll throw out nix - like... the unix philosophy of doing one thing well.

Sounds better as a prefix I think: nix-ajax, nix-assign, etc

Cons:

• nix is also a word that basically means "reject" or "nothing"
• I don't really like it

[matthewp]

I don't have a specific name in mind at the moment, but I wanted to comment in case some else likes this idea too and is more creative than me.

I think it can be a useful exercise to think of the name last but instead focus on a couple of other things:

1. What is the essence of the brand. In this case it is clearly about low-level utilities as the OP describes.
2. Is there an aesthetic that helps the user feel that brand?

So my idea is to base the branding around the idea of a construction site. You see the scaffolding a building, people using heavy equipment to build it. Construction signs etc.

[justinbmeyer]

@matthewp what about -works:

assign-works
drag-event-works
fire-works //<-- not sure what this does, but I want to find out

[matthewp]

Yeah, that's not bad. Either works or maybe even just work without the s. Overall branding could be WorkJS with a website with construction theming.

[cherifGsoul]

What about javascriptstd (standard library for javascript)

[justinbmeyer]

@andrejewski In my experience with what clients care about, initialization performance is often more important than runtime performance. Though there's the following considerations:

1. Usually runtime performance is easier to get right than load-time performance. After all, network is still slow compared to even mobile processing power.
2. The overlap created by multiple object-assign's might be small. It's 559 minified/gzipped bytes. However, that could quickly add up and be significant. Especially as there's lots of packages, and likely lots of other utils that would be needed.
3. Most analytics let us know if a user drops before full initialization ... however, they don't tell us that someone dropped b/c some part of the app was taking too long (so clients might be miss-prioritizing based on faulty data).

Also, while it's useful/nice to target our OS to ourselves, we have to be careful. Our tastes might differ from those of other developers that are worth targeting products towards. Many people care about the size of their JS payload.

This is why I agree with @matthewp 's sentiment that we need to focus on who this is for. IMO, this is targeting people who want a "medium" complexity toolchain similar to lodash. Especially one more focused on the DOM and things like task-queues, ReadableStream transforms, etc.

Like lodash, they don't want to spend too much time evaluating every package they consume individually, and judging its quality. They want to have some baseline expectation that it:

• works in specific browsers/environments
• is tested
• is actively supported

In some ways, I see people being very attracted to a hegemony after the left-pad incident.

Another thought is to split this into two projects:

1. A lodash for the DOM side of things.
2. A lodash for the JS side of things built around can-reflect. can-reflect is designed to allow lodash like utilities on any decorated data type. assign( new Map(), {foo: "bar"})

One more thought to sneak in ...

The real core value we are trying to give people ... is saying here's some stuff that's tested and supported. Those could be packages that other people build ... it's just harder for us to support them. But it might be valuable to say "here's what Bitovi uses ... we do a lot of work .... so if any of these things go wrong, you can bet we are going to be trying to fix it".

[mikemitchel]

Proposal: wrx wrxjs.com

Springboarding off @matthewp & @justinbmeyer works idea:

wrx == works (insert road sign logo here) or WR🛠 ?

Similar branding to DoneJS and CanJS - it just Works!

but has the nice 3 letter extension, with an X, but the x is not just for show (ie. worx) but takes the place of 2 letters to get us down to that 3 letter extension ideal - code efficiency !

assign-wrx
ajax-wrx
fire-wrx (what DOES this do ?!?!)

[bmomberger-bitovi]

Cherif said in #3426 (comment)

What about javascriptstd (standard library for javascript)

I like the idea of promoting it as a standard, but I'd use -sb (for JS Standard Base) or -sp for (JS Starting Point) instead. Some brief research says that the two letter forms of this aren't used for anything in the JS world, and at very least JSSB only name clashes with a bank.

[cherifGsoul]

@bmomberger-bitovi yes that was the idea, I like Standard Base also, I just found https://github.com/stdlib-js/stdlib so this can clashes with std I want to say bedrock but it is taken too https://github.com/digitalbazaar/bedrock so maybe Javascript Standard Foundation (JSSF) and I found this https://github.com/JSFoundation close to that name.

[frank-dspeed]

i think maybe that should get even more splitted up by its tool type for example if its a class or decorator or cjs script something like that

wasn't canjs about all this little utils?`maybe brand it something like:

• bitovi-framework bf-xxxx
• bitovi-helpers bh-xxxx
• bitovi-decorators bd-xxxx

This is the best of my suggestions

naming them can-utils-* as i think moving out to a other organization is not needed as canjs is designed to work as single modules as also combined as whole framework if something don't works as a single module then this should get renamed to can-shared-* maybe

[justinbmeyer]

After today's DoneJS contributors meeting, we decided:

• that we'd namespace our packages under @bitovi
• create a site like bitovi.com/packages. These packages would be organized by functionality.
• we will use generic names so we import like require("@bitovi/assign").
• canjs.com will have can-define, can-stache (or jsx), can-element (or can-component) as its core, but these will be directly listed on its site. It will have an ecosystem dropdown.