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

What I wish I knew about React

bitsofco.de

Post reply on HN
Print view View original

271–280 of 301 posts

Re: What I wish I knew about React

#271

Post by krapp »

cambalache wrote: post #261
krapp wrote: post #241

Earlier quoted context omitted.

It's an elitist mirror to 4chan's edgelord culture in many ways.

if only, for all their sins (which are lots) 4chan is a very fascinating place. The other day I was fantasizing (lol) about giving a talk to out-of-touch academics/journalist boomers and explaining them the 4chan phenomenon. There are lot of very smart people there. You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".They tend to create lots of Inter…

>You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".

My point is there are affectations in both communities (4chan and HN) that are strange opposites of one another. Here, people often pretend to be more polite and erudite than they are, there, people often act more rudely than they normally would, because that's the culture, that's the mask you're expected to wear.

And on both sides there's a pretension which you're kind of displaying. You're talking about a site as vast and varied as Reddit as a whole as if it were a single forum, and dismissing it as qualitatively lesser than an anonymous imageboard that has shitposting as a central part of its identity. Find some well moderated subreddits for any particular genre and you'll find quality of conversation equal to anything on 4chan, or even HN.

Also, you know, 4chan has been around long enough at this point that a lot of "out of touch academics" and "journalist boomers" have probably been there.

Re: What I wish I knew about React

#272

Post by jarym »

koonsolo wrote: post #266
hombre_fatal wrote: post #231

Earlier quoted context omitted.

Just curious, which framework are you referring to? Every time I see someone claim such a thing, it's usually only distantly related. Like it too has a render() function. I mean, you can find old FRP phd/whitepapers but I don't think they prohibit you from ever saying "$X introduced $concept" without a disclaimer that it wasn't the first. So if you're going to insist, then why not share some prior art for the discuss…

