re: Ready to use Progressive Web App template VIEW POST

VIEW PARENT COMMENT VIEW FULL DISCUSSION

Of course, using standards is a choice, and it's good for up to certain scale of an app.

That's the paradox: small pieces of code that can be shared online will actually look more complex. To get an example, you'd have to open-source a large app: basically what you did by sharing the in-house framework, but every app is different, and looks like you there did not reach the scalability and UI state management problems with its DOM manipulation approach. It's not marketing, it's just solving bigger engineering problems that only surface after a few years of app code evolution.

As I won't be able to share in a snippet a few years of the app code evolution and problems we've solved with React, I think it's impractical to continue this discussion. We have different experiences, so let's agree to disagree, and move on.

P.S. Here's the snippet from your library source, is it not?

/**
 * ZxQuery, a very lite subset of jQuery-like functions
 * internally used in Zuix for DOM operations.
 *
 * The constructor takes one optional argument that can be
 * a DOM element, a node list or a valid DOM query selector string expression.
 * If no parameter is given, the resulting ZxQuery object will wrap the
 * root *document* element.
 *
 * @class ZxQuery
 * @param {Object|ZxQuery|Array<Node>|Node|NodeList|string|undefined} [element] Element or list of elements to include in the ZxQuery object.
 * @return {ZxQuery} The *ZxQuery* object containing the given element(s).
 * @constructor
 */
function ZxQuery(element) {

Maybe you did not copy and paste jQuery source as is, but you definitely did copy its API and design decisions (e.g. having a new object which represents collection of selected elements that you pass around). jQuery latest does that in a more performant way, btw, borrows some standard functions like push from Array and uses for index loops instead of for in and Object.keys and hasOwnProperty to iterate in each. Have a look: unpkg.com/jquery@3.3.1/dist/jquery.js

I'm sorry, but it's true. Their code evolved, but your library's code snapshotted an older, less performant version.

EDIT: here's the each loop snippet:

z$.each = function(items, iterationCallback) {
    const len = (items == null ? 0 : Object.keys(items).length);
    if (len > 0) {
        let count = 0;
        for (let i in items) {
            if (items.hasOwnProperty(i)) {
                let item = items[i];
                if (item instanceof Element) {
                    item = z$(item);
                }
                if (iterationCallback.call(item, i, items[i]) === false) {
                    break;
                }
                count++;
                if (count >= len) {
                    break;
                }
            }
        }
    }
    return this;
};
// jquery@3.3.1
    each: function( obj, callback ) {
        var length, i = 0;

        if ( isArrayLike( obj ) ) {
            length = obj.length;
            for ( ; i < length; i++ ) {
                if ( callback.call( obj[ i ], i, obj[ i ] ) === false ) {
                    break;
                }
            }
        } else {
            for ( i in obj ) {
                if ( callback.call( obj[ i ], i, obj[ i ] ) === false ) {
                    break;
                }
            }
        }

        return obj;
    },

Maybe you did not copy and paste jQuery source as is, but you definitely did copy its API and design decisions

I'm sorry, but it's true. Their code evolved, but your library's code snapshotted an older, less performant version.

Back to attack? =) I did not copy at all.
Using method chaining and fluent API is a design pattern and choice, and anyway that's not a jQuery only prerogative.

Picking up similar methods name to jQuery is because I liked it and because it could also be familiar to many others, also names are similar all over many different APIs.

But I did avoid to implement methods that are already present in modern JavaScript/DOM API.
It's all explained in zUIx.js website. No secret.

Anyway thank you for pointing to this each issue, if you want you can make a pull request =) I will be glad to merge it.

Also if you want to talk about performance you are still invited to a code challenge. I will be glad to learn whenever there's something good to learn. And you? =))

But I did avoid to implement methods that are already present in modern JavaScript/DOM API.

Like Array.prototype.forEach over an Array of DOM elements for example?

Anyway, I wish you the best of luck with your framework, hopefully you'll get appreciated by the DEV.TO and Glitch communities. Try A-Frame, it's similar in nature with respect to quickly snapping together low-fi prototypes, it may be the next big thing and our modern approaches to functional and declarative data flow and UI state management will be obsoleted by agent-like components that interact with each other.

I have to sign off to get back to software engineering.

Oh, I understand =) and I guess they do pay you for things like this too ;) perhaps you're better at this arguing than coding and engineering =P

code of conduct - report abuse