9 ms·

Boiling React Down to Few Lines in JQuery

156 points by Suor 12y ago

danesparza 12y ago
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.
- deleted 12y ago
  [deleted]
- timhon 12y ago
  i thought it was a good simplistic illustration of react's concepts using a tool everyone already knows
  - joemaller1 12y ago
    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.
- Suor 12y ago
  There are sure some things I haven't covered. The major one is components, which make a big deal in factor, reuse and composition. But the post started to be too long and loosing point so I skipped it. There are also ideas beyond React I left aside. I will probably write some follow up post later.
i_s 12y ago
> 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 12y ago
  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 12y ago
    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.
- baddox 12y ago
  shouldComponentUpdate is nontrivial to implement when you're using mutable application state. I feel like all React tutorials should at least mention this, but sadly most seem to say something like "do not worry about performance until it becomes a problem, then just implement shouldComponentUpdate."
  - i_s 12y ago
    If you have a slow react component that uses mutable data structures for state, and implementing shouldComponentUpdate is hairy, you could always switch to using immutable data structures for that component's state instead. That change alone is very easy. From there, implementing shouldComponentUpdate is very straightforward.
joshstrange 12y ago
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.
- mrspeaker 12y ago
  I like how you redundantly alias `this` to `instance` except in the only method that needs it ;)
  - joshstrange 12y ago
    Haha yeah that was stupid. With the fat arrow "=>" I'm hoping to be able to get rid of it in most instances. I know I could mix this/instance but I'd rather use "instance" everywhere for consistency even if "this" works. I'd love to hear other's thoughts on the matter!
- aikah 12y ago
  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.
insin 12y ago
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/
deleted 12y ago
[deleted]
curiously 12y ago
I've never had to use a front end framework. I still use jQuery.
- cozuya 12y ago
  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 12y ago
    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.
    - 12y ago

156 points by Suor 12y ago

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.

deleted 12y ago
[deleted]
timhon 12y ago
i thought it was a good simplistic illustration of react's concepts using a tool everyone already knows
- joemaller1 12y ago
  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.
Suor 12y ago
There are sure some things I haven't covered. The major one is components, which make a big deal in factor, reuse and composition. But the post started to be too long and loosing point so I skipped it. There are also ideas beyond React I left aside. I will probably write some follow up post later.

i_s 12y ago

> 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 12y ago
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 12y ago
  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.
baddox 12y ago
shouldComponentUpdate is nontrivial to implement when you're using mutable application state. I feel like all React tutorials should at least mention this, but sadly most seem to say something like "do not worry about performance until it becomes a problem, then just implement shouldComponentUpdate."
- i_s 12y ago
  If you have a slow react component that uses mutable data structures for state, and implementing shouldComponentUpdate is hairy, you could always switch to using immutable data structures for that component's state instead. That change alone is very easy. From there, implementing shouldComponentUpdate is very straightforward.

joshstrange 12y ago

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.

mrspeaker 12y ago
I like how you redundantly alias `this` to `instance` except in the only method that needs it ;)
- joshstrange 12y ago
  Haha yeah that was stupid. With the fat arrow "=>" I'm hoping to be able to get rid of it in most instances. I know I could mix this/instance but I'd rather use "instance" everywhere for consistency even if "this" works. I'd love to hear other's thoughts on the matter!
aikah 12y ago
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.

insin 12y ago

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/

deleted 12y ago

[deleted]

curiously 12y ago

I've never had to use a front end framework. I still use jQuery.

cozuya 12y ago
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 12y ago
  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.
  - 12y ago