It's crazy how unusable most gun websites are for browsing what's available. This though is the perfect example of what I really want when browsing catalogues.
Correct, all the filtering is done locally in the browser, and the deploy is purely static.
If PSA had let me use affiliate links, I was planning to do the work to SSR in a Cloudflare Worker, but they declined and I decided to call the project where it was.
The comic artist seems pretty ignorant to think that it’s not meaningful.
What falsehoods people believe and spread about a particular topic is an excellent way to tell what the public opinion is on something.
Consider spreading a falsehood about Boeing QA getting bonuses based on number of passed planes vs the same falsehood about Airbus. If the Boeing one spreads like wildfire, it tells you that Boeing has a terrible track record of safety and that it’s completely believable.
Back to the start menu. It should be a complete embarrassment to MSFT SWEs that people even think the start menu performance is so bad that it could be implemented in electron.
In summary: what lies spread easily is an amazing signal on public perception. The SMBC comic is dumb.
It's less meaningful than you think. Widespread prejudice does give you signal on public sentiment, but it doesn't give you much signal on whether the prejudice happens to coincide with reality or not, compared to other methods. People should be open to having their prejudices corrected by more relevant information.
I worked on a business app made with lit web components and all properties being stringly typed was a real drag. It didn't compare to a realtime-first component library.
Alas, that’s a common misconception! You’re confusing properties with attributes. Attributes are set through HTML and are stringly typed, but litjs properties can be any js value.
For instance, I have a project with a small web component that displays data from a duckdb wasm connection. The connection object is passed as a property and it works flawlessly.
If you’re using it with something like React, passing attributes is easy, but setting properties is much harder, requiring using the escape hatches—I believe you’ll need useRef and useEffect, and a bit of care because it’s frightfully easy to do the wrong thing.
> Server Side Rendering: props passed to a custom element will render as attributes if their type is a primitive value like string, number, or the value is true. Props with non-primitive types like object, symbol, function, or value false will be omitted.
> Client Side Rendering: props that match a property on the Custom Element instance will be assigned as properties, otherwise they will be assigned as attributes.
> As of v19, React now uses a runtime heuristic to determine if it should pass data to Custom Elements as either properties or attributes. If a property is already defined on the element instance, it will use properties, otherwise it will fallback to attributes.
All up it sounds fragile, and I’m not fond of how JSX syntax makes properties look like attribute, and I hate the way you lose the sometimes-crucial distinction of whether something is a property or an attribute (<input value> is the most obvious example of this), but I guess it’ll be fine in practice. I’m a little curious how they handle some of the event stuff, since React’s synthetic event system is such a legacy mess. And I never did like the way several popular libraries/frameworks (definitely not just React) special-case /^on.*/ attributes, so stupid how you now can’t safely use an attribute or property named “once”, “one” or “online”, all of which would be the most sensible name in certain situations.
One of the reasons I value SetApp so much for Mac apps is that it's curated and I don't have to worry about filtering a bunch of shady or low-quality apps.
reply