re: Ready to use Progressive Web App template VIEW POST

TOP OF THREAD FULL DISCUSSION
re: I'm observing, not asserting. Using DOM markup attributes and imperatively attaching JavaScript behavior to them via attribute selectors is an old ...

I've just scanned this code github.com/genielabs/zuix-html-pwa... front to back, and I've only confirmed my initial observations: the code is great and beautiful, but its architecture and design decisions are obsolete. It's an in-house framework which blends jQuery, Angular, and a few built-in components, Logger, Async primitives, an XHR wrapper. It even explicitly borrows pieces of jQuery code. I wrote similar in-house framework at about the same time (2012-2014), but I instead included jQuery as a dependency; at about 2015-2016 I've upgraded all the code to the modern dependency management and bundling tools (npm, CommonJS, Webpack), and later introduced React; now the UI is mostly React, app structure and older components still use that in-house framework.

more declarative UIs to address some of the cons like the lack of composability

Respecting current standards is a choice, not an obsolete practice. There's no lack of composability here.

It even explicitly borrows pieces of jQuery code.

Are you kidding me? =) Where did you saw that? Still attacking without knowing what are you talking about?

Can you provide a practical example? This is what I was asking before. I mean, show a small piece of code.

at about 2015-2016 I've upgraded all the code to the modern dependency management and bundling tools (npm, CommonJS, Webpack), and later introduced React;

Why would one add complexity over complexity when you can reach the same goal without those tools? Most of times these tools are misused and abused.

Have you read my post about in-browser bundling? Have you tried a simple "View Source" on

HTML-PWA

there you will see an app.bundle.js:

app.bundle.js

and guess what? It didn't came out of any build tool.

So are you sure that what you stated is always (if at all) true?

As I never would dare a comparison between a 13kB library with a 100kB framework, still again, I beg you, provide some piece of code to show evidence that, for instance, a small component written with React is way better of any other framework (because is this what you are trying to do since the beginning of this thread, it seems).

This is now a very long thread that could have been solved with just few lines of code.

I must say I liked the name ThePracticalDev and I like DEV.TO. So since we are here, let's be practical.

Show how beautiful is writing code with React (since you mentioned it). I'll show how you can do the same in most of cases with this small "old-fashioned" library which might surprise you in term of performance and elegance.

So this will probably start to be a decent and constructive conversation. Otherwise still looks like trolling.

We're practical developers not marketing puppeteers.

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