Julien_r2

I could imagine that even a small task at NASA might involve more knowledge and logic than the smallest task for a Hanoi's tower problem.

Depends on what is considered as small enough for the LLM to be resolved with a high confidence.

If the framework is used, eventually there will be 3rd party lib adding new features (from the top of my mind, maps), and someone will need to write the bridging with the native SDK. It means the bridge will most likely need to be written in objective-C instead of Swift

I actually hope to find better answers here than on cursor forum where people seems to be basically saying "it's you fault" instead of answering the actual question which is about trust, process, and real world use of agents..

So far it's just reinforcing my feeling that none of this is actually used at scale.. We use AI as relatively dumb companions, let them go wilder on side projects which have loser constraints, and Agent are pure hype (or for very niche use cases)

Arf seems I'm one of those :).. thanks for the heads up!

A pro could have been an extra narrative about carbon footprint savings.

I'm surprised it hasn't been raised when talking about saving 2Tb/year only for React. It represents costs, which doesn't seem to be an issue, but also computing power and storage. (Event with a higher/longer computing power due to slower compression, it's done once per version, which isn't really comprable to the amount of downloads anyway)

Hard to calculate the exact saving, but it would represent a smaller CO2 footprint..

Which is, then, supporting the fact that scale matter, isn't it?

Here the scale of time is larger and does make the 5$ significant, while it isn't at the scale of a few days.

There're few benefits that comes with packaging it into an electron wrapper, including:

- making sure it works on all platforms independently of the browser you use (because it comes packages with chromium)

- having access to more API from the platform. Although the UI is rendered through a WebView, there's still native code running, that you can hook back into your app. That can be useful to either offload some logic to native, or access native API that you pilot from the WebApps

- having a shortcut icon to open you app in the system (although this is getting obsolete now that Chrome and Safari offer "Add to Desktop" functionally)

Many people in the PR mentioned the complexity that Typescript brings. But wasn't it an over simplification from the language from the beginning?

I mean, in the context of JS 10 years ago, Typescript in indeed overly complex, but in the context of today's JS running servers and very complex apps at scale, it just seems sane to back up the code with types, just as most other languages would do..

In my opinion it's now a required complexity to build up a lib with some stability and a safe DX for contributors

"the depth will be inverted" better describes it indeed. Thanks clarifying it!

I use this trick too for puzzles! Spotting on the fly the differences, makes for a great intro of the topic with people not aware of it!