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

Get in zoomer, we're saving React

acko.net

Post reply on HN
Print view View original

21–30 of 251 posts

Re: Get in zoomer, we're saving React

#21

Post by AaronFriel »

I thought this was the most insightful part, though it would be the second most if the author did more than allude to conflict-free replicated data types.

Whenever you build a tiny language for the purpose of templating, it's worth asking yourself if it's really worth it to have to reinvent variables, loops, branches, scoping, expressions, and functions... Poorly.

> Many competing frameworks acted like this wasn't so, and stuck to the old practice of using templates. They missed the obvious lesson here: every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code. A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist. Designers don't want to code at all, while coders want native expressiveness. It's just that simple.

Re: Get in zoomer, we're saving React

#22

Post by ccorcos »

> Every templating language inevitably turns into a very poor programming language over time.

This realization is what initially sold me on React. I just wanted program and build abstractions with an actual programming language!

Re: Get in zoomer, we're saving React

#23

Post by franciscop »

ccorcos wrote: post #22

> Every templating language inevitably turns into a very poor programming language over time. This realization is what initially sold me on React. I just wanted program and build abstractions with an actual programming language!

Exactly, I was a bit undecided back in the day thinking React and Angular might be similarly valuable, and I don't remember if there was even Vue yet or not (I believe not yet). Angular had just split, and I had to help contracting for a company using Angular 1, and OH BOY the page was horizontal and most of the programming statements happened within those nightmarish ng-if, ng-repeat, ng-{please-kill-me-know}. I believe there were parts up to 350-400 columns wide.

That's exactly when I learned that same realization, and decided never to use (if I can avoid it) a programming environment that defines its own templating language.

Re: Get in zoomer, we're saving React

#24

Post by EugeneOZ »

Hey, author!

I also remember something, and you forgot to mention it: other frameworks were honestly saying that they took some ideas from React (or improved their solutions being inspired by React’s ideas).

I don't think it was a good idea to use such a hostile style of writing - it is ok for web frameworks to evolve. It is more than ok to share ideas. Every time I see that some new framework took some idea of React (or Ember, or Angular, or PHP) - I see the “credits”, the authors are not trying to hide it.

Some people are criticizing some frameworks - it is ok, no need to start holy wars because of that. Valid criticism will help, pointless toxicity will just shade away.

Re: Get in zoomer, we're saving React

#25

Post by Gigachad »

bagels wrote: post #2

"Both the orange and red site recently spilled the tea about how mean Uncle React has been" Anyone know what this means?

“The orange site” is some weird euphemism twitter users use when complaining about HN. It’s also a great search term to chuck in to twitter for some entertainment.

Re: Get in zoomer, we're saving React

#26

Post by asddubs »

AaronFriel wrote: post #21

I thought this was the most insightful part, though it would be the second most if the author did more than allude to conflict-free replicated data types. Whenever you build a tiny language for the purpose of templating, it's worth asking yourself if it's really worth it to have to reinvent variables, loops, branches, scoping, expressions, and functions... Poorly. > Many competing frameworks acted like this wasn't so…

I always thought the point of the template language was more to enforce the boundary of presentation and code. and thus any template language that grows too powerful is a bad template language, because it's no longer doing the one job it has. So I think a template language should have loops, (non mutable) variables and basic conditions, that's it. So if there's something you can't do in your template that you want to do, the solution then isn't to write some sort of hideous thing in a bespoke templating language, but to add another variable/loop/whatever to the template.

Of course this requires coordination and the larger the organization, the more this is going to slow things down. I also don't think this separation is as important on frontend javascript code, since the lines get blurry there anyway.

Re: Get in zoomer, we're saving React

#30

Post by francislavoie »

crooked-v wrote: post #7

This post ultimately seems to spend a long time complaining about other people not putting in the effort to fix the problems of React... while the author doesn't offer any solutions or even ideas for solutions. Also, the author makes repeated digs at React 18's concurrent mode work while at the same time complaining about the kind of stuff concurrent mode is supposed to fix (for example, React updates not happening f…

> the kind of stuff concurrent mode is supposed to fix (for example, React updates not happening fast enough to keep up with mouse dragging).

How does concurrent mode help with mouse dragging? I went reading through the React docs on this and they only really talk about data fetching patterns. I'm not sure I understand how it would apply to mouse events.

Post reply on HN