Comments URL: https://news.ycombinator.com/item?id=48383441

Points: 4

# Comments: 0

For context: in Jurassic Park, there is a scene where a 12-year-old girl sits in front of an SGI workstation to deactivate some doors (or similar) and says, “I know this! This is UNIX; it’s easy”, and uses a 3D UI to navigate files. At that time, an SGI workstation was very expensive and not something you could learn at home, and UNIX-like OSs weren't as common. The scene was like someone saying “I know this it’s a nuclear reactor, it’s easy”

While many things changed, the world of remote services didn’t change radically: different technologies, same concepts.

> What surprised me was that Java supported processing ZIP files and XML from its standard runtime.

Makes me feel old.

Java was developed at a time when most people connected to the Internet via dial-up. That meant two things: the runtime is something you download once and has to work offline, and it has to support compressed packages. JAR files are essentially ZIP files with additional metadata stored as files. So yes, that’s why Java has built-in libraries for ZIP files.

The XML came with the “XML fever” of the 2000s. Java was one of the first languages to include XML support, and many of the XML DOM APIs are very Java-oriented. And, of course, it was included in the standard lib because nobody wanted extra module downloads over a slow connection. (and because XML was evolving at that time, it also meant that you had some issues between the SDK libs and user-provided libs)

Many of these systems are added to digital wallets due to legal requirements or fraudulent cases. For example, one case of fraud that I’m aware of happened in Chile, where citizens were able to open bank accounts digitally with just their ID. But since there is no good biometric information, many criminals took the IDs of homeless people to open accounts and move money around.

Sadly, these shitting things happen, then companies use these services to avoid the liability, and then these services abuse the information they have.

People don’t have much choice unless their representatives in government do something; it’s not about apathy: you can stop using one bank app, but not all of them otherwise you’ll be out of the financial system.

Deno has many of those things now, but my past experience wasn’t good. The first versions of Deno had a lot of friction; Bun however was more or less useful from day 1.

I think that the appeal of this product is that the Wintel monopoly of years ago is dying. If the Googlebook is well executed (as the Apple M1 line was), it can be an option for Android users who wish to move away from Windows but are not knowledgeable enough to use Linux. I think the only problem here is Google's track record of abandoning product ideas. A new product like this requires multiple iterations to get it right, but if Google abandons it as soon as the results are not what was expected, it will not have the time to mature in areas like gaming or app support.

Teams keep building product tours because the other option is to invest heavily in trial-and-error user research to optimize the onboarding experience. That is not only more expensive in terms of time and resources, but also requires greater alignment of priorities.

In my experience (I work in product design), introducing product tours is usually a band-aid for deeper UX problems.

Products with an excellent onboarding experience that goes beyond the “click next” pop-up tend to have an excellent user experience too, because they take the time to think about the usage story.

Instead of parsing or screen-shooting the current page to understand the context, an AI agent running in the browser can query the page tools to extract data or execute actions without dealing with API authentication.

It's a pragmatic solution. An AI agent, in theory, can use the accessibility DOM to improve access to the page (or some HTML data annotation); however, it doesn't provide it with straightforward information about the actions it can take on the current page.

I see two major roadblocks with this idea:

1. Security: Who has access to these MCPs? This makes it easier for browser plugins to act on your behalf, but end users often don't understand the scope of granting plugins access to their pages.

2. Incentive: Exposing these tools makes accessing website data extremely easy for AI agents. While that's great for end users, many businesses will be reluctant to spend time implementing it (that's the same reason social networks and media websites killed RSS... more flexibility for end users, but not aligned with their business incentives)

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.

Many apps, like Slack and LinkedIn, use it to display a link card with a description.

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

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.

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)

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.

He had a very prolific year.

There are a gazillion of options that resolve the same problems: Vue, Svelte, Solid, Lit, etc.

Backbone was born as better code organization on top of jQuery and CoffeeScript. It never attempted to solve these issues.

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.

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.