How to avoid rewriting your JavaScript application
tech.polyconseil.fr
tech.polyconseil.fr
>Frameworks, libraries, package managers, guidelines… even languages and meta-languages themselves are changing so fast that there's little to no chance a common or standard way of building applications emerges.
...and then gives an example using React, JSX, and ES6 modules. This is just my opinion but I think React + JSX will look about as antiquated and irrelevant as jQuery in less time than it took jQuery to lose favor among web developers, rendering the argument for longetivity moot.
At least jQuery solved the practical problem of non-standard JS/DOM implementations, but now browser vendors have finally made basic things work among each other, making it irrelevant in most modern browsers. React solves what? Encapsulation? There's Web Components v1 right around the corner, and dozens of competing frameworks that may take its place as the most hyped framework.
It changes the fundamental question of UI development from "How do I get from where I am to where I want to be?", but "Where do I want to be?"
The funny thing about the particular example in the article is that React was heavily inspired by event loops used in Game Development.
I know React has some things going for it, but data binding on the web is an old trick.
React is more functional in nature -- A react component is, almost entirely, a function that takes arguments and spits out DOM elements. React then diffs the desired DOM with the current DOM, and computes the set of transformations needed to update the UI to match the new state -- i.e. "Add a few rows to the table, change the text in a particular span equal to 'boom'" or whatnot.
Disclosure: I'm the author.
[1] https://github.com/sapeien/simulacra/blob/master/lib/bind_ke... [2] https://news.ycombinator.com/item?id=12757722
Personally, I lean toward server side web apps ATM--users are familiar with page reloads, and developers are familiar with building them.
This is changing--users want faster UX, designers want fancier UI, PMs want cross platform apps. These external wants have developers creating & familiarizing with simpler ways to achieve them.
Even flux is basically organized pub/sub. Instead of shouting out what you're doing, you're logging your actions in a logbook. Also, instead of arbitrary actions, you can only combine certain pre-approved actions. It's a natural extension from using globals (too messy) to shouting out your intent while basically using globals (too noisy, still kinda messy) to what I've described above. (still kinda messy, but can be traced and unit tested easily)
Flux/Redux and whatever still doesn't help you solve problems that truly reduce complexity like how to organize scope or what abstractions to use.
There are tons of good frameworks out there, and it's rather disappointing to me that people don't realize that the basics are the same and insist on everyone jumping on the same bandwagon (that just happens to be supported by a rich large company).
Knockout, and Angular, both do data binding, but their implementations fall short on complex application state changes & how it translates to DOM changes--leading to incidental complexity: digest loop, TTL, $watch, observable, custom handlers.
React stupidly doesn't try to understand how the state changes translates DOM changes, and instead rerenders, diffs, and applies the update. React's declarative model is also why it can render on the server side, iOS, or Android.
Still, React doesn't translate list sorting to DOM changes efficiently, so imperatively optimizing is still sometimes needed, but less often than in Angular & thankfully not complected by the DOM. React will be replaced when someone solves this. Most likely needing a new programming language, to analyze the application logic & automatically translate into efficient UI updates.
For React, it's "Calculating what are the DOM changes that need to happen to ensure the UI reflects the state of the world". In practice, this means that I no longer need to be concerned with "What's the current state of the UI", and I'm not manually diffing things. To a large extent, it makes client-side UI code look a lot more like server-side UI code.
State is one of those things that's a PITA to reason about -- the less of it that I need to care about, the easier it is for me to make code that works. Reasoning and testing in one dimension (space) is a whole lot easier than reasoning in two (space and time).
Nowadays everyone embeds mega of worth libraries to build a damn blog. But using jquery to do some basic Dom changes, Ajax and other simple stuff (which you would write you own helper functions for anyway) is bloat.
Long live jquery.
> document.getElementById('myid');
to
> $('#myid');
I feel the same way about underscore. Regardless of the helper functions, readability goes up.
function $(sel) {
switch (sel[0]) {
case '#': return document.getElementById(sel.slice(1));
case '.': return document.getElementsByClassName(sel.slice(1));
default: return document.getElementsByTagName(sel.slice(0));
}
}
But I can understand that it's less about the user experience and more about the developer experience nowadays.
(but it would be only pseudo jQuery, the way you can have pseudo React just by using functions and ES6 template strings https://jsfiddle.net/vug86rn0/ )
var $ = document.querySelectorAll.bind(document);
$('#myid');The problem with the redux react ecosystem is that it wants to be functional and so it imports a lot of innovations done in functional languages, but in the end js it's not functional and you end up fighting the language. For example the reselect library [2] tries to implement selectors, but without native inmmutable data structures its too painfull to use.
I see a lot of people trying to implement so much features that should have been part of the language as libraries and i ask myself why not just use another language that has all those features, i mean they are all compiling to javascript anyways. Its madness.
[1] https://medium.com/@jeffbski/where-do-i-put-my-business-logi... [2] https://github.com/reactjs/reselect
Redux really is a beautifully elegant way to decouple global state and actions from the UI.
But yeah, as I've said in a few recent comments, Dan and Andrew made some excellent decisions while designing Redux, and those decisions have helped Redux hit a sweet spot for concepts and use cases.
The central store and the run loop is very powerful. If you have two completely unrelated components issue two fetches for the same model type but different IDs (ie two different blog comments) Ember coalesces them into a single request (I.e /api/comments?id[]=1&id[]=2) transparently. That's awesome.
render: function() { return ( <div className="title">{this.state.title}/> <div className="button" onClick={this.handleClick}> ) }
His implementation is a bit iffy though. How will his app look when there are dozens of components? A single main.js module with dozens of data fetching functions is going to be really hard to work with.
My only concern would be that I hadn't heard of it before, so I wonder if it has significant traction and production readiness.
Anyone have thoughts on that?
[0]: https://gist.github.com/eiriklv/a498112b3a73fc2b92975649924c...
[1]: https://gist.github.com/eiriklv/b6cc681447a0939365e1ba044fac...
http://intercoolerjs.org/2016/05/19/back-to-the-future.html
That is probably the biggest issue: no one cares about long-term support or maintainability of UI applications nearly enough to actually create the ecosystem that it deserves.
Absolutely. Not a lot of long term, slow thinking going on these days.
But I appreciate that people who have seen it before are sick of seeing it again.
So are the models referenced in the image you link to.
Every program has a code structure. Certain programs have better code structure than others. These are properties independent from the programming language. Javascript evolved from a single entry point, being the [in]famous $.ready() to set behaviors of some html elements, to full blows ES6 single page applications.
It all started as a toy language.
But it simplicity is also its flaw: it enables every human with a not so deep understanding of computer architecture to write a button that changes color on click. The absence of a type system and a solid class paradigm (introduced in ES6) spoiled programmers to pass any object down to any function breaking well known software paradigms: Law of Demeter (https://en.wikipedia.org/wiki/Law_of_Demeter), Open/Close Principle (https://en.wikipedia.org/wiki/Open/closed_principle) and the Liskov Substitution Principle (https://en.wikipedia.org/wiki/Liskov_substitution_principle).
I'm in the Web space professionally from 15+ years and those are the 3 rules i see JS devs break the most, generating complected code (for more understanding of the term have a look at https://www.infoq.com/presentations/Simple-Made-Easy ), hard to maintain and extend like the example shown in this article.
The advice to build interfaces around data structures, proposed as solution, is no different than the Liskov Substitution Principle.
The other problem the article cites is the event loop.
At the time o $.ready() there was no event loop. Developers were just attaching functions to user events: clicks, hovers, blurs, focus. Just a direct mapping between an element and a function. You can simply come to the conclusion that the trigger and the action to be performed were not loosely coupled, but indeed tight together. Easy, yet not scalable.
Tieing events to the dom structure was another sin opening more questions: should an element that is not interactable fire events? bubble them ? every browser had its own answer to those questions. Things got even more complicated with single page applications which html element in the page can be added and removed. So here comes the event loop, like other well known ui stacks did in the past.
The concept of an event loop is not a novelty, it is indeed bound to the architecture of our computer: clock cycle, interrupts, kernel events. In the case of windows is the well known WPF (https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio...) which has, among a lot of other things like any Microsoft product, the concept of a dispatcher that is central to the flux architecture.
In 2015/2016 with React/Flux Javascript and the Web is moving out of puberty, enabling developers to write clean, decoupled, extensible code. Thus no all devs are ready to grasp those architecture that are so obvious in other ecosystems. To cite Poul-Henning Kamp in A generation lost in the bazaar (http://queue.acm.org/detail.cfm?id=2349257):
"So far they have all failed spectacularly, because the generation of lost dot-com wunderkinder in the bazaar has never seen a cathedral and therefore cannot even imagine why you would want one in the first place, much less what it should look like. It is a sad irony, indeed, that those who most need to read it may find The Design of Design entirely incomprehensible."
my 2 cents
Note how it doesn't say "Elm application" or "ClojureScript application".