HN user

FrontAid

390 karma
Posts5
Comments71
View on HN

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

React 19 2 years ago

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

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

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.

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;
    }

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.