

Boiling React Down to Few Lines in JQuery - Suor
http://hackflow.com/blog/2015/03/08/boiling-react-down-to-few-lines-in-jquery/

======
joshstrange
I use something a little similar where I work. No one would be on board with
something like React but I've documented a way to write our code that does
something similar to this post. We use js "classes" (Both Function.prototype
and now js classes with babel) and lo-dash templates to make it a little
nicer.

Example:

    
    
        function MyComponent(element) {
            var instance = this;
            instance.element = element;
            instance.history = [];
            instance.state = { myKey: 'someData' };
            instance.template = _.template($('my-template').html());
            instance.setupHandlers();
        } 
    
        MyComponent.prototype.render = function() {
            var instance = this;
            instance.element.html(instance.template(instance.state));
            instance.history.push(deepcopy(instance.state));
        }
    
        MyComponent.prototype.undo = function() {
            var instance = this;
            instance.state = instance.history.pop();
            instance.render();
        }
    
        MyComponent.prototype.setupHandlers = function() {
            instance.element.on('change', '.my-input', function(e) {
                instance.state.myInput = $(this).val();
                instance.render();
            });
        }
    
        
    

This is of course a very simplified version but it should give you an idea of
what I'm talking about.

~~~
aikah
You're example is the perfect example of what not to do and why React, Angular
and such exist: STATES. You want your view to be data driven.It means that
your component should be STATELESS.

There are other issues such as event delegation,cleaning up event
listeners,... that will make your solution hard to scale past simple
widgets.And before you know it,you'll be writing your own complicated
framework that does less than Angular or React.

~~~
skybrian
A web app always has a state machine somewhere, even in functional languages.
The question is whether the app's state is internal (mutable state) or
external (write a state transition function and let the environment pass the
state back to you on the next iteration).

I think the jury is still out on whether storing all application state in a
single state object (as in Elm) scales well beyond toy examples. All the state
is exposed which doesn't seem so good from a data-hiding point of view.

~~~
baddox
> I think the jury is still out on whether storing all application state in a
> single state object (as in Elm) scales well beyond toy examples.

I'm not familiar with Elm, but what do you mean by this? Even if all the
application state isn't literally in a JS object like {users: [...], messages:
[...], ...}, it's going to be in multiple variables like UserStore and
MessageStore. There's really not a big difference other than the syntax of
accessing them. But perhaps you're hinting at a drastically different approach
to application state.

~~~
skybrian
Elm [1] is not JavaScript. It's a pure functional language that compiles to
JavaScript. There are no mutable variables in Elm as you'd normally think of
them, but there are streams (called signals) and state machines.

The issue is that you can't really write UI components as you'd normally think
of them; everything needs to be divided up into a separate models and view
functions. The state of every single widget in the page (recursively) needs to
be represented somewhere in the application model.

[1] [http://elm-lang.org/](http://elm-lang.org/)

------
danesparza
React is more than a few lines of clever Javascript.

It's also a philosophy of UI composition. It's also a philosophy of data
consumption. It's also a philosophy of code structure.

Having written my share of code with both, I now prefer composing UI's in
React. It's easier to get simpler code maintenance and better performance with
React.

~~~
timhon
i thought it was a good simplistic illustration of react's concepts using a
tool everyone already knows

~~~
joemaller1
React also has two years of battle-testing at Facebook and Instagram. I'm not
a fan of Facebook the product, but they've got some great engineers and I
trust their code.

------
i_s
> I want to stress this once more – for an average app you can skip React or
> other virtual DOM at start and only go for it once it gets too slow (or
> never).

I don't think this is good advice. It would be better to just start by using
something like React, then if things get too slow, implement
shouldComponentUpdate, because you will almost certainly need something that
can make efficient DOM updates instead of just naively recreating whole DOM
trees.

~~~
Suor
Using framework has its cost, so you can be better of if you understand
clearly what you are doing. OTOH, framework brings structure so it's less
probable you skrew up your design.

~~~
acjohnson55
I think your piece does a great job of highlighting the design principles
behind React and friends, but in reality, I see nothing wrong with having your
cake and eating it too: understand the principles but still use a battle-
tested framework with a strong community around it. I don't see why _everyone_
should reinvent the same abstractions. Your last sentence really nails it.

Great piece though. It's good for programmers to understand how powerful the
concept can be of factoring state out of actions of your app.

------
insin
If you were to put the event bindings in the markup instead, some of the
examples would look very similar to Riot 2.0 [1] tag definitions, although it
uses a more Glimmer-like approach which only looks at the bits which can
change based on the template, instead of a Virtual DOM.

[1] [https://muut.com/riotjs/](https://muut.com/riotjs/)

------
curiously
I've never had to use a front end framework.

I still use jQuery.

~~~
cozuya
What's the biggest "program" you've written using solely jQuery? I recently
completed something in the range of 3k lines using only jQuery and
prototypical inheritance and realized later it probably could have very easily
benefitted from picking up Backbone, at the very least to hold state better
than sticking it in an object on the base class in various ways.

~~~
super-serial
Even backbone isn't worth the added complexity IMO.

All these frameworks make you write more code than needed... and because
people started to feel it wasn't worth it, their latest pitch focuses on
speed. They say the "virtual DOM" is the future, and if you're not diffing
your state to re-render the DOM you're not a serious developer.

I still don't see the benefit. I've written 15k lines of javascript code in
some apps. My components have state and I re-render as needed, and as long as
you separate code between components it's fine.

How many times have you been using a js app and thought "wow this DOM is
slow?" You don't. It's either 0.1 sec or 0.2 sec to re-render the whole
component/widget. 99.9% of the time a website is slow because the server
requests take too long. Every once in a while you'll see some crazy CSS3
animations that make things unresponsive.

The people who go on about having a virtual DOM run benchmarks on thousands of
elements... I don't know about you, but I'm never rendering thousands of
elements at a time. Ajax/pagination works fine for extra data. I did write a
very simple template system and event management system... but I'd rather do
that than add the complexity of a framework. Dealing with a framework to make
things work in "the X way" is wasting everyone's time. And then the next
Angular or whatever comes along... and everyone wastes more time learning the
latest version. This has turned into a rant... but I just want to say I'm
happy as a coder who avoids frameworks at all costs. At the same time I try to
use as many libraries as possible. Libraries save time, frameworks waste time.

~~~
baddox
Everything you say about DOM performance is decidedly not true on mobile.

