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

241–250 of 251 posts

Re: Get in zoomer, we're saving React

#241

Post by chris_armstrong »

AceJohnny2 wrote: post #211
chris_armstrong wrote: post #39

This article is weird linking together many unrelated strands of thought. Like linking reactive programming to “reactive” UIs, when really they mean UIs that are forgiving to their users instead of breaking down. Or how by coding on the web we’ve lost the immediacy of a UI that runs on our desktop, and the primitives (like undo/redo stacks) that make desktop user interfaces friendlier, at least without having to buil…

> This article is weird linking together many unrelated strands of thought. You know, this isn't the first time I've thought as much about Acko's writing :\ Often there isn't a coherent thesis, but a bunch of interesting related thoughts that don't add up to anything specific.

Yeah there's definitely some interesting stuff in the other blog posts, but oh boy, am I left begging for a narrative

Re: Get in zoomer, we're saving React

#242

Post by zarzavat »

makeitdouble wrote: post #233
jasonjmcghee wrote: post #194

Earlier quoted context omitted.

It being in the web means I can work on any computer without having to install anything, embed a Figma in a doc or wiki, and it’s super easy to write plugins (html/css/js).

The thing to me is...you are already dowloading the whole figma's client code base and running it in your browser. If it was a PWA it would even stay there. Your point on installation is accurate in our current ecosystem, and I wonder how we could change that so "installing" isn't a hurdle. That's clearly not a simple problem to solve, but making the web "native" probably isn't either.

Installing is a backwards step compared to accessing a URL and loading a cached resource. It’s nostalgia. What you want is guaranteed “cache”. i.e. the resources are guaranteed to stick around and not get evicted randomly, but can still be evicted if the application is updated and that resource expires.

Re: Get in zoomer, we're saving React

#243

Post by noobermin »

blep_ wrote: post #177
noobermin wrote: post #169

Earlier quoted context omitted.

Was about to upvote then you said 6502 asm isn't useful in 2022... If anything, learning 6502 asm is instructive because it isn't very abstract but forces you to turn abstract thinking to explicit instructions.

Any assembly language gets you the same thing, and 6502 assembly is likely not the one your current machine understands natively. (if it is, I would like to read your blog)

6502 is so bare bones, that programming it even over things like x86 is instructive, it really forces you (or it does for me) to think hard about doing things, even mundanely "easy" things that people who only program C say are fast and low level.

But anyway, it's not "useful" for actual everyday work, it's more of a nice challenge that keeps your mind sharp.

And for my c64, ah I need time to solder stuff so it can connect to another machine, much less the internet ;) one of these days...

Re: Get in zoomer, we're saving React

#244

Post by makeitdouble »

zarzavat wrote: post #242
makeitdouble wrote: post #233

Earlier quoted context omitted.

The thing to me is...you are already dowloading the whole figma's client code base and running it in your browser. If it was a PWA it would even stay there. Your point on installation is accurate in our current ecosystem, and I wonder how we could change that so "installing" isn't a hurdle. That's clearly not a simple problem to solve, but making the web "native" probably isn't either.

Installing is a backwards step compared to accessing a URL and loading a cached resource. It’s nostalgia. What you want is guaranteed “cache”. i.e. the resources are guaranteed to stick around and not get evicted randomly, but can still be evicted if the application is updated and that resource expires.

I'm looking at mike_hearn's response in the thread, and it's going in a good direction I think (https://hydraulic.software), albeit platform owners would need to do a lot more to help that kind of approach to succeed.

