Hacker News Reader

Comment by daliwali | Hacker News Reader

The article opens with:

>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.

View on HN

The fundamental problem solved by React is being able to express a UI as a function from Application State to DOM, and not having to worry about manually computing the changes to the DOM that need to occur to reflect the new state of the world.

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.

So.. data binding? Like backbone did, and knockout?

I know React has some things going for it, but data binding on the web is an old trick.

Not really "binding" per se -- mostly because "binding" implies you're attaching events to objects and thinking about "changes", and object lifecycle is still something you're concerned with.

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.

That's just an implementation detail. All these declarative UI ideas are variations of sprintf. Something, somewhere, is going to do a diff no matter what, whether it's a virtual DOM or the browser itself.

Try making a web app rerenders the DOM on any state change, it will be extremely slow--the browser doesn't diff. :) That's why vDOM & diffing is necessary. Also so UI inputs don't lose focus / selection state / etc.

State change, eh? There's this, which diffs only local updates and doesn't use a vDOM: http://simulacra.js.org/

Disclosure: I'm the author.

Tracking changes to application state & translating to DOM changes is nothing new, [1] it's what Angular, Angular2, Riot, Knockout all do, and doomed to efficiently translating any complex state changes. [2] Not only that, feeding application state in from an API will cause the all the dependent UI to completely rerender.

[1] https://github.com/sapeien/simulacra/blob/master/lib/bind_ke... [2] https://news.ycombinator.com/item?id=12757722

You don't need vDOM/diffing for many types of applications. Your CRUD app doesn't need to update at 60 FPS.

Diffing is an implementation detail. Imperatively updating might still be needed to hit that 60 FPS ;D

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.

IMO React is popular because it forces people to understand MVC. I've actually never seen a Backbone app where views render based on the model. It's too easy to just ram in jQuery in the render function. A lot of new frameworks just try to reduce Backbone's boilerplate of manual model-view event binding in different ways, dirty watching, virtual DOM, etc...

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).

Data binding exactly, like binding a declarative formula in Excel. Not like Backbone, which did event binding, invoking the programmer's code to imperatively update the DOM.

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.

Good description of event loops in games:

http://gameprogrammingpatterns.com/game-loop.html

I think you just described one way of updating things on a web page. The paradigm which React uses is popular in this moment, but there are many other ways to update things on a web page. It does not actually do anything that couldn't be done before, or with other frameworks or libraries.

Using jQuery you can express a UI as a function from Application State to DOM? I'd be really interested in an example. I've only ever used jQuery to do lots of imperative-looking DOM state changes.

The end user doesn't know or care about implementation details. It's bikeshedding that nobody cares about except the developers themselves. Facebook could have built their web app with Angular or Ember or whatever and nobody would give a shit except developers. Even as a developer I don't give a shit about what framework a web app I'm using is made with as long as it works (if it's horribly broken then I know what to avoid).

Isn't that like saying I'm not an architect so I don't really care what kind of foundation my house is built on as long as it hasn't fallen down yet? They're all held up by the same laws of physics anyway.

It is not common, easy, efficient or idiomatic, but you can: Imagine that in each event handler, instead of doing something, you just update some state somewhere, and after that call a common "draw" function. Inside the "draw" function you redraw all your UI: apply effects, etc. That's it, you have it.

Along these lines, this is why Dan Abramov's Getting Started with Redux[1] is one of my favorite tutorials to anything, ever. The concepts are simple, and half the tutorial is walking through creating a naive implementation of Redux. The actual library, of course, involves performance optimizations and better edge case handling, but at the very least, having a "this is sort of what the innards look like" is a really nice start to approaching anything.

[1] https://egghead.io/courses/getting-started-with-redux

For me, tools that I find useful are ones that make something no longer be my problem as an application dev. For JQuery, it was low-level browser implementation details. Sure, browsers were different, I just didn't need to care anymore.

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).

Jquery still solves a lot of the problems and saying bloat about is nonsense.

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.

Not to mention the syntax is nicer. Compare the wordy:

> document.getElementById('myid');

> $('#myid');

I feel the same way about underscore. Regardless of the helper functions, readability goes up.

So, jQuery instead of just...

  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));
    }
  }

I mean... "readability".

And in the end, you add 10 of those selectors. Then you create a small library so they are all at the same place and handy. Then few fixes to support that one browser in that case. And in the end you have jquery.

With that you would end up with something more like Sizzle[0], not necessarily jQuery.

[0] https://sizzlejs.com/

I think you're forgetting additional HTTP functionality, rudimentary animations, additional wrappers around existing JavaScript representation of DOM nodes, and a variety of other things that you'll never realistically used but thrown into all your applications for posterity. Because in the end, you had jQuery.

With http2 the additional request is not a problem. If you don't use jquery, you don't care about old browsers/OS not supporting them either. Also, cdn+caching of the library.

Bytes are bytes are bytes, http/2 or no. It's far less intensive to polyfill what features I actually am using than sending down all of jQuery, and that can still be minified, gzipped, cached, delivered via CDN, and cache-controlled and/or placed in the application cache via service workers (where available).

But I can understand that it's less about the user experience and more about the developer experience nowadays.

in HTML5 would be sufficient: const $ = document.querySelectorAll.bind(document);

(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');

jQuery is mostly superfluous these days, anyway. Javascript supports most of its functionality natively in the browser. Maybe it's time to ditch the overly large generic libraries and start writing in plain old javascript again.

Reply on news.ycombinator.com