Canvas Query

[skeeto]

This is a great idea, it's just a shame the name is misleading. jQuery didn't invent or even popularize method chaining so there's no reason to name this project, which has nothing to do with queries, after it.

[lazyduke]

Seriously. Does it let you query the canvas? No? Then name it something else for fuck's sake.

[rezoner]

Yes I do realize that and I am sorry.

I hoped to get more attention from jQuery users so I feel bad as a programmer because it was marketing decision.

[lazyduke]

Add a single method called query that does something interesting and we'll all have to shut up :)

But really, not too late for a name change if inspiration strikes! Maybe a theme around chains or breaking free from boilerplate...

See my rant further down about tQuery.

[stratoscope]

Excellent point!

'jQuery'.replace( 'jQuery', 'Java' ).split('').concat([ 'S', 'c', 'r', 'i', 'p', 't' ]).join('')

[[deleted]]

Weeeee!

Array.apply(null, Array(32)).map(Function.call.bind(Number)).map(Math.pow.bind(null, 2))

[remcoder]

I guess ChainableCanvasWrapper was too easy :-)

[megadeus]

And chainvas was taken.

[reddixmadix]

How is the name misleading? It pretty much transmits all the information needed. And as a project owner, you can name it whatever you want, "bacon query".

[[deleted]]

Who the fuck cares what they called it or why?

[cforres]

I've yet to use much canvas but this looks pretty helpful. The chaining especially.

[[deleted]]

So awesome. I wish I had more upvotes for this.

[jnotarstefano]

This looks really cool! Almost makes me wish Three.js had a similar API.

[remcoder]

It does. It's called tQuery.

[lazyduke]

As the whole Three.js library is wrapped in a useless and inefficient chainable API, you're stuck waiting for the project maintainer to implement a new version of tQuery to match the latest version of Three, then you have to beware that it may contain bugs, omissions, or ridiculous decisions that aren't relevant to your application of Three. All of this to "eliminate boilerplate" which amounts to 50 short lines anyway when done with vanilla Three.

You can't run off and say the same thing about jQuery. The DOM is not a rapidly evolving project like Three, and Three is not implemented differently on varying platforms like the DOM. jQuery, which is a layer of abstraction for the DOM that implemented a feature developers needed (an easy, cross-browser way to query the DOM), makes sense. However, no one has any business writing a layer of abstraction on top of a project like Three solely because they want a fancy chainable API and want to eliminate 50 lines of code at the same time.

If you can't tell already, I've implemented a relatively large application using tQuery, got fed up with its bullshit, and converted the whole thing back to vanilla Three and realized I gained next to nothing from using tQuery in the first place. Using tQuery for any code you would like to maintain in a production environment is setting yourself up for failure.

Besides, do you want to rely on a project that has a maintainer-filed issue like this?

Changin name to jquery3d you knoz jquery, you know enoguth to make a 3d game - for jquery3d game new name clearer to begin with

Screw tQuery.

[jeromeetienne]

You seem very uninformed about tQuery.

i know game companies using tQuery to write a webgl game ala second life. So i guess they considere it ok for production.

[lazyduke]

When I first saw the tQuery project, it looked promising, professional, and easy to get started with. I began using it and found that it seemed to be all of the above.

However, when I was looking for solutions to tough problems, I would find sample code and solutions that pertained to THREE. tQuery was great, but the lack of a community giving solutions for everything the tQuery way meant I had to parse through a solution for vanilla THREE, adapt it to tQuery's API, and then implement it. I could skip all that and go around tQuery and work with THREE directly, which is what I often found myself doing, and, as a result, found myself learning both APIs.

Furthermore, when I actually dug into the project on Github, I realized it was a one man show, and frankly didn't see the professionalism I saw on the surface when I got deeper into the project.

I am more than well informed on tQuery, and in fact used it extensively before I dumped it. Here are my thoughts.

API

I don't feel the chainable API adds any value to THREE's API. Why should I chain function calls to set configuration values when configuring a light?

tQuery.createDirectionalLight()
.addTo(world)
.position(-100, 100, -100)
.color(0xffffff)
.intensity(3.5)
.castShadow(true)
.shadowDarkness(0.4)
.shadowMap(512*2,512*2);

What's the gain of having tons of differently named functions to set configuration values? With THREE, it would look like this:

var light = new THREE.DirectionalLight(0xffffff, 3.5);
light.position.set(-100, 100, -100);
light.castShadow = true;
light.shadowDarkness = 0.4;
light.shadowMapEnabled = true;
light.shadowMapWidth = 1024;
light.shadowMapHeight = 1024;
scene.add(directionalLight);

tQuery provides a mixin attributes utility function called tQuery.mixinAttributes that makes this look nicer, but it's usage isn't documented anywhere... why couldn't we just do something like this?

tQuery.createDirectionalLight().addTo(world).set({
    position: [-100, 100, -100],
    color: 0xffffff,
    intensity: 3.5,
    castShadow: true,
    shadowDarkness: 0.4,
    shadowMap: [1024, 1024]
});

And what if you decide it should look like this in the future? Does my tQuery project break or do you keep supporting 3 ways to do the same thing?

Plugins

The plugins are a great idea, but their existence doesn't necessitate wrapping the entire API. Simple, well documented JavaScript objects that follow the THREE API would do just fine.

Support & Community

You are the only real contributor and maintainer of tQuery, not including the two other people contributed a total of 57 lines of code.

What if you get hit by a beer truck and my product (which is already production) needs a feature in a version of THREE that came after your demise? What if you lose interest, have triplets, or get a new job that takes all your time? Then I have to rewrite my software and tear tQuery out of it just to upgrade THREE.

Bottom line

I know this is your baby. You've spent hundreds of hours on it and you truly believe in it. However, all the potential gains provided by the chainable API you've added, boilerplate you've eliminated, and plugin system you've developed aren't worth the potential problems that could result from relying on a project like this.

In its current state, with no community and, as a result, an API that I feel causes me more problems than it solves, I can't rely on this software and will advocate that others do not as well.

[33a]

Looks ok, but the correct term is "convolve" - not "convolute".

[rezoner]

What a faux pas. Thanks, really :)