You probably don't need a JavaScript framework • Hacker News Board

Re: You probably don't need a JavaScript framework

#21

Post by thatswrong0 » Sat, Apr 30, 2016, 1:02 AM UTC

timr wrote: post #14

thatswrong0 wrote: post #10

Earlier quoted context omitted.

That doesn't address the fact that, to some of us, React simplifies creating, testing, and maintaining complex UI due to its functional nature. React is simple to me, and that's why I like using it.

"React is simple to me, and that's why I like using it." Horses for courses. The author is merely making the argument that you don't need react, and the GP comment didn't bother to read the argument before responding.

If you're going to tell me I don't need to use a library, it has to be way more convincing than, "Look how easy data binding it with native APIs! And it's not slow!" This is a weak argument in my opinion, and does nothing to address how removing abstractions will make my life easier.

Re: You probably don't need a JavaScript framework

#22

Post by city41 » Sat, Apr 30, 2016, 1:02 AM UTC

timr wrote: post #7

statictype wrote: post #6

React doesn't exist to handle the massive amounts of data that facebook has. React exists to make complex UIs easier to build and maintain. Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code. That the author kind of misses this point makes me pay less attention to the rest of the post.

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. Th…

I didn't downvote you. But I don't want data binding. I want to input parameters and get UI as output. I want to minimize state as much as possible. I want to write unit tests where I mock as minimally as possible. These are the reasons I use React.

Re: You probably don't need a JavaScript framework

#23

Post by CameronBanga » Sat, Apr 30, 2016, 1:02 AM UTC

Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.

Re: You probably don't need a JavaScript framework

#24

Post by dang » Sat, Apr 30, 2016, 1:03 AM UTC

timr wrote: post #7

statictype wrote: post #6

React doesn't exist to handle the massive amounts of data that facebook has. React exists to make complex UIs easier to build and maintain. Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code. That the author kind of misses this point makes me pay less attention to the rest of the post.

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. Th…

I think I agree with you, but your comment breaks the HN guidelines twice: the first paragraph is uncivil and the final one goes on about getting downvoted. It also pretty much breaks the injunction against "did you even read the article" comments, so that's three. Please don't do these things when commenting here, regardless of how irritatingly wrong someone else may be.

The middle paragraph is helpful and fine, and the comment would have been much better with just that.

https://news.ycombinator.com/newsguidelines.html

Re: You probably don't need a JavaScript framework

#25

Post by philfreo » Sat, Apr 30, 2016, 1:04 AM UTC

CameronBanga wrote: post #23

Are Slack Files an official blog from Slack? For a second, I thought looking at the URL that this was just a URL for a Slack snippet or something similar.

No, if you look in the footer you'll see it says "Public file shared from Slack", which I think just means someone posted this document using Slack

Re: You probably don't need a JavaScript framework

#26

Post by apeace » Sat, Apr 30, 2016, 1:04 AM UTC

contenteditable and MutationObserver? What about and onchange?

Re: You probably don't need a JavaScript framework

#27

Post by tomc1985 » Sat, Apr 30, 2016, 1:05 AM UTC

This! This times a million times!!~!

Seriously. The javascript world is INSANE. All these frameworks and few truly need them... node.js package management is a mess... yet how many of these coders will take the time to learn real ES5? It really isn't that hard of a language.

I feel like calling oneself a "javascript" expert practically requires knowledge of a framework or too. This is saddening, because Javascript itself is a rich language with a ridiculously fast runtime, yet everyone wants to work with a framework when a head full of sound theory and experience will do :/

Re: You probably don't need a JavaScript framework

#28

Post by tomc1985 » Sat, Apr 30, 2016, 1:06 AM UTC

Touche wrote: post #18

takno wrote: post #9

Earlier quoted context omitted.

Sure, you may well end up writing one, but it's likely to be a fraction of the size. My current entire app is running at half the size of jquery, which is getting me awesomely quick page loads even on poor mobile connections. The dev time was longer, but not crazily longer, and the surface area for testing is somewhat smaller

In reality JavaScript size means very little when a single image might be 500k.

Did you not see that headline about how the average page now is the size of a Doom install?

Re: You probably don't need a JavaScript framework

#29

Post by sorpaas » Sat, Apr 30, 2016, 1:07 AM UTC

Greenspun's tenth rule: Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp.

Now let's add Javascript to the list.

Re: You probably don't need a JavaScript framework

#30

Post by Dr_tldr » Sat, Apr 30, 2016, 1:10 AM UTC

timr wrote: post #7

statictype wrote: post #6

React doesn't exist to handle the massive amounts of data that facebook has. React exists to make complex UIs easier to build and maintain. Being able to just write the code once to render a UI from some state and then just reloading the entire UI when the state changes is an incredible simplification of your code. That the author kind of misses this point makes me pay less attention to the rest of the post.

"That the author kind of misses this point makes me pay less attention to the rest of the post." Too bad. The author addressed everything you said. You just didn't read past the sentence you quoted. Nowhere does the piece imply that you should render every state change server-side. In fact, it goes on to show, with specific examples, of how you can get data-binding and partial-update behavior with web-native APIs. Th…

The argument that React will be heavier than your own implementation is clearly true.

The argument that it'll take less time to develop, document, and test your own implementation than to take advantage of the React ecosystem is clearly untrue.

As the public demands higher quality images and video, code weight matters less and less. If you're not serving up 3mb+ of high-res images and/or video and making multiple AJAX calls, your site is highly specialized and outside of the mainstream. It's not an insult or a judgement, it's an easily verifiable fact by looking at Alexa ratings.

If you need to save 50-100kb that badly, use a slightly smaller image file or a slightly shorter video, don't add hundreds to thousands of hours of dev time. And if you're developing for mobile, do as much server-side rendering as you can and add a debounce for potentially costly operations, it's really not that hard.