Live data from Hacker News

Get in zoomer, we're saving React

acko.net

221–230 of 251 posts

Re: Get in zoomer, we're saving React

#221
post #66
post #60

Earlier quoted context omitted.

disagree, because the alternative is having a million tiny templates, which is annoying and cumbersome. sometimes you just want a condition to check if a user has an avatar, or if there are replies to a post, or whatever else. same with loop, if something is specific to a template, there's no reason for repeating content to not be a loop (I don't think a template system should allow custom loops though, only looping…

If one wants a view for the whole page, then using a programming language with a good support for embedding strings will be a better solution as it avoids the need to learn one more language.

DSLs have their place. arguably we have too few of them. we always use a general language. which is good, because it's general, sometimes great at a few things, but usually very awkwardly at most of the things.

Alan Kay (and his teammates during the STEPS project at VPRI) spent years and years thinking/experimenting with this, here's the final report from 2016: https://news.ycombinator.com/item?id=11686325

"The big breakthrough is making it easy to create new DSLs for any situation."

Re: Get in zoomer, we're saving React

#222
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!

I just wanted to wire up shit, make pages, send requests & receive responses ... and not spend days trying to pick the right router, form, state and whatever library for my view layer, and look for TS definitions for them, so I stayed on Angular2+ ^^

Re: Get in zoomer, we're saving React

#223

Earlier quoted context omitted.

React is just JS as any other app using JS with templating. I really fail to see the benefit with the React approach. If anything it makes it more difficult to have a 100% match between design and the end product.

How much React have you written? Because React is just JavaScript, you can take traditional programming patterns and apply them to your UI, for example higher-order components. You can't do this with templating.

Hm, can you describe what do you mean by "can't do this with templating"?

Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't?

Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other components programmatically[1] with complete dynamism.

