rudi-c

While the U.S. capricious immigration policy gives an opportunity for Canada, it only gives it one particular opportunity: that of hiring educated, high-potential, but inexperienced immigrant workers.

The thing about potential is that it needs to right environment to be realized. Canada still has two hurdles to create that environment:

- Access to capital, either in the form of risk-tolerant VC funding or established companies willing to invest significantly in R&D. Those are not quick to move over the border.

- A critical mass of _experienced_ talent. Entrepreneurs and high-agency ICs who've seen what it looks like to build a successful startup and capable of replicating it. Those don't have much incentive to move over the border either.

The U.S. has hundreds of startups that later became unicorns. The employees of those startups are typically the key members that drive the success of new ones. For Canada, the only name that easily comes to mind is Shopify.

In a related but less public way, I've found myself less motivated to write internal documentation at work. It feels like in a lot of cases, it'd be better for the reader to throw Claude at the codebase to explain things.

A separate document explaining how a system works can go out of date. While I'm quite good at highlighting the most important insights and non-obvious traits of a system, I'd still be guessing what the reader needs from my doc at the end of the day. Claude can answer questions based on what the reader is curious about and wants to learn.

Some types of document are still useful, namely higher-level directional or philosophical topics about the intention of a codebase. e.g. "we would like to eventually move X system to Rust for Y reason", "we chose mutable data structures over immutable in this part of the system because Z". But fewer than before.

On one hand, Shin Jinseo is an outlier player of this generation. On the other hand, the newest generation of new pros will have exclusively learned by using the AI to tell them what the best move is, so there's reason to believe that peak human level has yet to be reached.

While AlphaGo originally only had win rate as a metric, modern Go AIs have more knobs, including an evaluation of "complexity".

Just stating this off the top of my head so I could be misremembering, but I heard that the KataGo settings used were tweaked to favor complexity. This was most apparent in Game 1 which Shin Jinseo lost, where the AI had an unusual opening. However, the last game was quite plain leading me to wonder whether that setting was present in the last game (or at all).

Yes, I don't mean that it affects the present. Only sad in a nostalgia sense.

This is a lazy statement based on extremely vague handwaving about desktop v.s. web. It's not the 2010s anymore. Time to drop these generalities.

Users were migrating to us _from_ desktop applications. Collaboration was the key differentiator, but a less well known reason was that improved performance, including but not limited to the support of large design systems, was also a commonly cited reason among paying customers for migrating to Figma.

That's sad but sensical. Fun fact, Figma originally started as a fully C++ codebase, and Asm.js was key in proving that it would be possible to run a design tool in the browser. The switch to WebAssembly didn't happen until after there were paying customers, and provided nice improvements to load time (Asm.js is still JS which the bundle size is bigger and requires the code to be parsed into an AST, unlike WASM).

> If you're working online (eg figma), you can just download history lazily.

You can download the history lazily, that's a special case of incrementally loading the document.

If the history is only history, then sure. But I was understanding that we were talking about something that may need to be referenced but can eventually be GCed (e.g. tombstones-style). Then lazy loading makes user operations that need to reference that data go from synchronous operations to asynchronous operations. This is a massive jump in complexity. Incrementally loading data is not the hard part. The hard part is how product features need to be built on the assumption that the data is incrementally loaded.

Something that not all collaborative apps will care about, but Figma certainly did, is the concept that the client may go offline with unsynced changes for an indefinite amount of time. So the tombstones may need to be referenced by new-looking old changes, which increases the likelihood of hitting "almost-never" edge cases by quite a bit.

re: git repositories

That's partly because repositories rarely need to be cloned in their entirety. As such, even when you need to do it and it's a couple hundreds mb taking a few minutes, it's tolerated.

In situations where a document needs to be cold loaded often, the size of the document is felt more acutely. Figma has a notion of GC-ing tombstones. But the tombstones in questions aren't even something that get created in regular editing, it happens in a much more narrow case having to do with local copies of shared components. Even that caused problems for a small portion of files -- but if a file got that large, it was also likely to be important.

Electron does not belong in the same category as React & Vue. JavaScript frameworks are commonly understood to mean:

