But if you process your markup at build time into it's finished HTML, then you can host it anywhere - anytime and it'll work.
But if you process your markup at build time into it's finished HTML, then you can host it anywhere - anytime and it'll work.
and would say the bright side of the "enshittification cycle" is that we get nice places for a while and then we can move on. It's not like people party at the Mudd Club or CBGB anymore and why should they? Theory at
It'd be easy to have a world covered in ice with underwater oceans kept liquid by volcanic vents.
Chrome has plenty of problems but nobody cares because when Chrome doesn’t support something properly, no one uses it.
I agree that Safari is not perfect either. But let’s assume for a moment that nothing is going to make Apple invest more into WebKit than they are already. Which of the following worlds would I prefer?
1. WebKit remains the exclusive browser on iOS devices. The bleeding edge of the web doesn’t advance quite as quickly. A tiny number of developers who don’t already have access to an Apple device have to spend literally tens of dollars buying or inheriting 5+ year-old devices in order to test on a diversity of platforms.
2. Blink becomes available on iOS and Google continues use dark patterns to trick users into installing their browser. A small but non-trivial number of developers start assuming that everyone uses Blink/Chromium, and end users no longer have a choice of browser.
I’m sorry, I forget, isn’t the whole point about giving people a choice of browser? Because some people on Hacker News have some fairly dystopian blinders on and don’t actually care about user choice, they’re just lazy arseholes who don’t want to deal with an open web and resent having to test in more than one web browser.
Between these two alternative futures, I’ll pick number one every time, no hesitation. The open web is far more important to me than developer convenience.
The difference between Chrome and Safari not supporting features is that Safari is developed by one company (Apple) whereas Chrome is developed by two (Directly by Google and indirectly by Microsoft). So Apple can have an incentive not to add a feature and end up harming the entire industry. But if Google has an incentive not to add something, Microsoft can still add that thing anyway (and vice versa), we only need one actor to act good for their not to be harm caused.
> 1. [...] A tiny number of developers who don’t already have access to an Apple device have to spend literally tens of dollars buying or inheriting 5+ year-old devices in order to test on a diversity of platforms.
This is flat out wrong.
One Safari is not equal to another.
You need to buy one of each device because Safari will change how it works across different devices.
Example 1: Safari adds depth touch to some devices which adds weird box overlays around parts of the website while the user is trying to use it, which blocks the content and interferes with which elements are supposed to be interactable unless you add special webkit-prefixed rules (e.g. -webkit-touch-callout, -webkit-tap-highlight-color, etc...) to different parts of your pages.
Example 2: Safari adds different buffer areas around their browser which you need to test with (using the env() css function) on each device with a different screen to make sure content isn't flowing off the screen or elements are being cut off at incorrect spots when they're supposed to flow past the edge.
And so on...
Apple keeps adding device specific ways of breaking websites.
Furthermore, each device can only run one version of Safari. Every time a new version comes out, you need to upgrade your OS to get the new version of Safari. And you also can't downgrade your OS to get the older version. And because some users can't upgrade and others won't, you need multiple of each device running each one on a different version of the OS to test correctly.
We have to spend 1000s of dollars each year on new devices just because Apple keeps inventing new ways of breaking things.
-----
Side question: But what about just buying a mac and running the iOS Simulator to test different versions of Safari on different devices?
It's no good, the iOS Simulator is a simulator, not an emulator. So the bugs that are on the device are not the same as the ones in the simulator.
-----
So out of your two options, what will happen is:
Some users will switch to Blink/Chromium and find that things start working better. That will start to build up a reputation of Chrome/Edge/etc... working better than Safari.
Meaning Apple will need to invest more money and effort into improving Safari.
Meaning Safari will be improved.
So either users start migrating to a better browser, or Safari improves to the point that it isn't a problem anymore.
Microsoft got into trouble for pushing Netscape users over to Internet Explorer, but what they did isn't half as evil as the dark patterns Google is using to get Chrome and other Google apps onto the few devices left which don't have them.
It's IE6 all over again. But worse.
Safari is only available on Apple devices, Chrome is available everywhere. Let's not pretend that laziness is the only reason why Chrome has the largest marketshare.
> The point of the web is that it's an open standard. Expecting everyone to use the bleeding edge version of the most aggressively feature-laden browser isn't just unreasonable, it's counter to the spirit of the platform.
I don't expect Safari to be the bleeding edge. I just expect the features to work. Lets take for example: IndexedDB
- IndexedDB was first brought up in two propsals in 2009/2010 - IndexedDB was available for pubilc testing in early 2012 by Firefox and Chrome and was released for both browsers unprefixed in late 2012. - IndexedDB was "released" for Safari in late 2014. However:
1. The released version was so bad and buggy that it basically didn't work at all.
2. It essentially broke all the websites/web-apps that were using it, and there was no easy alternative to use. The affected websites/webapps had to essentially be rearchitected and remade or just plain shut down.
3. Apple had no interest in fixing it which essentially poisoned the feature for all developers. It was so egregious it was actually used in the lawsuits against Apple their monopolistic app store practices, which eventually led to the EU to create their new sweeping anti-trust regulation changes for app stores and browsers.
- IndexedDB didn't have a working release on Safari until mid-2016 and didn't have the industry standard "last two major version" support until late 2017.
That means we had developers affected by IndexedDB's poisoning for about 5 years.
---
So by my earlier request of "I don't expect Safari to be the bleeding edge. I just expect the features to work.", Safari completely and utterly shit the bed. They shit the bed so bad it helped lead the EU to create new anti-trust regulations.
And that was just Apple trying to meet a standard feature.
And if you thought the IndexedDB debacle was over, they broke it again. See: https://news.ycombinator.com/item?id=27509206
---
Let's not even get into Safari breaking other features. I'd rather not type all this out: https://webventures.rejh.nl/blog/2024/history-of-safari-show...
When it comes to things I am not good at at, it has given me the illusion of getting 'up to speed' faster. Perhaps that's a personal ceiling raise?
I think a lot of these upskilling utilities will come down to delivery format. If you use a chat that gives you answers, don't expect to get better at that topic. If you use a tool that forces you to come up with answers yourself and get personalized validation, you might find yourself leveling up.
Disagree. It's only the illusion of a personal ceiling raise.
---
Example 1:
Alice has a simple basic text only blog. She wants to update the styles on his website, but wants to keep his previous posts.
She does research to learn how to update a page's styles to something more "modern". She updates the homepage, post page, about page. She doesn't know how to update the login page without breaking it because it uses different elements she hasn't seen before.
She does research to learn what the new form elements and on the way sees recommendations on how to build login systems. She builds some test pages to learn how to restyle forms and while she's at it, also learns how to build login systems.
She redesigns her login page.
Alice believes she has raised the ceiling what she can accomplish.
Alice is correct.
---
Example 2:
Bob has a simple basic text only blog. He wants to update the styles on his website, but wants to keep his previous posts.
He asks the LLM to help him update styles to something more "modern". He updates the homepage, post page, about page, and login page.
The login page doesn't work anymore.
Bob asks the LLM to fix it and after some back and forth it works again.
Bob believes she has raised the ceiling what he can accomplish.
Bob is incorrect. He has not increased his own knowledge or abilities.
A week later his posts are gone.
---
There are only a few differences between both examples:
1. Alice does not use LLMs, but Bob does. 2. Alice knows how to redesign pages, but Bob does not. 3. Alice knows how login systems work, but Bob does not.
Bob simply asked the LLM to redesign the login page, and it did.
When the page broke, he checked that he was definitely using the right username and password but it still wasn't working. He asked the LLM to change the login page to always work with his username and password. The LLM produced a login form that now always accepted a hard coded username and password. The hardcoded check was taking place on the client where the username and password were now publicly viewable.
Bob didn't ask the LLM to make the form secure, he didn't even know that he had to ask. He didn't know what any of the footguns to avoid were because he didn't even know there were any footguns to avoid in the first place.
Both Alice and Bob started from the same place. They both lacked knowledge on how login systems should be built. That knowledge was known because it is documented somewhere, but it was unknown to them. It is a "known unknown".
When Alice learned how to style form elements, she also read links on how forms work which lead her to links on how login systems work. That knowledge for her went from an unknown known to a "known known" (knowledge that is known, that she now also knows).
When Bob asked the LLM to redesign his login page, at no point in time does the knowledge of how login systems work become a "known known" for him. And a week later some bored kid finds the page, right clicks on the form, clicks inspect and sees a username and password to log in with.
type UserId = `user:${uuid}`;
type OrgId = `org:${uuid}`;
This had the benefit that we could add validation (basic begins with kind of logic) and it was obvious upon visual inspection (e.g. in logs/debugging).1. https://www.typescriptlang.org/docs/handbook/2/template-lite...
But depending on the format it can sometimes be tricky to narrow a string back down to that format.
We have type guards to do that narrowing. (see: https://www.typescriptlang.org/docs/handbook/2/narrowing.htm..., but their older example is a little easier to read: https://www.typescriptlang.org/docs/handbook/advanced-types....)
If writing the check is too tricky, sometimes it can just be easier to track the type of a value with the value (if you can be told the type externally) with tagged unions (AKA: Discriminated unions). See: https://www.typescriptlang.org/docs/handbook/typescript-in-5...
And if the formats themselves are generated at runtime and you can use the "unique" keyword to make sure different kinds of data are treated as separate (see: https://www.typescriptlang.org/docs/handbook/symbols.html#un...).
You can combine `unique symbol` with tagged unions and type predicates to make it easier to tell them apart.
> We then installed Windows 11 on the handheld, downloaded updated drivers from Lenovo's support site, and re-ran the benchmarks on the same games downloaded through Steam for Windows.
Yes gamers could install Bazzite right now, but those that are open to switching away from Windows aren't going to if they don't have a large company that can fund the support focused primarily on the issues that gamers are going to experience.
He exploits bad science journalism to get his name out there.
Generally with proper science journalism, it runs along the lines of the saying: "It's never aliens, until it is", but with Avi Loebs it always tends to be "It's always aliens, until it isn't".