I like this familly of technologies. Having an SPA-type app that's mostly backend.
Recently i've redone my app website (https://alt-tab.app), and I implemented a minimal spa.js that has a similar approach. I find the end result blazing fast, simple to maintain / reason about, few moving pieces. I used Early Hints, compressed every single thing, inlined CSS, etc. I don't know how i could even make it faster.
I recommend this approach for websites that are not very complex. Of course if i made a browser-based music player with a super dynamic UI, that would have been a different story~
For those of you a similar SPA-type app with more type safety – which is even more useful for writing code with AI – you may want to have a look at the Gleam language and the Lustre web framework [1]. It combines the best of Elixir and Elm. You can mix and match having more logic in the backend or the frontend, as Gleam compiles both to Erlang and to JS.
I really wanted to like Gleam because the Rust-like syntax and static types looked familiar and robust, but seeing how Lustre does HTML templating versus how Phoenix does Heex was my deciding factor to try the latter. My understanding is this is because of a current lack of any macro system.
I probably didn't give it a fair shake, but it all looks very early days, which isn't for me. Kind of a shame, because the dynamic types are still kind of driving me up the wall in Elixir. Elixir structs and dialyzer type specs feel so much worse than what statically typed languages provide.
> but seeing how Lustre does HTML templating versus how Phoenix does Heex was my deciding factor to try the latter. My understanding is this is because of a current lack of any macro system.
When I worked with Ruby on Rails I was "addicted" to macros for everything, but after working for a while with statically-typed languages like Elm and Gleam, I see that there are many other ways to solve those same problems. The code can be quite repetitive sometimes, but as long as the compiler ensures everything is in place, it works quite well.
I think it seems logical on paper. I tried it, and it feels perceptually way worse. It also think it's objectively slower.
When you go from HTML page to HTML page without JS, the browser starts from scratch on every page. The user gets a big flash, then the browser has to redraw the page from scratch. It's actually a lot of work often.
If the browser expected pages to be similar, and added optimizations to reuse existing content, essentially doing internal SPA work, that would be a different story. To my knowledge, the browser does no such optimization, and brute-forces renders every URL from scratch.
You can actually try for yourself on the website I linked. Chrome devtools > disable Javascript. It's a pretty good experience still since I optimized everything. However, you see all sorts of things flicker and move around. It's not the smoothest experience. And If you have worse Internet, it gets worse and worse as you see more of the tear-down > built-up on every click. With the SPA experience, if you have bad internet, you can still scroll around and use the page, as you wait for the update to arrive.
Of course, you're totally right that static HTML works pretty good when the website is already simple and fast. My point was that with 4KB-uncompressed / 140LoC, I can get the smoothest experience. And I unlock options later on like having loading spinners for example.
My general point was that you can do simple client-side rendering in 140 LoC. You keep a simple backend-served website, and add a little polish this way to have a smooth experience.
I find it very cool to have polished app-like experience, while having a simple backend to serve. I like the low-tech, few moving pieces, yet I get options for great UX if I want.
I got charmed by this path with LiveView and Hotwire back in the day. I'm thankful that people continue to push this approach. It's wonderful
Static pages is basically always faster. The web browser is very, very quick at rendering HTML. Executing JavaScript is much slower. But, the real benefit of static sites is caching. You can cache on the edge and have remarkably fast load times.
For the flickering or flashing, you can just stick a couple lines of CSS for view transitions and boom, done. I understand the flashing looks less professional or fast, but it’s not actually.
> I don't really see any user defined input that would change the output.
I feel like the distinction between static websites and SPAs has been lost in the last decade, despite it being in the name _single page application_.
The point of SPAs is not "it's more interactive than a static website is", but "I don't need to fetch the new page and wait it to load as I navigate". You can have any custom behavior just by adding JavaScript. That's something we have from 30+ years.
"applications" don't interrupt the user as you navigate, and we tried to replicate that on the browser, by having history and render JavaScript controlled.
Honestly there are times when using the View Transition API makes sense, but the context here is a dinky brochure site. The weight of scripting does as much damage to first load as it saves on subsequent loads. Browsers are good enough at managing this stuff themselves.
Dude thank you for making AltTab. Recently you've introduced the pro version and paywalled some features behind it. That's totally fine and I bought the pro version but my honest 2c for you is...25 bucks for a window switcher app seems too high. Please make it 15 or less. Thanks
It seems that Fleet will support building XCode apps. It looks like a big regression from AppCode. As of today Fleet doesn't compile my macOS app. I try regularly on new updates. No alternatives, unfortunately
JetBrains already announced it is no longer targeting Fleet as its iOS strategy for Kotlin Multiplatform. Instead it will be realizing its strategy through IntelliJ IDEA and Android Studio.
This tool says "Xcode replacement" and "Xcode-free development". I thought there is no way they can build apps without Xcode. How would they replicate the libraries, compilers, etc.
I dug more and of course they don't: "Though we don’t rely on the Xcode build system, you still need to install Xcode for the iOS SDK and toolchain"
I think they should clarify their messaging. This is not a replacement or an alternative. It's a layer on top designed for what they think is a better experience.
I think you are mixing some different concepts here. It's not that this is a layer on top of Xcode/xcodebuild, it's just that Apple today happens to package everything iOS/Swift-related together with Xcode releases. So even if you couldn't care less about the Xcode IDE itself or the xcodebuild build system, you still need to have it because this is the only way for you to download / install those toolchains. Apple could provide these separately, but they just don't.
xtool creator here, this is correct. it wouldn’t have been possible to support Linux if xtool was just a layer on top of Xcode, as Xcode doesn’t run on Linux.
we only need Xcode to be installed on macOS since it bundles the iOS SDK (ie all the header files.) similarly, we ask the user to supply a copy of Xcode.xip during the setup process on Linux in order to extract the SDK.
it definitely depends on your definition of “replacement” in the end, but I (and most people I’ve spoken with in the iOS community) would consider “Xcode” to be the Xcode build system, user interface, and proprietary tooling. xtool doesn’t rely on any of this, not even for signing and installation. you can (read: must on Linux, may on macOS) use it with the open-source Swift and Clang toolchain + LLVM’s LLD linker and MachO tooling. Codesigning uses zsign, an MIT-licensed x-platform codesign alternative, and installation relies on the open source libimobiledevice project, which is installed by default on many Linux distributions (eg Ubuntu).
I've been developing a fairly popular macOS app for years. I consider myself in the community for that reason.
Apple has bundled everything together in a big mess.
- Only certain macOS versions can run certain XCode versions
- Only certain XCode versions contain certain SDK versions
- XCode embeds "Command line tools" which contains things like gcc, ruby, python, installed as a package, and conflicting with other versions on the machine
- Interface Builder is built into XCode and has its own compatibility story
It's a big messy blob and you can't pick-and-choose parts. You have to update your whole machine to move to the latest OS so they will let you run the latest XCode, so your app can compile on the latest platform for your users. It's not the best experience for sure. Many ecosystems have SDKs that you can download as you wish. I don't need to update my OS to download a version of the JDK for example.
That being all said, if you require users to download XCode, regardless of which part of it is necessary, i don't think you should mention "XCode free experience" or "XCode replacement".
I'm already developing a macOS app without launching the XCode GUI. I use the xcodebuild CLI that ships with XCode. My IDE is AppCode. I also use xcodebuild on CI to build the app headless. I would never call that a XCode free experience though, as i suffer from all the issues i mentionned above with version upgrades and XCode issues
I'm not too familiar with the xcode dev environment; could Theos be used instead of the huge xcode bundle? As far as I know, it provides the compilers and frameworks directly.
When you use Theos outside macOS, you have to install a toolchain and SDK. The toolchain is built from LLVM + cctools, and is in fact very similar to the one we use in xtool (I maintain both.) The SDK is hosted on GitHub and I could’ve decided to use this instead of getting the user to supply a copy of Xcode, but the copyright status is iffy; there’s an argument to be made in light of Google v. Oracle but I didn’t want to take any chances.
Would it be possible to get just the SDK from the Xcode package? Like Asahi installer streams only the relevant parts of macOS images from Apple’s servers.
I looked into streaming but afaict the XIP format doesn’t support random access the same way that ZIP does. specifically because 1) it doesn’t seem to have a Central Directory like ZIP and 2) it has an optimization where files can be hardlinks to other files (by ID) in the XIP, so if you want to extract a file but all you get is a hardlink ID, you can’t expand the contents until you encounter and expand the hardlink pointee. it’s possible I’ve missed something, open to ideas for sure.
I do have an idea that will add a lot of complexity for sure: you can extract Xcode, mapping out whick portions of the archive correspond to the SDKs we need, then use this mapping to only download these relevant parts, reconstruct the archive and expand it. Not sure if it’s worth it!
But that's wrong. You don't need macOS. That's why they say "cross-platform Xcode replacement". You just need the SDK, which can be used on every platform.
IIRC, you need to run on Apple hardware for a valid SDK license. VM or Asahi or Hackintosh would suffice, but not a VM on a random Linux box. Or did the terms change lately?
Domestication is often thought of as a unilateral relationship. Like all relationships, it goes both ways.
We have domesticated cows and wheat. Now their population has reached tremendous size. So has our population. We both need the other species to survive. We need them, and they need us.
You could definitely take the perspective that we have been domesticated. For example, plants have domesticated us by feeding us.
I'm the author of AltTab (https://alt-tab-macos.netlify.app/), a popular window switcher for macOS, imitating Windows famous alt+tab shortcut. I know for a fact how hard it is to implement what you did. It looks very nice, well done!
I see you ran into the issue of not being able to detect windows from other Spaces. Apple introduced it in macOS 12.2. If you're curious, you can see the vast efforts we've deployed trying to find a workaround: https://github.com/lwouis/alt-tab-macos/issues/1324. I wish some retro-engineering genius would solve this. We haven't been lucky so far. Of course Apple could fix this all in an instant with a new API, but that's very unlikely to happen.
I am an occasional alt tab user and it is a great product. Thanks for building it. I am reasonably used to MacOS window management behavior but I still need something like alt tab once a while, that’s why it keeps running in the background.
I also really appreciate the partnership and open attitude your comment above demonstrates, and that to a potential‘competitor’.
Are you familiar with the change Apple made to app stack ordering where cmd+h no longer deprioritizes the window resulting in the wonderful cmd+h cmd+tab agghhhhhh cmd+h cmd+tab cmd+tab rage fest I haven't been able to stop inflicting upon myself every three seconds for years? I have yet to find a third-party app that fixes this. :)
This is what I don't understand. Ok apple does not care or does not want to spend resources on the window management mess of MacOS for whatever reason (iOS is more important, MacOS does not bring services revenue etc)
Just open the API for the 3rd party developers to fix your mess!
Coincidentally, after 10 years, and 100 releases of 0.9, HammerSpoon just released 1.0 in August 2024:
Hammerspoon is a bridge between the operating system and a Lua scripting engine. What gives Hammerspoon its power is a set of extensions that expose specific pieces of system functionality, to the user.
You can write Lua code that interacts with macOS APIs for applications, windows, mouse pointers, filesystem objects, audio devices, batteries, screens, low-level keyboard/mouse events, clipboards, location services, wifi, and more.
Working harder at something will create better outcomes. There is a lot to think about, mitigate, deal with. The more time you put on something, the better the results.
For example, your crops are getting attacked by insects. It's exogenous yet if you wake up in the night to come out and kill them, you'll save more crops.
I'm genuinely wondering how our nose is not a good enough sensor. Are there common cases that affect large areas like the one you live in, where the pollution is not smellable?
I never could smell the pollution in Bangkok. I don't think people in LA could smell the smog. Certainly when we had wildfire smoke here near Seattle a couple years ago, I could not always smell it. Sometimes when it was heavy, you could smell smoke right when you went outside, but not always... and your nose gets used to it really quickly. But like, that was pollution you could see, the skies were dark and orange. Not really typical pollution levels that people live in every day.
Recently i've redone my app website (https://alt-tab.app), and I implemented a minimal spa.js that has a similar approach. I find the end result blazing fast, simple to maintain / reason about, few moving pieces. I used Early Hints, compressed every single thing, inlined CSS, etc. I don't know how i could even make it faster.
I recommend this approach for websites that are not very complex. Of course if i made a browser-based music player with a super dynamic UI, that would have been a different story~