- Third-party libraries, almost always implemented in JS (technically it could be some language compiled to WASM but I'm not aware of any commonly used WASM framework)

- Dynamically loaded from a CDN or bundled with application code at build time

- Provide an high-level API for creating and updating UI

- Whose implementation edits the DOM (a browser's low-level UI representation)

In contrast, writing an app _without a UI framework_, therefore implies writing first-party JS code that interacts with DOM APIs directly, without that level of abstraction in-between. This is not a common choice these days, and could be considered an impressive accomplishment, hence this Ask HN.

To create that UI, you use the same low-level DOM APIs in Electron as you would in the browser because well, it is a Chromium browser engine.

Example of each combination:

- Framework-using apps running in the browser: Airbnb, Figma

- Frameworkless apps running in the browser: HN

- Framework-using apps running in Electron: Figma's desktop app

- Frameworkless apps running in Electron: Obsidian

I wouldn't consider Electron as an answer to the question. It would be best described as a framework for running web apps as a standalone desktop app, but not a framework for creating user interfaces. Just using Electron doesn't make any progress towards having a solution for managing the complexity of writing code that interacts with the DOM.

Everyone else in this thread is talking about (React/Angular/Vue/JQuery/etc) v.s. (Plain JS/Direct DOM manipulation/etc). Running that code on top of Electron or not is entirely orthogonal. So I admit I'm confused why you're fixated on bringing Electron into the conversation. Op's question appears to me like it references the last part of the linked thread: "I’d like to know what JavaScript framework (e.g. Vue, React) Obsidian desktop application is using for creating the user interface?"

Since we seem to be talking past each other, what do you think the conversation is about?

I mean, you're correct that Obsidian doesn't run on the browser. But it's built on web technologies. As a result, I would argue that the overlap between the skillset and work needed to build an app like Obsidian overlaps more with most web applications than most desktop and mobile applications.

You're also correct that Electron provides APIs beyond those available in the browser, such as access to the native filesystem. The way I see it, those are mostly some lower-level details it wouldn't be that hard to run Obsidian in the browser, it's just a product choice not to (specifically, it would imply creating a file hosting service). As the Obsidian mobile app demonstrates, Electron is swappable and not needed for Obsidian's core functionality. In contrast, had Obsidian been built on React, it would be rather difficult to simply "run without React" without rewriting the entire application.

How to build a large front-end app on non-web technologies (Swift, C++/QT, C#, etc) is also an interesting question but I didn't understand that as being the topic of this conversation.

That you believe frameworks were invented to serve employers is a cynical point of view. I'm sorry for whatever bad experience you've had with the frameworks or people using them that caused you to develop this viewpoint.

A developer choosing to use a framework doesn't mean they are reliant on it, any more than choosing a particular language, library, text editor, tool, etc. It simply means they decided it was a helpful way to accomplish their goal, whether that's to save time, or establish consistency, eliminate categories of problems, avoid re-inventing the wheel, etc.

I don't know if you're aware of this, but you're coming off as incredibly arrogant with your strong claim that frameworks are used by those who don't know better. It's easy on the internet to vaguely gesture at "developers", but most of us are individual who've built software with real users among other demonstrated accomplishments. Strong claims require strong evidence, I hope you have the arguments to back it up.

Framework is unfortunately a term that's both ill-defined and quite overloaded. Electron is a framework in a very different sense than the "JS frameworks" op is asking about. The latter is about libraries with APIs and mental models for producing the UI & UX of web applications.

Electron is just a way of running Chrome without the Chrome UI around it, + a few APIs for accessing native OS APIs. You wouldn't say that Chrome/Firefox/Safari are frameworks just because they execute JS code and has APIs. In the context of this discussion, it is fair to say that Obsidian was built without a framework.

When you're writing only a "couple lines of code", you can do pretty much anything you want. There's no real tradeoffs to discuss except in a theoretical sense, because the stakes are so small.

If the app being built is "large" (which I understand to mean, has high essential complexity), then those tradeoffs matter a lot. If the app is built by a team instead of an individual, the people problems become significant. Those can very well be turned into a technology problem. The technology (framework in this discussion) can be used, among many other things, to establish a consistent way of solving the problems in the application, which alleviates many people problems.