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

191–200 of 251 posts

Re: Get in zoomer, we're saving React

#191

Post by makeitdouble »

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…

On building the next Figma, my first reaction was that Figma should probably have been a compiled GUI application in a ideal world.

Figma is a work tool where a designers are supposed to spend a decent amount of time, and when working on a specific project there is little navigation or moving to other pages. It being in the browser is a technical artifact to help the business model, but inherently there would be nothing lost if it was a local application synching data and changes with a central server.

If time had to be spent making react closer to desktop apps, can’t that time be spent instead on making desktop apps as sandboxed, OS compatible, easy to download and execute as web pages ?

This is something Apple doesn’t care much about, but react core devs also don’t care about desktop likeness, so it seems a to me to be a suitable alternative solution.

Re: Get in zoomer, we're saving React

#192

Post by [deleted] »

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…

[deleted]

Re: Get in zoomer, we're saving React

#193

Post by makeitdouble »

The more I think about it, the more this plea to push web frameworks in the direction of desktop apps feels misguided.

I know Chrome OS is really seen as the way forward for many many people, but what if they are just betting on the trend to last, when it is just the usual cycle of “applets” vs local applications ?

The same way Java was pushed in the browser, to then cement its role in desktop apps (or the Flash -> Air progression), wouldn’t javascript heavy work sites at some point move to a native JS hooked into the system and opening the door to system wide drag and drop, undo etc.

Re: Get in zoomer, we're saving React

#194

Post by jasonjmcghee »

makeitdouble wrote: post #191
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…

On building the next Figma, my first reaction was that Figma should probably have been a compiled GUI application in a ideal world. Figma is a work tool where a designers are supposed to spend a decent amount of time, and when working on a specific project there is little navigation or moving to other pages. It being in the browser is a technical artifact to help the business model, but inherently there would be noth…

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

Re: Get in zoomer, we're saving React

#195

Post by layer8 »

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)

A possible benefit of 6502 assembly is that the instruction set is relatively simple. And you get to implement stuff like multiplication. ;)

Re: Get in zoomer, we're saving React

#196

Post by layer8 »

klondike_klive wrote: post #110
fifticon wrote: post #99

I agree with this guy. I can see that his tone unfortunately irks many to take offense and post. I am sad that microsoft has so dropped the ball on UI, that even MS' own teams use web tech to build apps nowadays. I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days. Often they are even hidden, so…

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!)

That’s probably due to the ISO country code being “GB”.

Re: Get in zoomer, we're saving React

#197

Post by layer8 »

stillkicking wrote: post #148
fifticon wrote: post #99

I agree with this guy. I can see that his tone unfortunately irks many to take offense and post. I am sad that microsoft has so dropped the ball on UI, that even MS' own teams use web tech to build apps nowadays. I particularly lament that scroll bars have become a lost art. We have gone from scroll bars working perfectly in windows 3.1, to .. whatever passes for a scrollbar these days. Often they are even hidden, so…

Scrollbars are actually a real pain to implement. - you first need to lay out the scrollable content normally, without a scrollbar - then you need to detect whether it spills over, and whether a scrollbar is needed - if so, you need to lay out all the content again, in a slightly smaller area - if the content ever shrinks, you need to detect this too - and if the content only _just_ fits, then it is possible that wit…

Yes, scrollbars are not completely trivial, but what you describe used to be a solved problem on desktop UIs, and the reason for making scrollbars invisible were purely aesthetic.

Re: Get in zoomer, we're saving React

#198

Post by shepherdjerred »

AtNightWeCode wrote: post #126
shepherdjerred wrote: post #58

Earlier quoted context omitted.

I think the point is that React is a true programming language with syntactic sugar to make it look templates, vs templates that bolt on some language.

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.

Re: Get in zoomer, we're saving React

#199

Post by UncleEntity »

cowtools wrote: post #43
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…

As someone who has admittedly worked on approximately 0 user-facing programs, it seems like there are not many revolutionary ideas when it comes UI. I have some dream of a sort of user-interface system that exposes controls and data more directly to the user, independent of the author's stylistic choices. Sort of like semantic HTML with style-sheets that are configured on a per-user basis. It would be analogous to th…

> But instead of that it just seems like every toolkit or library wants to be highly specialized and complex, and provide for a very specific use-case rather than making the most general-possible user interface that is universal.

Blender, and 3d modeling in general, is a very specific use case which probably couldn’t just have some UI code thrown up over a library and be expected to work. Not like displaying some text and an image or two to rant about “those damn kids”, there’s real math behind being able to transform mouse movements into 3d space. Expecting to display a 3d environment in whatever front end UI code you want so it can have a pretty wrapper is very unrealistic.

I’m having a hard time even imagining how this would be possible without a large team working behind the scenes to do all the heavy lifting to make this even remotely possible. Wasted time IMHO as having a specialized tools for specialized domains is just how these things work.

Re: Get in zoomer, we're saving React

#200

Post by klysm »

LAC-Tech wrote: post #87

Nevertheless, when it appeared on the scene, it was wild: you're going to put the HTML and CSS in the JavaScript? Are you mad? I still think plain old CSS - separate from any JS or HTML or JS that generates HTML - is the way to go. Just so much easier and less brittle. I get that CSS being too hard for binary tree inverting geniuses to learn is now widely accepted folk wisdom, but it's really not true.

I strongly dislike having all the css for the site in one place because the dependencies are opaque and it’s hard to apply local reasoning. For some CSS that’s what you want, but for a lot of use cases you want very specific rules coupled to very specific DOM. When I have that kind of relationship I want to control the blast radius and not let it leak out to the rest of the app. I also want co-location with the thing that’s making the relevant DOM.

I also do think CSS is hard to learn because of how vast it is with the decades of shit piled on. There’s no clear way to do a lot of things, and if I have a solution, there’s always this doubt that I’m holding it wrong and fucking over future me.

People that know CSS tend to hate things like tailwind and css-in-js because it’s an absolute abuse of the core design principles of “correct” CSS. But these things succeed for not 100% bad reasons.

Post reply on HN