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

How Does React Tell a Class from a Function?

overreacted.io

Post reply on HN
Print view View original

101–110 of 142 posts

Re: How Does React Tell a Class from a Function?

#101

Post by cloverich »

danabramov wrote: post #72
quietbritishjim wrote: post #66

Earlier quoted context omitted.

I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…

>to me, separating out that function is a good thing To us, too, and that's exactly the point of Hooks. They let you extract logic into functions in a way that wasn't possible before. I suggest to read more than a single page -- in particular, extracting custom Hooks is largely the point of the proposal. https://reactjs.org/docs/hooks-custom.html I also wrote about this here: https://medium.com/@dan_abramov/making-se…

It reminds me quite a bit of mixins.

Re: How Does React Tell a Class from a Function?

#102

Post by maceurt »

kbumsik wrote: post #73

> I didn’t know this for years. Please don’t turn this into an interview question. In fact, this post is more about JavaScript than it is about React. Well, I think how prototype works is much more important than using React. I think having an interview in JS without knowing prototype is like having an Java interview without knowing polymorphism, abstract class, interface or something.

I have heard Prototype in js used as a term, but I don't really understand what it means. I have programmed a good deal of things in js also, and I have never felt like I needed to explicitly know what Prototype means. Is it really essential to know what this term means?

Re: How Does React Tell a Class from a Function?

#103

Post by victor106 »

sametmax wrote: post #96
quietbritishjim wrote: post #66

Earlier quoted context omitted.

I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…

I have this doubt as well. Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitfalls. To me it seems a good way to ensure most devs (espacially unexperienced casual ones, which are legions in JS by nature of the market) will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will…

I agree with this thinking.

One of the key reasons for choosing a framework/library is to enforce (reasonable) constraints. These constraints help in making sure that the framework takes a longer term view of things than just making it easy in the short term.

Re: How Does React Tell a Class from a Function?

#104

Post by dntrkv »

maceurt wrote: post #102
kbumsik wrote: post #73

> I didn’t know this for years. Please don’t turn this into an interview question. In fact, this post is more about JavaScript than it is about React. Well, I think how prototype works is much more important than using React. I think having an interview in JS without knowing prototype is like having an Java interview without knowing polymorphism, abstract class, interface or something.

I have heard Prototype in js used as a term, but I don't really understand what it means. I have programmed a good deal of things in js also, and I have never felt like I needed to explicitly know what Prototype means. Is it really essential to know what this term means?

Depends on what you work on and what kind of developer you are.

If you are just building frontend applications using frameworks like React and Vue, you don't really need to know how things work under the hood. Especially with all of the new syntactic sugar introduced to JS in the last few years.

But, if you are building lower level tooling and you want to understand why things are implemented the way they are (this post being a great example) you really should understand them as best you can. A lot of design decisions in JS are influenced by these lower-level design "constraints."

Re: How Does React Tell a Class from a Function?

#105

Post by wallawe »

maceurt wrote: post #102
kbumsik wrote: post #73

> I didn’t know this for years. Please don’t turn this into an interview question. In fact, this post is more about JavaScript than it is about React. Well, I think how prototype works is much more important than using React. I think having an interview in JS without knowing prototype is like having an Java interview without knowing polymorphism, abstract class, interface or something.

I have heard Prototype in js used as a term, but I don't really understand what it means. I have programmed a good deal of things in js also, and I have never felt like I needed to explicitly know what Prototype means. Is it really essential to know what this term means?

As a js dev for 6 years now, and having conducted hundreds of interviews, I would say it is not necessary for a junior developer and most of the things they'd be doing.

However, when it comes to a mid or senior level engineer, it's important not to just make things work, but to understand the how and why in order to build performant applications at scale.

So to answer your question, no it's not a necessity to build applications. Yes, it is if you want to excel at building applications.

Re: How Does React Tell a Class from a Function?

#106

Post by jbob2000 »

kbumsik wrote: post #73

> I didn’t know this for years. Please don’t turn this into an interview question. In fact, this post is more about JavaScript than it is about React. Well, I think how prototype works is much more important than using React. I think having an interview in JS without knowing prototype is like having an Java interview without knowing polymorphism, abstract class, interface or something.

I have developed javascript applications for a while now and I have never had to use prototype. If I was asked about it in an interview, I would explain that it's a leaky abstraction, that using it in code means you are over-complicating your solution, and that it seems to be a holdover from when people thought your codebase should be modeled according to reality ("we have users, therefore we should have a user model").

You can absolutely be a great javascript developer without ever touching prototype. Prototype is an infection of object-oriented programming into a functional language.

Re: How Does React Tell a Class from a Function?

#107

Post by ergothus »

sametmax wrote: post #96
quietbritishjim wrote: post #66

Earlier quoted context omitted.

I absolutely agree with you. This makes me very skeptical about the proposed feature in React, called "hooks", which is linked to in the article. It lets you add state to your functional components, and it looks like you end up bundling all your code into one function rather than having a separate constructor to initialise the state (to me, separating out that function is a good thing). I would be interested in the m…

