Cool, I often use grid for precise placement of items even for small widgets like toggle buttons.
If you’d like an intro into grid:
341 karma · joined November 27, 2019
If you’d like an intro into grid:
Every vertical line is a dom element.
I was considering moving to GPU rendering as the dom approach can take a long time to re render on changes.
Is this from the SQLite developers?
Do you filter them? What does the system you are watching do?
I have many systems that log in this format but are quite hard to visually scan during development. I typically create ad hoc filters using jq, rg or a js script.
Nice tip thanks
Gives you quite a granular time reference but not too fine like days.
I usually have a ./sh directory which is like my "control panel" for the project, then I run ./sh/deploy.sh from the root which builds and does a `firebase deploy`.
Firebase handles HTTPS and seems to have the lowest latency of the CDN's I have tried, even though they all claim to be the "fastest".
I prefer to have a explicit "button" to deploy rather than working with git commits.
It becomes harder when any one of your distributed event loops can be closed/shut down at any time (e.g: content script, service worker, options page).
Chrome Extensions with the newest "manifest v3" do not have persistent "background pages" any more, but have "service workers" that Chrome will terminate every 30s.
This makes sense, CSS layout is computed with logical rules/programming.
I think the “illogical” reputation comes from people not knowing which rules apply. They cannot see how the current layout output was calculated by the given css properties.
This is due to CSS being backwards compatible and constantly adding new ways to do things. But you can choose to use the “good parts” of the language as Douglas Crockford would say (for JS).
Also many people assume CSS would be easy and brush off that it requires a bit of effort and practise to learn the language.
I created an interactive grid explainer here if anyone is interested, I think grid is one of the good parts.
I used to use events just like this, but once the app gets bigger it’s hard to keep track as the event keys are strings. There is no IDE support for tracking usage (functions and class properties allow jumping to and from usage).
Also MobX tracks dependencies based on reads and auto re-renders changed components. This replaces having to hook up event receivers manually to re-render.
I think there are newer mobx state management systems nowadays (Signals is the new term).
- CPU features and system calls. Native code can leverage specific CPU features to gain performance. It has access to files and the network via OS system calls. Code compiled to WASM runs inside the WASM sandbox. It makes code slower. Getting data to/from the WASM code is harder.
- The WASM engine is right next to a “good enough” alternative (JS).
It’s whisper in the browser using WASM with an transcription annotation Ui.
Take a look: https://stay100.app
- You can align things in 2D space, not just along a single axis (like flex). Great for the top level layout of a site/UI.
- You can have white space. I often create white space (empty grid cell) in my UI so I can add UI elements there if needed later on. Works well with elements that are conditionally rendered, as these will change flex layouts but elements assigned to a grid cell will not move.