Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Boiling React Down to Few Lines in JQuery

hackflow.com

Post reply on HN
Print view View original

11–20 of 35 posts

Re: Boiling React Down to Few Lines in JQuery

#11

Post by skybrian »

aikah wrote: post #10
joshstrange wrote: post #5

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 = []…

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…

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.

Re: Boiling React Down to Few Lines in JQuery

#12

Post by Suor »

danesparza wrote: post #2

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.

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.

Re: Boiling React Down to Few Lines in JQuery

#13

Post by Suor »

i_s wrote: post #3

> 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 n…

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.

Re: Boiling React Down to Few Lines in JQuery

#14

Post by donw »

skybrian wrote: post #11
aikah wrote: post #10

Earlier quoted context omitted.

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…

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 sta…

It seems to work reasonably well for the two non-toy apps I've worked on that use a single state object. There are two key rules required to make this work, however:

1. For each domain, state can be modified in one place (in React, a store).

2. For each domain, state can be read in once place (a Presenter).

This preserves data-hiding for the most part, and keeps you from having to play hunt-the-wumpus when you need to change the data structure.

Re: Boiling React Down to Few Lines in JQuery

#16

Post by mambodog »

joshstrange wrote: post #5

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 = []…

It's sad that your colleagues' lack of open-mindedness about adopting a framework is forcing you to create a less-well-specified, less-documented, implicit framework.

Re: Boiling React Down to Few Lines in JQuery

#17

Post by cozuya »

mambodog wrote: post #16
joshstrange wrote: post #5

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 = []…

It's sad that your colleagues' lack of open-mindedness about adopting a framework is forcing you to create a less-well-specified, less-documented, implicit framework.

I think its more surprising that his/her collegues are down with ES6 through babel but are yet scared of something like React..

Re: Boiling React Down to Few Lines in JQuery

#18

Post by cozuya »

curiously wrote: post #15

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

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.

Re: Boiling React Down to Few Lines in JQuery

#19

Post by joemaller1 »

timhon wrote: post #9
danesparza wrote: post #2

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.

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

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.

Re: Boiling React Down to Few Lines in JQuery

#20

Post by acjohnson55 »

Suor wrote: post #13
i_s wrote: post #3

> 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 n…

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.

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.

Post reply on HN