Live data from Hacker News

Get in zoomer, we're saving React

acko.net

211–220 of 251 posts

Re: Get in zoomer, we're saving React

#211

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.

Re: Get in zoomer, we're saving React

#212
post #159

Can any Web Dev framework survive long enough to be stable? If I learn some fancy framework today, I expect to use it for years to come else my knowledge and time is wasted.

No, it won't. Web is an ever changing platform, with a lot of churn. The most long lived framework currently is emberjs. But it is not the hottest, so you won't find it discussed much. The most "future proof" framework is "React" which is the one mentioned in Original article. It goes without saying but React is the cause of a lot of churn in js ecosystem, particularly due to its "no-battery included" approach. ## wh…

What shift is Angular 2+ undergoing? In my experience it’s been remarkably stable since the first couple of releases. I’ve often wished they were more willing to support newer paradigms (functional components, observable inputs, etc.).

Re: Get in zoomer, we're saving React

#213

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…

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

It can! This is (sort of) the vision of my current company [1]. Its founding belief is that web tech is reaching end of life and it's time for our industry to start looking at what comes next. The long term goal is to create a new competitor to the web, but not all at once. Instead we're doing it via incremental iteration on current desktop development. Starting with better distribution tools we want to work up to sandboxed, streamed, cached, crawl-able, embeddable app/document hybrids just like the web has but with very different architectures that benefit from what we've learned from 30 years of the web.

The starting point is to make it as easy for people writing desktop software to distribute their work cross-platform as it is for people making static websites. The resulting UX is that of a normal desktop app as far as the user is concerned but from the developers perspective they just grab the tool we've made and run "conveyor make site". Out pops a set of files you can upload to any static HTTP server, which are fully signed, notarized and self updating for every desktop OS. It can do this because all the packaging and signing code is implemented by the tool itself, so there are no native dependencies and it can thus be very convenient to use.

For people who like the React model an interesting way to use this is to write an app using Jetpack Compose [2] for Desktop [3]. You get a fully functional/reactive UI toolkit but without needing a mishmash of HTML/CSS/JS - it's all just Kotlin. Your Android code can be shared directly with the desktop version (with layouts for larger screens of course), and you can then go ahead and start integrating with native OS capabilities as you see fit by directly invoking their APIs. For "mobile first" companies that develop a web version primarily for desktop users, this can eliminate the need to build a web app entirely (or you can use a minimal one for search engines). Next week we'll be releasing an update that improves support for Compose Desktop apps, in fact.

There's more work to do on making distribution trivial for everyone, and of course you can use Conveyor with Electron apps if you want to - the goal here is to be layered so the lower levels are usable by everyone including web developers, and the platform gets incrementally more opinionated as you go up the layers. Once the core product has matured further we'll be exploring an experimental architecture in which RDBMS' fully replace the web server, and what advantages you get from doing so.

[1] https://hydraulic.software/

[2] https://developer.android.com/jetpack/compose

[3] https://www.jetbrains.com/lp/compose-desktop/

Re: Get in zoomer, we're saving React

#214

Earlier quoted context omitted.

I didn't read the article, but just based on the passages you have quoted and based on my recent experience, I will have to agree with the author. I recently learned that GitHub has a discussions page which is separate from the issues pages. To pass the time and to give back to the community I try to help people and answer their questions. It's a bit concerning to me that when I point some people to the right directi…

I don't know if it's the whole new generation or only the web/nerdy part of it.

Mostly likely it's neither, and the problems we notice is due to a very biased sample.

We don't see the many thousands who solve problems quietly, and even when we see them we tend to make note only of the most unskilled ones.

Compounding this with the fact that all over the world more people are motivated to learn and work in IT we are simply bound to see more extreme outliers.

Re: Get in zoomer, we're saving React

#215

Earlier quoted context omitted.

> Anybody know why this is the case? Because it's often true, although it's more cyclical than downhill. You have an open emerging technology and people start out self-reliant and have to learn from the ground up out of necessity, and over time things become so tower of babel like that new people can't or don't need to understand it anymore. Then it gets so bad that someone tears it down and you're back to the starti…

"Hard times create strong [developers]. Strong [developers] create good times. Good times create weak [developers]. And, weak [developers] create hard times."...?

maybe it's true for development, though unlikely :)

https://acoup.blog/2020/01/17/collections-the-fremen-mirage-...

Re: Get in zoomer, we're saving React

#216

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…

The big take away from software eating the world and everything is in the cloud now, is that making things that can scale down and up wins over specialists' specialized custom hyper optimized tools.

was Word 3.1 better than TeX or Quark Xpress or whatever? No, but it allowed people to do stuff quickly. To get things done. It was bad at scaling up, though.

Then online/cloud tools enlarged the pool even more. And finally it was possible to compete with the curse of the default, the shit forced on the world by OS vendors, corporate office suites.

Figma-like tools are the endpoint that can serve 99% of possible users. Both professionals and clueless casuals (and they don't even need to download and setup anything).

Re: Get in zoomer, we're saving React

#217
post #205
post #175

Earlier quoted context omitted.

> that angular 2 should have been renamed. Didn't it? I recall it was called AngularJS when it was v1. (Yes, I'm purposefully nitpicky here, you're still right a completely new name could have been helpful here)

Nope, it wasn't. Before it was angular and angularjs, like some people say vue and vuejs Or react and reactjs. After angular 2, Angular team decided to rechristen 1 as "angularjs". But they didn't (cause couldn't) change stackoverflow and other sites content

I rest my case then.

Re: Get in zoomer, we're saving React

#218

Earlier quoted context omitted.

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…

I've thought the same thing. A tech that lets you consume data from web sites but visualize it in any way you want. Despite the naysayers in other replies I think it is possible

in the early days of web2, everyone high on RSS feeds and dreaming about pubsubhubbub ... when a google maps embed was just a few seconds and half a line of code, when OAuth1a and JSONP were all the rage, well, back then 3rd party was not a swearword and it did not automatically meant ad-fucking-track-tech.

back then it was seen as the great, bold, and messy cross-linking organically-grown future.

it was called "semantic web", every day people were announcing how simple it is to encode more and more machine-readable stuff less-and-less intrusively into your HTML or xml+atom.

then facebook became the web, twitter became the truth and one day the dream got mugged, beaten up and left to bleed out in a back alley on July 1 in 2013.

everyone got mad and posted about it on their phone using an app from a nice boring, proactively curated walled garden.

Re: Get in zoomer, we're saving React

#219

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…

desktop environments (from Windows to iOS, including OSX, macOS, KDE, Gnome and everything in between) sort of already do this. they provide services and they provide apps/programs that require those services.

what they don't provide is interchangeability of programs from different environments. probably the closest thing is the freedesktop.org semi-standards, but there's not much compatibiltiy or interoperability between KDE and Gnome stack. (KDE's Plasma needs all the usual K-things and Gnome's thing needs, well, I don't know what it needs, but it does almost nothing but needs a bunch of things to do that :D Xfce sort of piggybacks on Gnome, but also uses a lot of their own shit, but at least Xfce is great.)

basically this is due to Conway's law:

https://www.youtube.com/watch?v=5IUj1EZwpJY&t=2153s

because there's no counteracting force that's pushing back to make things use a standard :/

Re: Get in zoomer, we're saving React

#220
post #159

Earlier quoted context omitted.

No, it won't. Web is an ever changing platform, with a lot of churn. The most long lived framework currently is emberjs. But it is not the hottest, so you won't find it discussed much. The most "future proof" framework is "React" which is the one mentioned in Original article. It goes without saying but React is the cause of a lot of churn in js ecosystem, particularly due to its "no-battery included" approach. ## wh…

Which of these can be considered functional? In other words, which frameworks hvae the most function-only friendly interface?

React can be and is written in function-only style, although hooks are grossly impure.
Post reply on HN