Get in Zoomer, We're Saving React

This page summarizes the projects mentioned and recommended in the original post on

Our great sponsors
  • Sonar - Write Clean JavaScript Code. Always.
  • Zigi - Workflow assistant built for devs & their teams
  • InfluxDB - Build time-series-based applications quickly and at scale.
  • Scout APM - Truly a developer’s best friend
  • Lobsters

    Computing-focused community centered around link aggregation and discussion

  • additive-guis

    guis constructed from tuples/triples

    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.

  • Sonar

    Write Clean JavaScript Code. Always.. Sonar helps you commit clean code every time. With over 300 unique rules to find JavaScript bugs, code smells & vulnerabilities, Sonar finds the issues while you focus on the work.

  • jQuery-menu-aim

    jQuery plugin to fire events when user's cursor aims at particular dropdown menu items. For making responsive mega dropdowns like Amazon's.

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

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

  • compose-samples

    Official Jetpack Compose samples.

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




  • ng-ivy

    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 ( see the withTheme and withStyles functions )

    [1] for simple things ... see also the official working example from the docs

  • Zigi

    Workflow assistant built for devs & their teams. Automate the mundane part of your day, with live actionable messages for your GitHub & Jira tasks.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts