Not HTMX but Alpine.js has been a complete revelation to me. What clicked for me was that you're enhancing server-rendered HTML, not replacing it. Need a dropdown menu? Add x-data="{ open: false }" and you're done. Want to show/hide elements? x-show does exactly what you expect etc.
Same here, using Alpine.js is a breeze and it made working on frontend fun again, everything is so easy and intuitive to implement and manage, even on large projects. It's definitiely my favourite frontend framework right now and a default for new projects.
I worked on a large commercial AlpineJS app and grew to really, really hate it. It's great for smallish projects where the limits of the tool are known, but it is in no way a drop-in replacement for something like React (and I am no fan of React). People like to throw around how easy it is to do basic things, but building a real app using Alpine is an absolute nightmare.
Alpine data objects can grow to be quite large, so you wind up inlining hundreds of lines of JS as strings within your HTML template, which often limits your editor's ability to do JS checks without additional config.
State management in Alpine is implicit and nested and not a serious solution for building commercial apps IMO.
And don't even get me started on unsafe-eval.
If it's your hobby app and you are the developer and the product owner, go for Alpine. If you're working at a company that is asking you to build a competitive web product in 2025, use a more robust tool. Hotwire and Stimulus has scaled much better from an organization standpoint in my experience.
Have you tried the CSP build of AlpineJS? It takes the code out of the template into a proper JS file, no unsafe-eval. Isn't state management mostly handled on the backend when you use AlpineJS?
On the contrary, I've built some very complicated apps with Alpine and it handled the use cases every time. You are right with string methods creating it hard to click to go to the function in your IDE, but I'vd never had a problem with state management. Perhaps it depends on the setup.
20 years ago (well, 25) it was actually more common than it is now - many computers in the late 90's to early 2000's came with video capture cards built in. The Sony VIAO for example, or some "multimedia" machines. The Hauppage WinTV cards and similar knockoffs were popular as well. I remember working on the Linux kernel modules/drivers for these types of cards (I want to say that the project was called "Video4Linux" or similar).
Being able to "watch TV" on your computer used to be a somewhat popular request from well-to-do consumers, and as DVD's came out, people started wanting to digitize their VHS tapes, and video capture cards (the same concept as what the article is doing) allowed that.
Most of them only supported the yellow RCA video in, not VGA or DVI. Just the VGA/DVI to RCA adapter costed some amounts too(not $49).
I think it was really right before COVID that HDMI capture devices finally dipped below $200. Then that Macro Silicon chip at $9 appeared out of the blue and solved PC video input problem. 20 years ago it indeed had been prohibitively expensive to capture desktop video outputs.
The challenge was high bandwidth nature of raw display outputs. Just 1024x768 @ 60Hz is over 1Gbps without overheads. A capture device for that is not something that can be "just" made.
People have been making these for a while. I used to see them on Flash game sites all the time as a kid. It'd be "Windows 96" or "Windows XD" or whatever else they decided to call it. They all had a start menu, notepad, maybe a calculator, and maybe a Minesweeper clone, and not much else.
Judging by the amount of Windows startup sound compilation videos out there, "the kids yearn for desktop UIs" might just be a little more common than you think.
Cool hardware, generally stable experience, family friendly, lots of games which are enriching, the portability is awesome, it’s inexpensive, the games are fun, lots of exclusives…
There can be a thousand reasons to favour something, yet it only takes one reason to reject it.
As for the inexpensive bit, I've never really viewed Nintendo in that light because the games themselves are rather expensive. For my older DS/3DS it wasn't much of an issue since there was the secondhand market. It sounds like the secondhand market is a gamble with the Switch 2 which, at least in my case, makes it a non-starter. That is especially true since they are punishing the person with the legitimate cartridge, who may or may not have been the person who pirated the game.
Sure, but OP asked why anyone would ever buy one, and all of those alone can be a justification. He didn’t ask “how doesn’t everyone view these problems as a non-starter”. It’s an unbelievably popular and fast-selling console - the entire premise of the question is weird anyways.
Eh, from what I've heard it's not really that great. Nintendo isn't really known for cutting edge tech, they're really more known for their first party offering. Steam Deck is a few years old now but still pretty impressive hardware, so I would call them about equal
> generally stable experience
Yes this is true (as long as you don't try to mod), though Steam Deck has been rock solid stable for me
> family friendly
Can you expand on this a bit? Other platforms have family controls and lots of family-friendly game options so I don't know where Nintendo out competes in this area.
> lots of games which are enriching
Aside from the first-party games, this also doesn't feel like a unique quality of Nintendo
> the portability is awesome
I'm assuming you mean physical portability? If so then yes, but also not unique to Nintendo.
If you mean software portability like "can run games on other systems/platforms" then absolutely not. Steam is going to be way better at that.
> it’s inexpensive
Is it? Here at least the switch 2 is $500 (there is one on Amazon for $450 but it is "invite only"), compared with Steam Deck which starts at $400 but goes up to $650 for the top model. It seems like again Nintendo is just not unique in price.
> the games are fun, lots of exclusives…
The exclusives are IMHO really the only reason to get a Nintendo. If you really like their first party games then you have no choice. Everyone I know who bought a Switch (and will buy Switch 2) did it for this reason. To me personally the exclusivity is a major turn-off
If you really want first party games or those with heavy anti-cheat, then yes, but if you just want a handheld console with a great UX, the Steam Deck is phenomenal. The same games are also often way cheaper, plus if you want to play on PC later you can...
For myself it was my first console bought on pre sale. And here in my country is much more expensive.
Basically I raised the bar tremendously. I have the console, MKW, probably will buy Metroid, probably another Zelda. But that's it. I will not tolerate a low bar.
Now that indies are constantly increasing theirs with more genuine experiences? No no no
I bought NSW2 to be my defacto indie platform as well, but I just reporpused a laptop with Arch/Proton/Steam/Gog and I will work on that.
All my accessories from 8bitdo are working flawlessly, so not even a controller I will buy. I don't even bothered to buy the special SD card they require because I can't see myself using even the internal storage, unlike my NSW1.
I'm also part of the group that was shocked with the changes on MKW as well. A long time Nintendo fan disappointed.
I stayed fan for all this time because the experience hassle free. I don't want another Denuvo strategy, or games becoming boring like many mobile games.
I hope more people realize that there are options out there. Support the indies is my choice.
even if you do connect it to the internet and get it banned, it probably wouldn't matter if you're not planning on using it with Nintendo's online services anymore
Several are given in the linked article, like built-in support for ~non-Roman~[edit: non-Western] numeral characters, and nomenclature that works well with screen readers. A diverse staff may also help to promote language (e.g. keywords or in documentation) that's broadly understood across different cultures.
Ah, I think I see the confusion. In the linked article it talks about whether the code itself can include non-western digits. That's distinct from whether it can handle strings or render text containing non-western digits.
It's great that those languages exist. But that doesn't refute that mainstream PL design is linguistically narrow. Even the languages in that article are mostly monolingual, whereas the author is envisioning multilingual languages.
for (I = I; I <= XIV; I++) {
printf("Pope Leo %d is best Pope Leo!\n", I);
}
Interestingly, the authors use circumlocutions to avoid naming the Arabic numerals for what they are, while the ones used in their example are known as Eastern Arabic Numerals.
They clarified in the footnote that this is to prevent confusion as many readers may not know that Arabic numerals are the widely used ones. It is indeed confusing that what the world uses as numerical lingua-franca are Arabic numerals, and what are used in Arabic script (and India sometimes) are called Eastern Arabic Numerals.
As well as information about side by side assemblies (ie: library versions), a Windows manifest file has various settings and a declaration of compatible versions of Windows that affect Windows' handling of the app, such as whether it can handle paths over MAX_PATH, if it is hi-dpi aware, or if it knows about themed controls.
If an EXE doesn't have a manifest file, Windows assumes that it's ancient, so it falls back to conservative defaults like ye olde USER controls to try and avoid breaking it.
While MSDN is a bit impractical to browse (there's simply so much stuff in there) it's usually the best place to go to for documentation when doing Windows dev.
The magic numbers (hashes and UUIDs) sort of make sense because there's a slightly adversarial interaction between developers and Microsoft. If you just had a compatibleWindowsMin and compatibleWindowsMax field with version numbers, people would just go ahead and put "9999" in the max field, and then OS upgrades break applications again. By using UUIDs instead, an application developer can't intentionally or unintentionally declare compatibility with unreleased Windows versions.
No bundler required, no compilation step.