I started my career in 2002 (been programming since '93), and back then there was no client side rendering. So my guess is, he's talking about server side rendering that spits out html. Since those things really miss the 'react' part of React, it is still quite different.

I used SmartClient when it was launched in 2002 and that did client-side rendering back then: https://en.wikipedia.org/wiki/SmartClient - I've recently taken the JS version (not GWT) and ported it to a set of ES6 classes and modules.

I used to work for a portal vendor called Plumtree in 2004 (later acquired by BEA and then Oracle) and much of their stuff did client-side rendering.

The idea of making web interfaces more declarative and less tied to DOM manipulation has been evolving since then. Many developers I'd encounter back in those days moaned that we were not using jQuery or MooTools or whatever.

React is very nice - don't get me wrong - but its popularity has much to do with the mindset of developers shifting away from seeing JavaScript as a way of 'adding spruce' to 'web pages'.

Re: What I wish I knew about React

#273

Post by koonsolo »

jarym wrote: post #272
koonsolo wrote: post #266

Earlier quoted context omitted.

I started my career in 2002 (been programming since '93), and back then there was no client side rendering. So my guess is, he's talking about server side rendering that spits out html. Since those things really miss the 'react' part of React, it is still quite different.

I used SmartClient when it was launched in 2002 and that did client-side rendering back then: https://en.wikipedia.org/wiki/SmartClient - I've recently taken the JS version (not GWT) and ported it to a set of ES6 classes and modules. I used to work for a portal vendor called Plumtree in 2004 (later acquired by BEA and then Oracle) and much of their stuff did client-side rendering. The idea of making web interfaces mo…

The revolutionary part of React is not client side rendering, it's the composition (and reaction) of GUI through state changes.

A quick look at SmartClient shows that it still uses the old OO way of widget composition (widgets having .show() and .hide() methods, etc). This is not at all how React works. In react you render your GUI based on state, and events never manipulate widgets, they manipulate state. It's a functional way of approaching GUI's instead of an Object Oriented way.

The React way of building GUI's is now used outside of the web, for mobile apps through React Native and Flutter. This is completely different that any pre-existing GUI frameworks.

Re: What I wish I knew about React

#274

Post by jarym »

koonsolo wrote: post #273
jarym wrote: post #272

Earlier quoted context omitted.

I used SmartClient when it was launched in 2002 and that did client-side rendering back then: https://en.wikipedia.org/wiki/SmartClient - I've recently taken the JS version (not GWT) and ported it to a set of ES6 classes and modules. I used to work for a portal vendor called Plumtree in 2004 (later acquired by BEA and then Oracle) and much of their stuff did client-side rendering. The idea of making web interfaces mo…

The revolutionary part of React is not client side rendering, it's the composition (and reaction) of GUI through state changes. A quick look at SmartClient shows that it still uses the old OO way of widget composition (widgets having .show() and .hide() methods, etc). This is not at all how React works. In react you render your GUI based on state, and events never manipulate widgets, they manipulate state. It's a fun…

It does have show and hide methods - but inside the framework it is deeply compositional. If you have a chance to look at the docs search for ‘autoChild’ which achieves much the same as react and co but using different terminology.

Re: What I wish I knew about React

#275

Post by cambalache »

krapp wrote: post #271
cambalache wrote: post #261

Earlier quoted context omitted.

if only, for all their sins (which are lots) 4chan is a very fascinating place. The other day I was fantasizing (lol) about giving a talk to out-of-touch academics/journalist boomers and explaining them the 4chan phenomenon. There are lot of very smart people there. You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema".They tend to create lots of Inter…

>You compare the recommendations in music/books/cinema between them and reddit and it is "People" vs "Cahiers du Cinema". My point is there are affectations in both communities (4chan and HN) that are strange opposites of one another. Here, people often pretend to be more polite and erudite than they are, there, people often act more rudely than they normally would, because that's the culture, that's the mask you're…

On the contrary, that is the refreshing part of 4chan, the unpretentiousness, a guy can talk about Nietzsche using memes and somehow make a good argument. Reddit is pretentious without any reason for it to be, at least here in HN there are competent people. And I was comparing the lists of recommended books of r/books vs its equivalent in 4 chan, as far as an apple vs apple comparison goes.

Re: What I wish I knew about React

#276

Post by azangru »

sngz wrote: post #260
II-V-I wrote: post #258

Earlier quoted context omitted.

Oof. Sorry to hear the FE dev gives up like that. You may become a JS expert if that carries on. > the solutions seem to be super hacky when I've found other frameworks out there that handle these things out the box or more gracefully. I'm curious to hear what alternative frameworks handled these things better? The only one I've used recently, other than React, is Vue.

So the issue I'm referring to is this, which has been open since 2017 https://github.com/facebook/create-react-app/issues/2353 There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO. I ultimately ended up forking off this repository…

> So the issue I'm referring to is this, which has been open since 2017

I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or have an api endpoint that your app will query before or during rendering and will get all the relevant config information from it.

> but I think next.js and nuxt.js does

Probably because they server-side-render. And even if your app renders on the client side; even if you don't use next, nuxt or whatever, there is no-one stopping you from dynamically serving the html skeleton with the relevant variables in it.

But then, it all probably has been mentioned in that issue. I wonder why it wouldn't be a good solution.

Re: What I wish I knew about React

#277

Post by [deleted] »

II-V-I wrote: post #255
dehrmann wrote: post #225

Earlier quoted context omitted.

This is usually a smell that the person is competent at what they do, but doesn't know what's going on under the hood. Funny enough, I'd rather work with someone who doesn't know the specific technology, but knows what the language was built on top of, because they'll have a better intuition for how it actually works and be able to learn it relatively quickly.

I'd rather work with someone like that, too. All is well and good when one can crank out React components, but if that same person doesn't know how to find, for example, the tag name of a element from an event handler, a little red flag goes up for me, and as you said, probably doesn't know a great deal about what's going on under the hood.

[deleted]

Re: What I wish I knew about React

#278

Post by Can_Not »

iluvblender wrote: post #75
ma2rten wrote: post #35

Earlier quoted context omitted.

Maybe something like svelte?

I just started studying svelte today (alongside Vue). I look forward to sharing my thoughts soon.

Things I wish I knew about Svelte: error handling is fragile and/or non-existent.

Re: What I wish I knew about React

#279

Post by cloverich »

genezeta wrote: post #12

React have sold very well the "it's a library" mantra. I find this, at least, bends the difference to build a marketing point around it. The point they make, and the one everyone writing about React simply repeats, is that "it doesn't give you everything" so you can use it with any other library/framework without trouble. While this claim may be indeed correct, it doesn't mean it's a library. React is a UI framework…

The library argument makes much more sense if you've been around the block in web UI. There are many precursor and concurrent web frameworks that do much more than just the UI: They control data management, dependency injection, etc. For some, the UI is nearly an after thought of the model layer. So maybe its not completely accurate but contextually it rang very true to someone like myself, who had used 4-5 other frameworks before using React, and was absolutely one way it stood out to me.

Re: What I wish I knew about React

#280

Post by sngz »

azangru wrote: post #276
sngz wrote: post #260

Earlier quoted context omitted.

So the issue I'm referring to is this, which has been open since 2017 https://github.com/facebook/create-react-app/issues/2353 There's a slew of workarounds offered in that github issue, most people (including another team in my org) opted to just rebuild the app every time a docker container is created which kind of defeats one of the major pros of using docker IMO. I ultimately ended up forking off this repository…

> So the issue I'm referring to is this, which has been open since 2017 I probably don't appreciate the complexity of the issue, but I would say environment variables are not React's concern; it’s up to you how to architect your code. If you want runtime environment variables, then either add them to the html that React will render into, so that the javascript code can read these variables in before rendering, or hav…

> but I would say environment variables are not React's concern; it’s up to you how to architect your code

I don't consider it part of the "code" but part of configuring the application based on the environment you're deploying it on(Precisely why the FE dev basically said its not his problem). The fact that a lot of people are suggesting you just build the app every time you deploy a docker container is really concerning to me.

> I wonder why it wouldn't be a good solution.

it just feels dirty. it's the fact that I have to add these into the code that it feels like a hacky solution for a production app. using a shell script to read read the OS environment variables to create an ENV file then convert that ENV file to a javascript file that is then read, it seems like many things can potentially go wrong.

Ideally they would just deal with this within the dotnev library

Post reply on HN