However, I’ve been subscribed to it since its inception because it is the best way to have games that my kid can play without shady ads or engagement practices.
I know that is not going to last, as my kid is now a pre-teen and likes other types of games (like Hollow Knight) that are not available on Apple Arcade.
But the current state of the gaming industry is terrible, especially on mobile. Indy companies producing games like Dead Cells, Hollow Knight, and Stray are good, and there is the extremely rare case of Larian. But other than that, the market is full of dark-UX patterns to promote app purchases. Mobile apps are a minefield of gacha games that should be forbidden for kids.
Sure, but in another time you'd have paid ~$2.99 for the ad-free version one-time, and carried on using it. They intentionally deleted that version of the game, screwing over everyone who did so, then quietly launched the same game again, removing the ad-free one time purchase option.
Just forget that mobile gaming exists? I think one of the cheapo Linux retro handhelds offer a better portable gaming experience than 99% of mobile games, ads or no.
Taste is subjective. I get it. There are Triple A games on Arcade. Things like Civilization 7, for example. I don't know what the current standalone price is because we use Apple One Family, however, it used to cost $5/mo.
Apple one is a steal IMO. Apple TV, Fitness+, 2TB, Arcade, and other smaller perks like News+ make it an easy sell. Compared to something like Netflix? Netflix is $25/mo for their top tier streaming alone. Apple TV consistently has higher quality content. So does Apple Arcade and Apple Fitness...then you get 2TB of storage to back your crap up to.
Ask Google or Samsung what they are doing for the cost of an Apple One subscription.
Not a fanboy or anything. I'm basically critical of all tech companies, however, Apple is doing something that is working well for them.
Have you thought of getting your kid a nintendo console of some kind? A jailbroken 3DS seems like it'd be great for avoiding that kind of slop since the 3DSs app store died a few years ago
There is no doubt that a product’s community culture and the maintainer’s attitude have a significant influence.
However, I used Perl and stopped using it without knowing anything about its internal politics or community. PHP, ASP, Java JSP and later Rails were much better than Perl for web development.
* I know that for some the mention of JSP will be rare, as it was ugly… However in the 2000s it was the state of the art
The issue with Eclipse and that approach is the complexity of mixing plugins to do everything, which kills the UX.
When VSCode started, the differentiator from Atom and Eclipse was that the extension points were intentionally limited to optimize the user experience. But with the introduction of Copilot that wasn’t enough, hence the amount of forks.
I think that the Zed approach of having a common protocol to talk with agents (like a LSP but for agents) is much better. The only thing that holds me from switching to Zed is that so far my experience using it hasn’t been that good (it still has many rough edges)
Microsoft just fork Atom, and Atom had already good and a lot of extensions.
Before Microsoft buy Github, there was no reason to switch to VSCode instead of Atom.
When Microsoft buy Github, it received Atom from the Github team, and Microsoft stops the development of Atom.
VSCode was just Atom with the Microsoft brand, and some little tweaks from Microsoft, never a game changer compared to Atom, like Atom was in it's time.
Now Antigravity is again a fork with some little tweaks from VSCode, no game changer, just with the Google branding.
I guess we have different perspectives and information about the “rise” of VSCode.
I was an Atom user. Even before the acquisition of GitHub the major feature of VSCode was its speed and TS integration. AFAIK, the only common part between Atom and VSCode is Electron. Other than that, VSCode started with a different codebase based on TypeScript, while Atom was originally written in CoffeeScript.
Multiple design decisions helped VSCode to thrive (btw Erich Gamma was also part of Eclipse):
- The creation of the LSP. Each release of VSCode is also tied to TypeScript releases and improvements. There is a lot of collaboration between the two teams. That gave VSCode the best support for TS and JS. I used Atom and WebStorm regularly when VSCode came out, and VSCode auto-complete and TS support were orders of magnitude better. Everybody caught up since then, but I guess many users like me switched because of that.
- Unlike Atom, VSCode was designed with web integration in mind. A lot of sites started to use Monaco for code editing, and a lot of web-based IDEs use parts of it (CodeSandbox, StackBlitz, etc).
- Gradual rollout of plugin integration. While Atom has the philosophy of everything is pluggable, VSCode was intentionally limited. Which was a good thing given the poor loading performance of Atom.
By the time MS acquired GitHub, Atom usage was already in decline.
* Note: my side of the history, comes from my experience of working in a company that did a custom Eclipse IDE. We evaluated Atom and then VSCode as alternatives to “modernize” our IDE. So I have experience in looking at both Atom and VSCode code bases: they are totally different. Also, the main problem with VSCode for us was the limited extensibility.
> By the time MS acquired GitHub, Atom usage was already in decline.
I wanted to second this: I compared both, with Atom experience starting before the first VSC release. Atom had performance and stability problems continuously through that period, and never really won any of my coworkers over. A lot of that was simple performance: I remember using Is It Snappy? to test my subjective impression and finding that input latency was a full order of magnitude worse, which is the kind of thing which really colors your impression of an editor.
Given their extensive expertise in browser and OS plugins, I understand this move.
You can foresee a challenging future for the Grammarly product for a long time. Now that the "improve writing with AI" feature is everywhere, there are fewer reasons to pay for their subscription (e.g., I didn't renew this year because I have multiple AI subscriptions, and Grammarly was the least critical of them).
However, for me, the main advantage of Grammarly was the user experience of having mistakes and suggestions inline and just a click away while editing, as well as the quality of the suggestions (with an LLM chat, there's a lot of trial and error and junk you need to filter out).
I understand their move, but I wish they had developed a good minimalist native text editor with the same Grammarly suggestions and click-to-correct interface.
That is my number one issue with startups. They all start minimalist and end up bloated, some sooner than others, and what made them great disappears behind all this bloat. See: tyranny of the marginal user.
I worked with Backbone, Angular 1, Ember, and then React.
The article overlooks the problems that made React popular:
- Composition: Composing components is easier and more efficient in React. Backbone’s render function assumes "this.$el" is mounted and available in the DOM. That makes composition difficult: you cannot simply nest one component inside another without managing the DOM lifecycle of subcomponents. You don’t need 1.000 components to feel the pain.
- Event handling: You can’t pass an event handler as a string, so the events object must be paired with the selector to locate the element. Any structural changes require updating selectors or managing unique IDs.
- State management: Re-rendering components when state changes becomes messy in Backbone fairly quickly. That mess is why Angular 1 gained popularity. React simplifies this further by enforcing a one-directional state flow.
- Efficient DOM updates: Even if you implement composition and state management ad hoc, you still must update the DOM efficiently to avoid layout thrashing and related issues. React isn’t immune, but these problems are typically easier to handle.
- Other features: Implementing useful capabilities from scratch, like lazy loading parts of components (for example, suspense) or building hybrid apps with server-side rendering, requires significant work.
I'll argue that nowadays, if you want to use vanilla JS with templating support, lit-html (not the full framework, just the template part) is a much better choice than Backbone.
The example is also unrepresentative of anything meaningful. TodoMVC[0] is the classic point of comparison, and the Backbone version is a nightmare to grok compared to React[2].
What you see as a nightmare is really straight-forward code from another perspective. It just looks very unfamiliar. Yes, it feels raw, it is verbose, it's imperative and not declarative, but the entire app lifecycle is there to see.
You can easily tell what every function is doing, including the library ones, and magical behaviour is kept to a minimum. It could be easily maintained 20 years from now, as you have a very thin layer over DOM manipulation and Backbone itself can be grasped and maintained by a single human.
One could argue that React leads to better development velocity, but from experience I can say that reality is not that simple. The initial speed boost quickly fades, instead a huge amount of time starts being allotted to maintenance, updates, workarounds, architecture and tooling as complexity compounds.
That's all true, but I think the article's point still stands: React trades one set of compromises for another, and regardless of the tool used, software engineers using that tool have to do a lot of lifting to get the tool to work. It's not a question of whether react is better than backbone or vise versa, it's a question of whether we software engineers, as a group, are emphasizing the correct compromises, and what takeaways we can make from examining the compromises of today's popular tools.
I definitely do a lot less lifting with React than with jquery or backbone; like OP I also used all three (and others) in production, and my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air. In particular, counter point to the article, i loved that i could do something relatively complex, relatively easily, but still pop open dev tools and understand what was happening. I think tis great new libraries and concepts are sprouting but imo looking back wont help; browser javascript has come a LONG way obviating a large chunk of the reason we were all using jquery in the first place. Basic CRUD does fine with server side rendering, and is easier to test and maintain. Using that until it hurts is a solid strategy for avoiding react if thats ones goals.
The reality is stateful UI is complex on its own. Then JS tooling is complex (byo typescript and std lib). Then UI is something everyone sees so the whole company has opinions about how it should look. Mush it all together and FE development is rough. React is a punching bag because its been dominant so long. Id welcome the next phase when it arrives. But building toy apps with aged technology imo wont bring to light any unturned stones. Id recommend researching the plethora of real code and discussions that have beaten this horse to death on the open internet instead.
> my React sentiments at the time seemed to be relatively common: React felt like a breath of fresh air.
This was exactly how I felt. I building a Backbone app around the time React was released. It was only around 2600 lines of JS at the time but event handling and state management already felt like a tangled mess.
Porting it to React was a huge improvement even at that scale and really paid off over the next 5 years of development.
Agreed. You want to run htmx at a company where the business requirements change every month? Good luck but you’re going to end up rewriting it and have a much harder time hiring.
I too prefer Vue over React. I still haven't checked out Svelte, and I'm completely over Angular by now.
React looked great when I first used it for something really small. It looked horrific when I used it on a massive project with ridiculous amounts of data and tons of middleware. Although the real horror was the useEffect spaghetti. Vue keeps looking reasonable in every project I encounter it in. Even when people use it poorly, it's never Vue itself that's the problem. Well, maybe when people start working around the reactivity. That can get really bad.
Oh, the nostalgia! Looking at the project felt like taking a trip in a time machine: the blog on Blogspot, the release files on SourceForge, the use of Delphi, and the screenshots reminiscent of typical 2000s IDEs.
It is not a criticism. The challenging task of creating an IDE deserves a lot of respect. I’m just surprised by the tech choices.
I know that political topics are not suitable for HN.
But, as an Argentinian, I’d like to clarify that this financial rescue is intended for Milei.
We will have midterm elections soon, and the government is doing whatever it can to keep the USD exchange rate down so it doesn’t impact inflation and public perception. But this type of “rescue” is a band-aid, and it’s usually bad in the mid-long term.
In 2018, the IMF took a similar action. They extended the largest loan in their history, to cover bonds and provide some respite to Macri at the onset of an election year.
And if you wonder why this happens, it’s a combination of politicians who put their desire to stay in power over their country, geopolitics (a country in debt with you is easy to control), and high interest rates from high-risk bonds.
Sadly is a cycle repeated over and over in my country. In fact, the economy ministry that we have today it’s the same one involved in the 2018 negotiations with the IMF.
The problem arises when you start to mix memory management with more complex structures.
It’s extremely easy to make mistakes, and you must be very careful about ownership and clean up. Those things are not strictly related to pointers, but in C, it’s inevitable to use pointers to handle them. That's why people say pointers are hard.
Yeah, it's one thing to understand "a pointer is a location in memory". It's a completely different things to understand what to do with that information.
When I first started learning to program, it was in C, with one of those "Sam's Learn Yerself a C++ in Eleventy-Three Days" books. I was, like, 15 or something. This was long enough ago and my family was just barely poor enough that we didn't even have the Internet yet.
The book explained memory. That was not hard to understand. But we had been using stack-allocated variables through several chapters in the book so far. I didn't get why you would ever want anything as a pointer. If I wanted to write a program to add 3 and 5, why wouldn't I just say "int x = 3;"? Why bother with this stupid dereferencing syntax? Given that the author chose to explain pointers by first explain the address-of operator on stack allocated variables, it felt particularly perverse. The regular, ol' variables were right there! Why but just use them
I didn't have a concept yet of what one could even do with programming. Hell, just a few years prior to that point, I was pretty sure all of the other programs on my computer were written by massive teams of wizards manually typing out 1s and 0s.
I still managed to bungle on and write code. But my programs in C never really worked well. Though, they still worked better than my classmates' versions! Then, in my 2nd year of college, I had transferred universities and the new place taught in a Java.
Java was disgusting. It was so verbose. Why did we need all these weird, multi-sylabic, period-infested function calls to do anything? Why was it so slow? Why couldn't I write ASCII-art graphics with it? Why couldn't I run my programs on my friend's computer?
It wasn't until I had taken computer architecture that I gained a much better understanding of what any of all these computer things were meant to do. I ended up implementing a basic scripting language in Java. And then, suddenly, I understood pointers.
However, I’ve been subscribed to it since its inception because it is the best way to have games that my kid can play without shady ads or engagement practices.
I know that is not going to last, as my kid is now a pre-teen and likes other types of games (like Hollow Knight) that are not available on Apple Arcade.
But the current state of the gaming industry is terrible, especially on mobile. Indy companies producing games like Dead Cells, Hollow Knight, and Stray are good, and there is the extremely rare case of Larian. But other than that, the market is full of dark-UX patterns to promote app purchases. Mobile apps are a minefield of gacha games that should be forbidden for kids.
reply