Looking at the current situation from a high level view, we already have URLs for applications (you'll need to declare a unique identifier for your bundle), and Apple and Google are already toying with the idea of immediately executable apps with App Clips and Instant Apps, so it feels like we're actually pretty close from that alternate reality where "installing" can be seamless to the user.

(+ iOS also handles removing unused apps from the device, so that part should also be ok)

Re: Get in zoomer, we're saving React

#245

Post by efdee »

LtWorf wrote: post #234
efdee wrote: post #145

Earlier quoted context omitted.

Don't expect me to download your .exe if you're solving a problem that can be solved using a web app.

Don't expect me to care if my exe solves your problem but you are too stubborn to use it.

If you don't care about what your potential users want, that's fine, but I don't see why you would be partaking in an argument that's mostly about trying to reach more users.

Re: Get in zoomer, we're saving React

#246

Post by adigau31 »

hantusk wrote: post #140

When reading through the comments here, I really feel like the article was misunderstood. My summary of the article is: Point 1: React solved all the right things, but its current trajectory, does not prioritize developing the fundamental tooling we need. 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 an…

> React does not allow us to build a new Figma Did you take a look at Liveblocks? They have an example of an advanced whiteboarding experience: https://liveblocks.io/examples/collaborative-whiteboard-adva... And they recently released a set of APIs so thast you can build a Figma-like dashboard to seewho's in which board and set permissions: https://liveblocks.io/docs/guides/managing-rooms-users-permi...

Re: Get in zoomer, we're saving React

#247

Post by klondike_klive »

mkl wrote: post #114
klondike_klive wrote: post #110

Earlier quoted context omitted.

Recently scrolling through a list of countries to choose 'United Kingdom' I eventually found it under 'G'. The nearest I can figure, it was previously for 'Great Britain' and was never re-sorted? (Never mind that nobody in the UK has called it Great Britain since maybe mid 20th century!)

People still say Great Britain all the time (it refers to something slightly different than the UK though [1]). It's what the Olympic team is called, for example. [1] https://www.cgpgrey.com/blog/the-difference-between-the-unit...

That's true, I forgot about Team GB!

Re: Get in zoomer, we're saving React

#248

Post by wildermuthn »

Except for the non-dancing zoomers catching stray bullets at the end, this is a really great rant. He’s absolutely right that React won for very good reasons, reasons that new frameworks don’t seem to understand by making old mistakes (templates and directives, looking hard at you). But the rant goes deeper in its accusation that React (and the web) has forgotten the past as well. React (and the web in general) isn’t a great solution for data that is 1) real-time, 2) multi-user, and 3) contextually undo-able.

He’s not wrong, but I wonder what kind of applications he’s working on that require all three of those characteristics simultaneously. If you only need 2 out of his 3 data requirements, then React + Apollo can handle it just fine in experienced hands.

For apps that truly do need all 3 capabilities, the problem isn’t React per-se. The problem is that such apps are just complex by their very nature — even by reducing accidental complexity to zero, you are still stuck with a huge amount of essential complexity. That’s just the nature of the beast.

Although I have long since moved on from Clojure since Rich Hickey made it clear Clojure was not about me but about him and his consulting business, you really need a powerful language like Clojure to do something as tricky as the author wants poor little JS to do. Someone one described JS as a cute dog with three legs — you feel for it, and take care of it, but you know it really isn’t capable of too much. A hard problem needs a powerful tool, and nothing written in JS (kinda-typed or not) is going to get the job done.

Re: Get in zoomer, we're saving React

#249

Post by pas »

shepherdjerred wrote: post #240
pas wrote: post #238

Earlier quoted context omitted.

Hm. I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. HTML is the templating. JSX is a super lightweight layer on HTML with its own weird rules. I don't like Angular's default verbosity of separating the template from the logic, nor it's hijacking of the simple double quotes, but I disliked fighting with JSX and too too large files in React. Plus in my experience React projec…

> I find this kind of inconsistent, as you already have HTML in your JS, so it's not just JS. You don’t write HTML in React. You write JSX that gets compiled down to function calls which at runtime becomes HTML. JSX is a nicer syntax to make function calls look like HTML. I know this sounds pedantic, but this is the exact thing that differentiates React from others.

Angular does the same :)

As far as I know all modern frameworks only produce JS files and the index.html only contains the .

Re: Get in zoomer, we're saving React

#250

Post by Cthulhu_ »

cturtle wrote: post #123
StuckDuck wrote: post #118

Earlier quoted context omitted.

I'd say macOS actually is a lot more polished than Windows, but I agree with you that it is damn confusing. Try "closing" an app for example and you'll find that half the time it will not have closed properly, or maybe it did, who knows? It depends on the app. If it's vanilla you can bet it will have to be closed with CMD+Q

That’s because “proper” macOS apps close windows not apps when you click the little red dot in the upper left. See some of the answers here https://unix.stackexchange.com/questions/4618/why-mac-applic... And I agree it’s different from all the other operating systems, once I understood why it made sense. For example, I can copy an image to my clipboard, and open Preview. No window opens, but the top menu bar shows th…

It makes sense if the initial startup of an app is expensive, memory is cheap, and creating new windows is fast.
Post reply on HN