There is functionality to reopen the last closed window, and also a keyboard shortcut for it. IIRC, the shortcut is Ctrl+Shift+N (on Windows and Linux).
Yes, it is a saving grace and I do use it in case of accidental closure. However, the workspace feature avoids having to manage multiple windows and generally feels snappier because it doesn't have to load/show all the windows at startup. Coupled with shortcuts to switch workspaces, it just feels more organized.
> How do you test on Safari if you don’t have Apple devices?
How do you test a Playstation game without a Playstation (dev kit)? How do you test some hardware firmware without having the hardware? How can you run a program without the hardware required to run the program, if no emulator/simulator is available?
I'm almost lost at words how these are questions, unless they're theoretical and some diatribe comes afterwards that has the actual point trying to be made, but it never came.
Yes, some things run only on specific hardware and without virtualization/emulation, you're not supposed to test those things outside of the hardware. Been a thing for decades, probably since the beginning of computing.
> How difficult can it be for Apple to make barebones virtual machines with just Safaris?
Almost nothing Apple does is seemingly decided by how difficult it is, for better or worse, but are strategic decisions. If you haven't caught up with that they're building a walled garden for themselves, I'm not sure what could convince that they are. I think this is extremely clear for most people. If you don't like it, don't play there, like the rest of us.
I don't think it's fair to compare development for web, which is supposed to be an open standard, with developing for a proprietary piece of hardware like the Playstation.
If you want to develop a game for the Switch and ignore the Playstation entirely, you can, and then you don't need a Playstation (dev kit).
When you're developing for the web, you're ideally making something that runs regardless of the user's browser. When you start getting bug reports in from Safari users, how else are you supposed to fix them? Cheapest option is detect if they're a Safari user and tell them to use another browser, but that's not really ideal for anyone except Google.
If you're developing for the web and you're not testing you're site on real hardware, including a handful of iPhones and a handful of Android devices, your not actually testing your software.
You can't just check Chrome and assume everything else will exhibit the same behaviors. Standards exists, but so do bugs.
Having access to a representative spread of devices is the reality of web development. As a web developer that doesn't own any Android devices, I was "forced" to buy a couple of Android devices so that I could squash bugs (some of which couldn't be replicated in emulators) and to refine aspects of the physical touch experience that emulators cannot emulate. I don't resent these purchases, because I understand it's the reality of developing for a diverse open web.
And yet, oh how often I hear developers resent having to buy an Apple device. Every time, I look at my little stack of Android devices and instinctively roll my eyes.
> Cheapest option is detect if they're a Safari user and tell them to use another browser
I suppose the cheapest option for me was to detect if they're an Android user and tell them to use another device. It sounds silly to say it — it is silly to say it — but that's exactly the same logic.
A lot of folks want to run tests off a GitHub action I.e. on a server somewhere.
Ideally you want your test stack to fit in a docker image. So this does suck for developers in the respect and you could imagine apple releasing a special docker image that just ran safari if they wanted to really make it easy to develop for thier platform.
However, I imagine someone will fill a server rack with cheap old macs and offer and safari mcp as a service…
> A lot of folks want to run tests off a GitHub action I.e. on a server somewhere.
Understandable, but also if you're dealing with these sort of projects, you kind of have to setup that sort of automation yourself in an office/someone's house, unless you find some provider that already hosts that sort of thing, like the various Apple/vendor-specific services for that.
It's also not a very new thing really, MacStadium for example been around since like 2010 sometime.
I have multiple Playwright webkits on both Windows and Linux. I have Epiphany on Linux (not 100% same webkit). I have subscriptions for testing on real hardware.
This is why it seems to me that Apple does not really care about web developers.
No way, is Orion Browser available on other platforms as well now? Does it mean I can finally do tests for Safari (webkit) without owning an Apple product or paying for a vm? Incredible.
### THIS FILE IS AUTOMATICALLY CONFIGURED ###
# Changes to this file will not be preserved.
# This file will not be recreated if removed.
X-Repolib-Name: Microsoft Edge
Types: deb
URIs: https://packages.microsoft.com/repos/edge-stable
Suites: stable
Components: main
Architectures: amd64
Architectures: amd64
Signed-By: /usr/share/keyrings/microsoft-edge.gpg
First, the Microsoft browser these days is Edge, not IE. IE is dead.
Second, if you want, or wanted in the past, to test on Internet Explorer without a Windows computer, you could just virtualize Windows. Windows can be legally virtualized on any hardware and on any host operating system.
Starting from 2013, you didn’t even need to pay for a Windows license to do that:
Are seriously asking with a straight face? Just do what a generation of people have done with Windows and run an unlicensed version of macOS. There's a whole generation of people who can recite Windows product keys off by heart. (FCKGW, anyone?) Entire empires of indie web development will have been done on improperly licensed versions of Windows.
As for people working in a serious professional corporation that cannot condone casual piracy, buy a Mac mini and expense it, or get an account on MacStadium.
The owner of whirlpool.net.au commenting on my comment.
I am replying because of the huge respect I have for the work.
Yes, I am seriously asking with a straight face.
Yes, I know how to pirate. I’m from this planet. :-D
Pirating, and jumping through hoops to do things certain vendors didn’t want done, was fun while I was learning. And educational. Super educational, in many respects.
But it is not fun anymore for me. There are other things these days that can get me banging my head against walls, and they are, in total, more fun and more educational.
My point is only that testing on any non-free platform involves jumping through non-free or non-legal hoops. Testing on a variety of platforms/clients shouldn't be considered a chore. It's a necessary part of having a truly open, truly free web. Don't complain that you have to buy an Apple device. Say thank you. Seriously.
Diversity — not choice — is what keeps the web truly open and truly free. Enforced diversity sometimes sucks for the individual but necessary for the healt of the ecosystem. The "choice" of Chromium everywhere isn't a choice, it's forcing everyone into a monoculture. When everyone is expected to use one browser engine, the open web is dead.
Because it cannot run Chromium, Safari on iPhone is the last refuge of the truly open and truly free web. Steve Jobs might be known for many things, but I think he's under-appreciated as a two-time saviour of the web; first by destroying Adobe Flash[0], and second by ensuring that one web browser couldn't dominate on all platforms.
[0] To this day I am utterly stunned that anyone in a community like Hacker News would think it acceptable that a significant chunk of the web was under the thumb of a proprietary, closed source binary blob. The death of Flash was necessary, righteous, and overdue.
I love Vite, when I don’t forget it exists in my projects. It took things that made you feel mentally deficient and made them almost zero-config.
This news does not make me happy.
Same with the news about Astro earlier this year.
I know it must be good for the people how have made the projects (why else would they chose to do it?) but there is something in those acquisitions that makes me uneasy.
> I know it must be good for the people how have made the projects (why else would they chose to do it?) but there is something in those acquisitions that makes me uneasy.
Same, kind of conflicting. Happy for the individuals involved, they've probably more than earned it. Slightly sad about what comes next, as I'm guessing both you and me seen this happen so many times before, and we've learned to read past the always-reiterated "Nothing will change, everything keeps on being great forever".
I've loved Vite from the moment it was public. I also tried Snowpack back in the day. (fun story that Fred "fks" went on to create Astro after Snowpack didn't gain traction). The fact that we can "just forget it exists" is a major win in my case. Webpack - while maybe a win over Grunt/Gulp, was MASSIVELY complex.
I too am a bit uneasy. It's not always the case but, corporate ingestion is often where cool projects go to die. The good news about open source is that we have enough Terraform->OpenTofu & Redis->Valkey stories out there.
Having used Webpack since 2016... Vite was amazing. Few years ago I migrated a rather complex project (monorepo with a Rust wasm binding) from Webpack to Vite (before the LLM days!) and dev builds and real builds went from minutes to seconds. I never looked twice at Webpack ever again.
I don't know what to feel about this news, especially since migrating to from vite 7 to vite 8 broke my project in ways that were not documented, but I'm remaining cautiously optimistic.
Migrate off vite to what exactly? I just migrated a personal project to vite and it simplified the existing webpack thing drastically, I was very impressed.
IDK, I've been purposely limiting the scope of work I can provide by only working with js, html, css. It's extremely limiting but when it comes to basically making one-off splash pages it's nice to not worry about tooling and just deploy what I made instantly. Modern CSS is amazing, there's no need to use sass or postcss. The modern web APIs are amazing as well. You can get a lot done with new base standard across browsers. The only libraries I really pull in nowadays are anime.js + umami for analytics.
I don't even need TS and can get away with js doc annotations + a functional LSP allows me to be slightly more dangerous (think running with scissors in chain mail).
Maybe if you need a specific web app you can reach for the complex tooling but even then I still wonder if it's necessary? The most popular political tool I've shared was a simple HTML page that just fetched the census API for specific codes in a tabular format. Sure I could have used react which would have enabled me to unlock some future value I couldn't foresee at the time but the working alternative is that I have a single html page with minimal JS (around ~2k LOC) that a surprising amount of nontypical devs (think carpenter that is interested in cybersecurity or union negotiators) are able to extend by themselves for their own needs (think adding census codes about snap or public transit).
There is a tremendous amount of value in telling my users how they can modify the source code and see the immediate impact of doing as much.
If this was a project that would have necessitated vite the first thing I would tell them is to install nodeJS and that's where I would lose 99.9999999999% of my users being able.
These projects will never go beyond 500,000 visitors and a CDN is more than sufficient for 90% of the work I do. So that obviously plays a major role but if this is a solo project there are much better choices to make if you want it to be sustainable + low upkeep. Those two qualities are something we as an industry should always value as it makes all our jobs collectively easier.
What alternative ending do you prefer? Personally I think acquisition is preferable to dev burnout due to lack of funding and/or extractive practices from other companies.
I'm not the one you replied to, but a typical config & plugins stack for (webpack + eslint + prettier) is nearly impossible to reason about. VoidZero's tools (Vite + oxcfmt + oxclint) are radically simpler and more performant.
> a typical config & plugins stack for (webpack + eslint + prettier) is nearly impossible to reason about.
I think people just don't want to bother. They don't want to read the docs, or maybe watch a video or two (back when webpack was popular, Sean Larkin, webpack evangelist, made a number of popular courses about setting it up). Also, webpack config became easier compared to 2014/2015; I think they got to practically a zero-config by default.
I can understand that people don't want to care; but "impossible to reason about" is not it. It isn't rust, for crying out loud; nor lisp; nor haskell.
That’s not a dig at webpack: Those tools are super complex, and hiding complexity from the user is not easy. But it seems that with Vite we finally got there.
Even if the code was written by author, not bothering to remove co-signed-by part from the commit message (assuming author did indeed wrote it by himself) let alone not writing their own commit message is an indication of negligence to me
Some of the stuff we have been adding since then is GOOD though.
Some examples:
We now have to accommodate all types of user agents, and we do that very well.
We now have complex navigation menus that cannot be accessible without JavaScript, and we do that very well.
Our image elements can now have lots of attributes that add a bit of weight but improve the experience a lot.
Etc.
Also, things are improving/self-correcting. I saw a listing the other day for senior dev with really good knowledge of the vanilla stuff. The company wants to cut down on the use of their FE framework of choice.
I cannot remember seeing listings like that in 2020 or 2021.
PS.
I did not mean this reply as a counterpoint.
What I meant to say is, even if we leave aside the SPAs that should not be SPAs, we see the problem in simple document pages too. We have been adding lots of stuff there too. Some is good but some is bad.
> We now have to accommodate all types of user agents, and we do that very well.
Simple websites don't even care about the UA.
> We now have complex navigation menus that cannot be accessible without JavaScript, and we do that very well.
Is there an actual menu which is more than a tree? Because a dir element that gets rendered by the UA into native menu controls would be just so much better.
Websites do care about the UA. They don’t care, at least most don’t care, about the User-Agent string. That is different.
About an element that gets rendered into native menu controls, I am not sure. I haven’t been following closely for the last two or three years. But that seems like a good candidate for a native element. 9 out 10 websites need it.
Firefox could (should?) be better in several aspects but it seems excessive to say it is pretty irrelevant.
It has 4.5% market share in Europe, 9% in Germany (statcounter numbers).
It is the browser that got the Google Labs folks to write a Rust jxl decoder for it, and now, thanks in part to that, Chrome is re-adding support for jxl.
You can be unhappy with Firefox (I often am myself), and Firefox HAS lost relevance, but can you really say it has become pretty irrelevant?
It is an idea I started playing with when custom properties landed in browsers, around 2016 or 2017? Around 2021 I started using the technique in client sites too.
Now I want to write a 2026 version of the post that talks about container queries too. The technique becomes more powerful if you can rely on container queries and on the cqw unit. (You cannot always. That stuff is still new.)
For an example of the convenience cqw offers if you can rely on it, see the snippets I have in this:
I don’t believe resips will be with us for long, at least not to the extent they are now. There is pressure and there are strong commercial interests against the whole thing. I think the problem will solve itself in some part.
Also, I always wonder about Common Crawl:
Is there is something wrong with it? Is it badly designed? What is it that all the trainers cannot find there so they need to crawl our sites over and over again for the exact same stuff, each on its own?
Many AI projects in academia or research get all of their web data from Common Crawl -- in addition to many not-AI usages of our dataset.
The folks who crawl more appear to mostly be folks who are doing grounding or RAG, and also AI companies who think that they can build a better foundational model by going big. We recommend that all of these folks respect robots.txt and rate limits.
> The folks who crawl more appear to mostly be folks who are doing grounding or RAG, and also AI companies who think that they can build a better foundational model by going big.
But how can they aspire to do any of that if they cannot build a basic bot?
My case, which I know is the same for many people:
My content is updated infrequently. Common Crawl must have all of it. I do not block Common Crawl, and I see it (the genuine one from the published ranges; not the fakes) visiting frequently. Yet the LLM bots hit the same URLs all the time, multiple times a day.
I plan to start blocking more of them, even the User and Search variants. The situation is becoming absurd.
Well, yes, it is a bit distressing that ill behaved crawlers are causing a lot of damage -- and collateral damage, too, when well-behaved bots get blocked.
I compare PNG and the four modern formats, AVIF, HEIF, WebP, JPEG XL, on tasks/images that PNG was designed for. (Not on photographs or lossy compression.)
It seems like the natural categories are (1) photographs of real things, (2) line art, (3) illustrator images, (4) text content (eg, from a scanned document).
Is there a reason you used only synthetic images, ie, nothing from group 1?
The motivation behind the benchmarks was to understand what are the options today for optimizing the types of image we use PNG for, so I used the same set of images I had used previously in a comparison of PNG optimizers.
The reason the set does not have photographs: PNG is not good at photographs. It was not designed for that type of image.
Even so, the set could do with a bit more variety, so I want to add a few more images.