I have this doubt as well. Hooks will allow people to use "class like" features and behavior, but with none of the conventions forced by syntax, plus some pitfalls. To me it seems a good way to ensure most devs (espacially unexperienced casual ones, which are legions in JS by nature of the market) will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will…

> will dump their logic wherever it works with as little structure as it allows. It's a technical debt catalyser, and will make sure nobody feels at home in someone else's code. The community will pay the price in a year.

I don't want to downplay your concerns, but I will say that this is already a problem. Part of the goal with hooks (and I can't say if it achieves that) is to encourage the separation of a lot of state-interaction OUT of the components. Today it is much too easy (arguably it is easiest) to write a component that is basically untestable - basically a mini-application in itself, which is the opposite of good React design.

I'm hopeful that Hooks will help, and I think the original demonstration focused too much on state and not enough on other interactions external to the component, which is where the real pain today exists. I've not played with the alpha at all to have a feel for how realistic my hopes are.

Re: How Does React Tell a Class from a Function?

#108

Post by ravenstine »

ta567657567 wrote: post #40
wz1000 wrote: post #17

I have written maybe 200 lines of JavaScript in my life, and this article has strongly reinforced my desire to never have to write a single one more. The next time someone asks me what the problem with JavaScript is, I will send them this article. "Scheme for the browser" what a joke. Some excerpts for those that didn't have the strength to sit through the entire thing without pulling their hair out: > If you called…

I don't understand why you're getting downvoted, completely agree. I'm hoping WebASM can save the browser from this foul language. Don't even get me started on server-side JS; if it were a nice, sane scripting language, I'd agree, but the amount of hoops, translators, hackish dev tools etc that have been thrown into the mix to wrangle it into a workable experience... it's too much.

I get your hope for WASM, but I'm not so optimistic. That's not because I don't think that WASM would allow for "better" languages(I personally like and prefer JavaScript), but the future you are suggesting might cause even more fracturing in the web development community than already exists with frameworks and changes in ECMAScript.

Arguably, such fracturing already exists with frontend frameworks. But what will that be like when we become fractured by language? Plenty of people like and prefer JavaScript, but seem to be at least as many people who would rather use an entirely different language on the frontend. I know someone will want to chime in and point out that WASM will still need to interact with JavaScript, but that's not really the point; once JavaScript as a language can be effectively ignored by the developer, that complicates our occupation in terms of interoperability.

One of the great things about web development was that workflows could be different but, at the end of the day, the end product is(was?) essentially HTML, CSS, and JavaScript. There were only so many languages we needed to learn in order to write servers, and at the end of the day we just needed to make something respond to HTTP requests. I chose web development because it wasn't going to pigeonhole me as much as other fields of software engineering; one can, or could, take their web development skills from one company and easily apply them to another, no matter the scale.

Today, we have a constantly evolving browser language, several frontend frameworks and rendering libraries, not just PHP; ASP; and Perl for the server but Python; Ruby; Java; Elixir; Node.js; Groovy, and a wide variety of toolchains and transpilation setups. Now, we're going to open the frontend floodgates to different language runtimes, and along with them even more frontend debugging tools?

This field is becoming way less fun. It's not that I don't understand the desire for choice or to simply not use JavaScript, but I doubt that as humans we won't naturally take the freedom given to us and use it to our detriment.

Re: How Does React Tell a Class from a Function?

#109

Post by malvosenior »

finchisko wrote: post #39
adjkant wrote: post #29

Earlier quoted context omitted.

I really don't get how JS on the client and the server is any real advantage - besides sharing some syntax, the models and paradigms are so drastically different it might as well be two different languages. Why make the server so bad when you don't have to? I think JS has its place despite it's flaws, but for the sake of sanity I can't imagine ever using it on the backend by choice. If you want the ease of express, u…

> I really don't get how JS on the client and the server is any real advantage from my own experience, using single language has huge influence on overall code quality. Makes you understand it much better, comparing to situation you must switch between multiple languages. As you gain more experience in it, the less obvious bugs you'll make (just by knowing what's good and what's wrong). The worst js code I see, is co…

Can I ask if you've ever programmed in another language on the backend? I've done plenty of JS and many backend languages and I'd never consider using JS on the backend.

> from my own experience, using single language has huge influence on overall code quality.

From my experience, JS code is really poor quality and overly complex (looking at your build chain) even when written by an expert.

Re: How Does React Tell a Class from a Function?

#110

Post by [deleted] »

IMTDb wrote: post #64
arry wrote: post #60

What's the rationale for allowing the components to be defined as functions in the first place? As far as I can see, it has a single thing going for it: saving a line of code, at the expense of jumping through the JavaScript hoops to implement the class/function distinction described in the post. Besides, when the function component evolves and acquires the need for state or other features, the saved line of code goe…

To me it's all about intent. By using a function instead of a class, you are basically saying "future reader, this component is nothing more than a simple mapping from those values to that DOM tree, don't try to look for internal states or any complex treatment here". Sure you could write a "normal React component without state" and do the same, but having those properties baked in the way you defined the component i…

[deleted]
Post reply on HN