FrontAid

There are many options, each with their own pros and cons. Also, you may or may not like their default styling and/or styling options. There is no one size fits all. Having said that, we maintain an incomplete list of popular UI libraries here:

https://frontaid.ch/web/ui/libraries.html

Dashboards, tabs, trees, ... usually require at least some JavaScript to work properly. For some components, you may be able to use hacks around that. But I would generally not recommend that outside of experimentation. So a pure CSS framework is not going to work. It seems that you are not using a frontend framework like Vue.js. So I would recommend a library using web components for the interactivity. One good option is Shoelace [1] and there are a couple of others, too [2]. Take a look at the ones with the checkmark in the "W" column for libraries with web components.

[1] https://shoelace.style/

[2] https://frontaid.ch/web/ui/libraries.html

> specifically UI libraries

There are certainly more UI libraries available for React than any other framework [1]. But do you think that these are also clearly better? What would be your go to framework for React? To me, it seems that the trend is going to framework-agnostic or multi-framework libraries anyway (e.g. Ark UI or Zag).

[1] https://frontaid.ch/web/ui/libraries.html

Hi there. We create FrontAid CMS as another headless, Git-based CMS like Tina. And we integrate directly with Uploadcare. You can find more information here:

- https://frontaid.io/

- https://frontaid.io/docs/integrations/

Yes, that's it. Judging from the screencast, I will continue using lazygit for that though. Not a fan of all the clicking. Hopefully there will be a keystroke available for it.

I don't know Rider, but I assume this is a limitation in all of their IDEs. Yes, you can commit only certain changes within a file. But you can only do that based on whole chunks. For example, if you add two new lines at the end of an existing file, you cannot commit only one line but not the other. The same limitation applies to changelists (at least in IntelliJ IDEA and Webstorm).

I use IntelliJ IDEA and often rely on their own Git functionality. But it cannot stage specific lines, only whole chunks [1]. For that, I've been using lazygit for a couple of months now. I like its simple UI and that it makes staging specific lines very easy and quick. If you like lazygit, you might also be interested in similar Git CLI clients that I collected here [2].

[1] https://youtrack.jetbrains.com/issue/IDEA-186988/Allow-commi...

[2] https://github.com/frontaid/git-cli-tools#clients

Ask HN: How did you increase your UX skills?

https://news.ycombinator.com/item?id=32147968

Can you make an example of features/styles that have been replaced? I'm not really sure what you mean by that.

No. The former imports all the exports, and the latter imports the default export only.

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

More or less what CrowdView does.

- https://news.ycombinator.com/item?id=34507965

- https://crowdview.ai/

> Similar to the Do Not Track header, a Accept Cookies header?

Do not track can do that, it has three possible values.

    0: The user prefers to allow tracking on the target site.
    1: The user prefers not to be tracked on the target site.
    null: The user has not specified a preference about tracking.

Source: https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/DN...

The problem is that DNT is mostly ignored, and also deprecated by now.

Same in Switzerland. There is even a remake/adaption in Swiss German https://www.youtube.com/watch?v=JNJrprqPVns but I like the original way more.

> I want access the RSS of NYT, where I find it?

https://www.nytimes.com/rss

Unfortunately, almost all of them are terrible for accessibility. Most of them cannot be focussed by keyboard. And even more do not have a focus styling. I did not check their code, but that alone does not make a good impression.

Please consider accessibility when you have the urge to build custom (form) components. For checkboxes, have a look at https://www.w3.org/WAI/ARIA/apg/patterns/checkbox/ for some guidelines.

Very interesting! I had a look at your "RFC 001: Core Architecture" but one question remains. You mentioned "git as the backend". As far as I understand, you don't use the word "backend" in the classic frontend <=> backend sense. Instead, you mean that Git is being used as a software repository and as a content database. Is that correct or am I missing something?

I'm already sold on the idea of using Git as a database for content and localization. But I'm obviously biased as we are working on a similar solutation ;) It is called FrontAid and it is a CMS that stores your (localized) content in a JSON file within your own repo. More information can be found at https://frontaid.io/

Using Git for content has some great benefits. Like complete version history, easy reverts (for devs at least), (feature) branch support, Git hooks, ... And of course, you own your content at all times.

PS: Both the "Editor" and "VS-Code-Extension" links in your repo are broken.

If you are considering switching to a (different) date library, I would suggest to hold off. ECMAScript is about to introduce a native date and time API that is much better than the current Date functionality. It may also make the need for a third-party date library obsolete (as long as you do not need to parse custom date formats).

- https://github.com/tc39/proposal-temporal

- https://github.com/tc39/proposal-temporal#polyfills

- https://tc39.es/proposal-temporal/

- https://tc39.es/proposal-temporal/docs/index.html

- https://github.com/tc39/proposal-temporal/issues/1450

- https://tc39.es/proposal-temporal/docs/parse-draft.html

As far as I know, issue #1450 is the last remaining blocker for the standardization. I'd assume that this will be resolved in the next months. So Temporal will likely be officially released with ECMAScript 2023, but browser vendors and other implementors will start shipping it before the offical release.

The article already explains that thoroughly.

Another similar gotcha is that the global-scoped `name` variable must be a string. See https://developer.mozilla.org/en-US/docs/Web/API/Window/name for details.

    var name = true;
    typeof name; // "string", not "boolean"

Luckily, this is not true within ES modules which you probably use most of the time anymway.

Au contraire. That is good question. Everything in the snippet except the font-size should also work with the body selector. The font-size is an exception here as it defines the root font size that the `rem` unit is based on. And that has to be defined on html.

https://css-tricks.com/html-vs-body-in-css/

> I wonder if everyone has a different optimum here based on different eyesight, screen size, and usage patterns. I always have a slightly different zoom on every website I visit.

I would think so. And because of that, accessibility is an essential topic. Luckily, this snippet will automatically follow your zoom level and/or font size settings.

I think this does not work well for mobile devices. Spacing and the font size is too large. Hence, a lot of screen space is wasted and the user has to scroll more. Larger font sizes on mobile are usually not a good idea as the device tends to be closer to your eyes anyway.

A snippet that could work better in my opinion is the following:

    html {
      max-width: 70ch;
      /* larger spacing on larger screens, very small spacing on tiny screens */
      padding: calc(1vmin + .5rem);
      /* shorthand for margin-left/margin-right */
      margin-inline: auto;
      /* fluid sizing: https://frontaid.io/blog/fluid-typography-2d-css-locks-clamp/ */
      font-size: clamp(1em, 0.909em + 0.45vmin, 1.25em);
      /* use system font stack: https://developer.mozilla.org/en-US/docs/Web/CSS/font-family */
      font-family: system-ui
    }

    /* increase line-height for everything except headings */
    body :not(:is(h1,h2,h3,h4,h5,h6)) {
      line-height: 1.75;
    }

The changes in this edition of ECMAScript can be found at the end of this table (everything with "2022" in the last column):

https://github.com/tc39/proposals/blob/main/finished-proposa...

The ECMAScript 2022 specification can be found here (warning: large document!):

https://262.ecma-international.org/13.0/

You can have a look at https://github.com/troxler/awesome-css-frameworks which is an extensive collection of CSS frameworks. Check out the "Class-less" section for similar projects.

There is also an open PR to add Simple.css to the list: https://github.com/troxler/awesome-css-frameworks/pull/85

This issue currently blocks shipping Temporal support without a flag:

https://github.com/tc39/proposal-temporal/issues/1450

Not sure where you got that quote from, but FLWOR is not something JSONiq invented.

- https://en.wikipedia.org/wiki/FLWOR

- https://www.w3.org/TR/xquery-30/#id-flwor-expressions

FLWOR is pronounced 'flower'.

I did see the commits, but the last release was almost three years ago. That is not necessarily bad. I was just wondering whether it still works well or there are any quirks.

It does not really seem to be maintained anymore. Is there any downside because of that?

neogit is "magit for neovim". It is written in Lua. Did you already know the answer to your question? ;)

https://github.com/TimUntersberger/neogit

Similar Git tooling can be found in https://github.com/frontaid/git-cli-tools

bit (https://github.com/chriswalz/bit) is a somewhat similar CLI tool for this. It shows command completion alongside a description.

PS: We maintain a list of helpful Git CLI tools on https://github.com/frontaid/git-cli-tools