Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I wrote a GUI framework that uses React API directly.
It's more proof of concept than useable, the idea is that we don't actually have to write layouts, we can just describe the layout with code or a template language and let the computer work it out.
>So what exactly did we lose? It's quite simple: by moving software into the cloud and turning them into web-based SaaS offerings, many of the basic affordances that used to be standard have gotten watered down or removed entirely. Here are some examples:
>Menus let you cross over empty space and other menu items, instead of strictly enforcing hover rectangles.
I met the guy who implemented that feature, Frank Leahy, when I was working on a project with Current TV. He rewrote the Menu Manager for Mac SE and Mac II. We were reminiscing about how great the original Apple Human Interface guidelines were, and I mentioned how it actually documented that subtle feature, and he told me he was the one who implemented it, and that he was touched that somebody actually noticed and appreciated it as much as I did.
https://bjk5.com/post/44698559168/breaking-down-amazons-mega...
https://news.ycombinator.com/item?id=17404401
DonHopkins on June 26, 2018 [–]
The comments are actually great -- even Tog weighs in! It also mentions Frank Lehey, who rewrote the Menu Manager for Mac SE and Mac II.
Jake Smith • 5 years ago This was first implemented by Apple's HID team back in the 80s, specifically Bruce Tognazzini, I believe.
Bruce "Tog" Tognazzini Jake Smith • 5 years ago Yes, I did invent it back in 1986 and it is firmly in the public domain. From what I remember, it was Jim Batson who worked out the math and coded it for the Mac OS. The OS X team later failed to copy the algorithm, so I am happy to see that amazon has resurrected it.
Josh Davenport Jake Smith • 5 years ago I think it was yes. It looks like it was originally implemented by NeXT and then removed by Apple when they bought NeXT. Tog himself talks about what happened here: https://www.asktog.com/columns/022DesignedToGiveFitts.html in the answer to question 6 - "When I specified the Mac hierarchical menu algorthm in the mid-'80s, I called for a buffer zone shaped like a <, so that users could make an increasingly-greater error as they neared the hierarchical without fear of jumping to an unwanted menu...........Sadly, the NeXT folks, when coming to Apple, copied Windows, rather than the Mac"
markr_7 • 5 years ago Can't comment on the HID team, Bruce, or possibly the many times it was even implemented at Apple, but as a young developer at Apple in the 80s, I remember stopping by Frank Leahy's office as he was tweaking his code to get menus to "work right." I've often recalled the experience because of the time he was spending to get it right, and how the behavior wasn't simple once you started really trying to meet a users expectations. If I remember right it wasn't just the direction, but also time and therefore velocity. For example, you wouldn't want to stick with the wrong menu if the user wasn't really moving with purpose in the direction of the sub-menu.
"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/
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...