[0] depending on the use case there are different preferred ways: directives, which have access to the wrapped component and its template, and can interact with it in many ways, or you can do it from raw TS ( https://github.com/abumuawiyah/ng-ivy/blob/master/src/app/ap... see the withTheme and withStyles functions )

[1] for simple things https://blog.angular-university.io/angular-ng-template-ng-co... ... see also the official working example from the docs https://stackblitz.com/edit/angular-568wsw?file=src/app/ad.s...

Re: Get in zoomer, we're saving React

#224

Earlier quoted context omitted.

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

It seems to always be said with disdain. Is there a reason these people don't want to use the name? Do they really dislike the color orange?

because the name is harmless, uninteresting and unambiguous, but if anyone asks "what's that orange site" they can explain that it's bad because it's libertarian/capitalist/idealist/optimist/progressive/every-account-is-elon-musk-himself.

and this helps them to maintain their nice oversimplification too.

Re: Get in zoomer, we're saving React

#225

How can React be so great if Facebook's own UI sucks. They can't even get the back button to work correctly.

i think the back button behavior is intentional - at least on mobile.

if someone sends you a link to a piece of content on FB and then you use the back button it sends you to your feed, and now they have a much greater chance of trapping the dear user in their algoverse.

Re: Get in zoomer, we're saving React

#226
post #202

Earlier quoted context omitted.

> React does not allow us to build a new Figma (consistent undo/redo in collaborative settings, immediate low-latency mutation of app state to reflect user changes and building fundamentals to SaaS interoperability) If I wanted to write the next Figma, the first thing I’d reach for is Phoenix Liveview + Channels with Vaxine/AntidoteDB or some other eventually consistent CRDT store for collaborative editing and host i…

> I’d forgo the ‘front end’ completely Not to dismiss your argument/stack preference, but forgoing the front end for a graphic design tool might prove difficult. EDIT: But yes, CRDT-backed stores are definitely the way to go for a requirement like this.

> but forgoing the front end for a graphic design tool might prove difficult

How so?

Offline support? Collaborative tools don't really have a good offline story by nature.

Ping times? If you use fly.io you're going to have great availability and low latency. It's like a CDN for live apps.

I'm not biased against a 'client-side front end', it's just that a collaborative tool that is 'always online' might as well use a 'live app' style where the server drives the DOM. It solves all the problems that the OP raised in the quote, and it's less about where React should go next, because client-side front end literally can't solve those problems due to their nature.

Re: Get in zoomer, we're saving React

#227

Earlier quoted context omitted.

(As a zoomer,) I know that React is designed as the way it is because it's limited by the DOM model for all rendering and user interaction, whereas for native apps you have much more freedom in terms of design space of GUI toolkits (from a completely retained model like Qt to highly immediate ones like IMGUI). The disappointment of the article is that he talks about how the Mac OS X apps were the pinnacle of desktop…

You know it well (DOM, Retained | Immediate). There's nothing to do with saving react here. Talking about browser app specially, I'd keep eye on standard like Template Instantiation and the coming up Symbol as Map's key. It's closed to the recent "Signal (reactivity)" trend. A way to update part of tree more efficiently without re-render-the-whole-thing. As long as we still use DOM, it's not going to be more revoluti…

The only possible Revolution I see is not using the DOM. JS + WASM is fast enough, the DOM is not fast enough, or good enough, enough here meaning enough for creating highly dynamic 60FPS experiences. Main issue with leaving it behind is A11Y though.

Re: Get in zoomer, we're saving React

#228

> What's really frustrating about all this is how passive and helpless the current generation of web developers seem to be in all this. It's as if they've all been lulled into complacency by convenience. They seem afraid to carve out their own ambitious paths, and lack serious gusto for engineering. If there isn't a "friendly" bot spewing encouraging messages with plenty of emoji at every turn, they won't engage. > A…

It is as old as history itself. What you're witnessing is a result of what I call the problem of knowledge.

Realize that, everything that is learned, any knowledge gained, and new technology invented, will eventually be lost and forgotten - as the people who gained said knowledge or invented said technology will eventually die, and the next generation is born ignorant. Yes, we as a species try to pass our knowledge to the next generation, via teaching, books, or what have you, but it's a never ending problem that can't ever be resolved.

Think about it, If I were to invent - say a new programming language tomorrow, the entire world would be ignorant of its existence, let alone know how it even works. Now I could go on to teach others that my new programming language exists and how it works, but this takes time, and people don't have infinite time to learn things. So as time goes on, and we learn and invent more and more things as a species, the next generation has a greater amount to learn than previous generations. Eventually there comes a point where there's too much knowledge to learn, that even if you spent your entire lifetime trying to learn what your ancestors had recorded, you would die before having learned everything. So knowledge inevitably does get lost between generations, and thus, history tends to repeat itself, and the next generation seems decadent for not knowing what you came to know.

Computer technology is just a perfect microcosm demonstrating this problem, as new things get created all the damn time (often to be just reinventions of old things). Heck, even most old programmers I know say they struggle to keep up to date on things.

And it is as old as history itself, as this is what Ecclesiastes 1:9-11 is essentially talking about. Heck, look at most ancient civilizations, and how little we can comprehend what we still have of their writings.

Re: Get in zoomer, we're saving React

#229

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

DSLs have their place. Twig for example is/was a nice templating lib for PHP. (Smarty is of course completely cursed.)

There's value in separating the presentation layer from the other parts. There are nice things in Twig that are not in PHP. (Pipes, for-else, etc.)

Of course PHP was (is?) far from a general purpose language, but a templating lib allows PHP core devs to focus less on "templating".

And it's just reality that fixing/improving/iterating/evolving a library is much easier than the host language. Updating a lib version is easier than updating language version. Similarly it's a real constraint that not every company/team/engineer will be able to "just hire competent designers".

React is also suffering from this. (Due to its popularity, hence it's the victim of its own success. Or looking at the big picture it's the normal part of the hype cycle.) The article mentions that every React repo/project is different and full of their own conventions. (And implies that they are broken too.) Oh, who would have guessed? After all it's just a view layer and people will put a myriad things on top of whatever the current "create react app" spits out.

Re: Get in zoomer, we're saving React

#230
post #223

Earlier quoted context omitted.

How much React have you written? Because React is just JavaScript, you can take traditional programming patterns and apply them to your UI, for example higher-order components. You can't do this with templating.

Hm, can you describe what do you mean by "can't do this with templating"? Do you mean that since React/JSX kind of a superset of JS you can do higher order stuff in it, whereas in a simple templating language like Jinja2 you can't? Isn't that a false equivalence? I mean I regularly use patterns similar to HOCs in Angular. It's easy to wrap components[0] and it's just as possible to project components into other compo…

I wrote this on my phone. Hopefully it makes sense.

No templating language is going to beat a general purpose programming language as far as features go.

There’s no technical limitation of templated languages that would bar them from having the same functionality as a general purpose language. Whoever is designing the templated language is probably not going to design something as powerful as a general purpose language.

Angular built a specific set of keywords to include higher order components. React did no such thing — they exist for free because it’s all just JS. You could imagine that there are other patterns that exist in JS that you can’t express in Angular because it doesn’t have all of the flexibility of JS.

From your example you showed that you used TS to create your component, essentially using an escape hatch from Angulars templating language to do what you want. You don’t have to escape from React, because you’re already in JS.

I haven’t used Angular in a while, but I have been using Vue recently. The difference is huge. I can’t (easily) put a Vue component in a stack. I have to learn Vues syntax that will have zero transfer when I go to another framework, whereas React is just JavaScript (JSX does change some HTML attributes, but it is generally 1:1).

To close, I don’t think React is required to be productive or write good UI. I just really like it because there’s no magic going on. It’s just syntactic sugar over JS.

Post reply on HN