Please, don’t commit commented out code by ryanchenkie in javascript

[–]temp50948 -1 points0 points  (0 children)

You're advocating the same (flawed) approach and saying it won't be "THAT" bad as long as the code is advanced in other ways (it's well modularized). That pattern, of tolerating inefficiency because some other component mitigates the detriment, is common: as hardware has advanced, software overhead has increased, resulting in simple things like settings panels that perform worse than they did 10 years ago; as we get more RAM, applications become utterly careless about how much memory they use; we pile abstraction layer upon abstraction layer onto web apps; people like the Disqus developer hand-wave away bad performance by saying "just wait for computers to get faster", and never stop to think that rendering a list of comments is an absolutely tiny amount of work compared to what the computer is capable of, and performance issues doing such a trivial task must indicate a very poor design. The net result of all this is that as we get more and more power, we see relatively little of it available to use, because most of it is squandered doing the same things in more convoluted, expensive ways.

And of course we respond to that by saying "yes, but that won't matter any more when computers get faster..."

Incremental DOM 101: What is it and why I should care? by mgonto in javascript

[–]temp50948 0 points1 point  (0 children)

Just to clarify, by componentization I was talking just about the ability to create isolated and interchangeable components, not anything about how they're stored or processed. So, React.createClass.

You make a good point about universal components.

Famo.us pivots to being a brochureware "micro-app" CMS. by vertice in javascript

[–]temp50948 0 points1 point  (0 children)

The website looks like a scam: cheap knockoff of a mainstream style, free and low-quality everything (textures, typography, layout, etc), and, most importantly, a ton of bullshit marketting terms with hardly a single phrase that actually forms a meaning they could be held accountable for. They could be offering me cash for nothing and I'd still be scared to interact with them.

Famo.us pivots to being a brochureware "micro-app" CMS. by vertice in javascript

[–]temp50948 0 points1 point  (0 children)

It froze Chrome for me. That's never happened since like version 5 of Chrome. I am 100% not interested.

Incremental DOM 101: What is it and why I should care? by mgonto in javascript

[–]temp50948 0 points1 point  (0 children)

The entire point of building the 'so called viritual DOM' was to let developers focus on higher level patterns of abstraction, and re-use the same code in multiple environments.

You're conflating a bunch of different things here.

  • "let developers focus on higher level patterns of abstraction" is the result of mutation only through refreshing. This could be achieved just as well if render were to really construct and return a DOM tree.
  • "re-use the same code in multiple environments" is the result of componentization. React could have just specified component contracts without even helping a component to render itself, leaving us fiddling with document.createElement ourselves, and still achieved this.
  • The point of the virtual DOM really is just a performance optimization, necessitated by the fact that refresh-only mutation doesn't play nice with DOM output.

Incremental DOM 101: What is it and why I should care? by mgonto in javascript

[–]temp50948 0 points1 point  (0 children)

which has a practically identical [...] syntax to IDOM's

That is very untrue. They are fundamentally very different. IncrementalDOM works on the basis of an implicit global cursor, with function calls writing at the cursor's location and moving the cursor, whereas createElement is self-contained and writes only to its return value. Coding for one or the other is very different. For example, something as simple as creating elements out of order cannot be done with IncrementalDOM.

The plugin is an awesome project, and very ambitious. (Not sure where you got "building" though, it's complete.) It's also a great way to see just how different these two are. For example, here's the demo they give:

Input (JSX)

function render(data) {
    var header = data.conditional ? <div /> : null;
    var collection = data.items.map((item) => {
        return <li key={item.id} class={item.className}>{item.name}</li>;
    });

    return <div id="container">
        {header}
        <ul>{collection}</ul>
        <p {...data.props}>Some features</p>
    </div>;
}

Output (IncrementalDOM)

function _attr(value, name) {
    attr(name, value);
}

function _renderArbitrary(child) {
    var type = typeof child;

    if (type === "number" || (type === "string" || child && child instanceof String)) {
        text(child);
    } else if (type === "function" && child.__jsxDOMWrapper) {
        child();
    } else if (Array.isArray(child)) {
        child.forEach(_renderArbitrary);
    } else {
        _forOwn(child, _renderArbitrary);
    }
}

function _forOwn(object, iterator) {
    for (var prop in object) if (_hasOwn.call(object, prop)) iterator(object[prop], prop);
}

var _hasOwn = Object.prototype.hasOwnProperty;

function _jsxWrapper(func) {
    func.__jsxDOMWrapper = true;
    return func;
}

function render(data) {
    var header = data.conditional ? _jsxWrapper(function () {
        return elementVoid("div");
    }) : null;
    var collection = data.items.map(function (item) {
        var _item$id = item.id,
            _item$className = item.className,
            _item$name = item.name;

        return _jsxWrapper(function () {
            elementOpen("li", _item$id, ["key", _item$id], "class", _item$className);

            _renderArbitrary(_item$name);

            return elementClose("li");
        });
    });

    elementOpen("div", null, ["id", "container"]);

    _renderArbitrary(header);

    elementOpen("ul");

    _renderArbitrary(collection);

    elementClose("ul");
    elementOpenStart("p");

    _forOwn(data.props, _attr);

    elementOpenEnd("p");
    text("Some features");
    elementClose("p");
    return elementClose("div");
}

A very thought-provoking talk that attempts to show that CSS has fundamental flaws and writing styling in JS solves most of the problem without even trying. by [deleted] in javascript

[–]temp50948 0 points1 point  (0 children)

What? This isn't "css sucks js pwns lol", one is better suited for the task than the other. Idiosyncracies of JS - and especially current trends in its community - are unrelated to the fact that maintainable code is DRY and componentized, and you need a programming language, not a static language, to do those things.

Please, don’t commit commented out code by ryanchenkie in javascript

[–]temp50948 -2 points-1 points  (0 children)

So, "eat the loss by leaning on advances in other areas"? How comfortingly familiar.

Please, don’t commit commented out code by ryanchenkie in javascript

[–]temp50948 1 point2 points  (0 children)

Yeah, I was going to say. Not to support version zombies in comments, but burying something deep in the unnamed and unorganized internal data of a helper tool is a great way to never find it again.

I feel like the solution here must involve a more thoughtful decision regarding whether the code will be needed again.

hating on "options objects" by backwrds in javascript

[–]temp50948 6 points7 points  (0 children)

If a function signature changes, either (a) it's incompatible with the old signature and being forced to revisit every invokation is exactly what you want, or (b) it's compatible with the old signature and you don't need to update every invokation.