Boiling React Down to Few Lines in JQuery • Hacker News Board

Re: Boiling React Down to Few Lines in JQuery

#21

Post by super-serial » Mon, Mar 09, 2015, 4:09 AM UTC

cozuya wrote: post #18

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.

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.

Re: Boiling React Down to Few Lines in JQuery

#22

Post by baddox » Mon, Mar 09, 2015, 4:31 AM UTC

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…

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

Re: Boiling React Down to Few Lines in JQuery

#23

Post by baddox » Mon, Mar 09, 2015, 4:37 AM UTC

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…

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

Re: Boiling React Down to Few Lines in JQuery

#24

Post by baddox » Mon, Mar 09, 2015, 4:38 AM UTC

super-serial wrote: post #21

cozuya wrote: post #18

Earlier quoted context omitted.

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.

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

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

Re: Boiling React Down to Few Lines in JQuery

#25

Post by skybrian » Mon, Mar 09, 2015, 4:56 AM UTC

baddox wrote: post #22

skybrian wrote: post #11

Earlier quoted context omitted.

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…

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

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/

Re: Boiling React Down to Few Lines in JQuery

#26

Post by i_s » Mon, Mar 09, 2015, 5:14 AM UTC

baddox wrote: post #23

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…

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

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.

Re: Boiling React Down to Few Lines in JQuery

#27

Post by i_s » Mon, Mar 09, 2015, 5:18 AM UTC

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…

Om also stores all app state in a single object, but lets you give components a window into that state ('cursors') in order to maintain modularity. If there turns out to be a problem with this general approach, it won't be a data-hiding one.

Re: Boiling React Down to Few Lines in JQuery

#28

Post by curiously » Mon, Mar 09, 2015, 7:08 AM UTC

cozuya wrote: post #18

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.

about 5k. Funny I thought about the same thing but in the end I considered the amount of work that would be required vs.something that is already working well, easy to understand, skillset being very low if someone needs to pick it up (just jQuery, not even weird object orientated bull crap).

Yup, just one single .js file written in jQuery. I am however, curious about React.js, and want to experiment with new components, I doubt I would use Backbone.js however.

It took far longer, and more bugs using Backbone.js than using jQuery. I don't know why people are so obsessed with Backbone.js, modularizing, object orientation with Javascript, the language was not optimized for such purposes, it's only with the server side javascript boom with node.js that we are seeing this heavy shift towards Javascript, but I treat Javascript like the second class citizen it really is, and I think it's rather naive to suddenly start using it for everything just because you can and everyone is doing it.

Re: Boiling React Down to Few Lines in JQuery

#29

Post by curiously » Mon, Mar 09, 2015, 7:21 AM UTC

super-serial wrote: post #21

cozuya wrote: post #18

Earlier quoted context omitted.

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.

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

I often feel like Javascript frameworks is dominated by 'experts' claiming how the proper way to write Javascript apps is now to share their opinions.

I've yet to run into any problem that were supposed to happen using jQuery and vanilla Javascript.

Even outside of Javascript, I stay away from using full blown frameworks. Even libraries that you think will be perfect for your use case turns out to be a drainage of resource learning, and now being bent to the will of the author's opinions. For example, Celery is a complete piece of shit. The amount of bug, and workarounds that one must experience vs. writing something on your own using RabbitMQ or even just redis, it's clear to me. Same with giant PHP frameworks or RoR vs. Flask. Even microframeworks that focus on not being a framework comes with the some opportunity cost, however being better than the monolithic frameworks that whines and decides to leave you in the dark because you did not share the same opinions.

Re: Boiling React Down to Few Lines in JQuery

#30

Post by joshstrange » Mon, Mar 09, 2015, 11:58 AM UTC

mrspeaker wrote: post #7

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

I like how you redundantly alias `this` to `instance` except in the only method that needs it ;)

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!