desmondl

Yeah, I clicked expecting a review of GLM 5.3 Flash, but the article was more a retrospective about what he learned during his September challenge: "Only use GLM 5.3 Flash for one month"

He said his experiment was a failure because:

1. He accidentally spent 450M tokens vibe coding with the wrong model, instead of GLM 5.3 Flash.

2. When he used GLM 5.3 Flash, it was sometimes slow. So he switched to other models (Deepseek / Qwen) instead. His guess to why it was slow: GLM 5.3 Flash was so good that the providers were congested.

3. He still needed to use other models besides GLM 5.3 Flash, for R&D and benchmarking.

His takeaways from doing the experiment were:

1. Measure local usage more.

2. Experiment with agent orchestration, with bounded goals.

3. Don't count other models that are used for R&D.

4. Play with Jev.

5. Include experiments with flagship models to compare with cheap open models.

His conclusion about GLM 5.3 Flash: Probably viable for day to day work, but he'll have more thoughts next month.

> When you write something you constantly remodel your understanding through refactors and rewrites until you internalize it.

Unfortunately I learned that not everybody thinks this way. Some orgs do imperfectly fine without good engineering discipline, and that has been the case before AI... AI has only made it easier to give the appearance of good engineering, which is exactly the pre-AI goal of many orgs

Update: It's pretty good.

It still covers as much detail as Opus 5, and provides a healthy amount of caveats, but it's much better at just providing the answer up front and framing the caveats.

5.5 communicates like a real collaborator and not something that constantly demands my mental energy to decode what it's trying to say.

In the application I'm working on, we don't want "user's local midnight" to mean "next day". If a live sports game extends past midnight, we don't want the UI to group it under "Yesterday's games." So I asked Opus 5.5 "can we use the backend's API response as the definition of today instead of the browser's local time?"

Opus 5.5:

> Your assumption holds, and the commit history backs it up. Every time the frontend decided for itself what "today" meant, it broke and was later replaced with the backend's currentSeasonDay. There's one catch: trusting the backend only works if the client's copy of currentSeasonDay is current, and right now it often isn't.

Opus 5 would have buried the answer in some kind of unhinged lecture. Something like:

> The assumption is right about ownership and wrong about possession.

> currentSeasonDay is the authority; the commit history has already paid for that conclusion. Every local reconstruction of “today” became a second clock and was deleted. But naming one clock does not make every copy of its reading current.

> The remaining failure is on the other side of the seam: the frontend no longer invents the day, but it can preserve an old one indefinitely. The source is right. The observation is stale. Those are not contradictory states.

> Do not reopen the ownership decision to solve a freshness defect.

Basically the point is just poll the endpoint every 5 minutes or so

I'll keep an eye on this, it seems cool - write once in typescript, compiler compiles typescript into native apps. Seems like it combines ideas from React Native (one language/application model across platforms), Svelte (compiles away high level abstractions to avoid a heavy runtime), and Flutter (own enough of the UI model to target very different platforms).

What I still don't understand (and can't find documentation for) is how Gea defines the portable abstraction boundary.

The targets are radically different: embedded devices, native UI kits, framebuffer-style rendering, and webviews. The docs don't make it clear which Typescript/JS/node/browser semantics are guaranteed. If I write something like `requestAnimationFrame` and `fetch` and `queueMicrotask`, does it work on every target? The lack of caveats in the documentation implies "Yes" but provides no assurance. Where is the compatibility matrix?

Does an application developer mostly stay inside a portable Gea model, or do they need to understand both Gea internals and the target platform to know what will work? If it's the latter, then it's hard to see the advantage of Gea vs just writing a native app.

My impression right now is: potentially VERY interesting, but needs clearer technical documentation about the portability/limitations and convincing real world proof before I can believe it and let myself be excited about it :)

Looking at the compiler repo, it looks like there is just one contributor. So I'm curious, what AI coding tools did you use? Which models? What's your workflow like? (I'm really interested in first hand experience on how models perform on truly difficult projects, not just at drawing pelicans)

I'll have to try 5.5 on my work's Cursor account. If they really solved the communication issues, I might consider moving my personal account from Codex back to Claude Code.

This is awesome. I've watched frontend webdev swing back and forth over the last decade of my career: from server frameworks like ASP.NET MVC with hacky progressive enhancement, to huge SPAs that reimplement things the browser should already be doing, to lighter SPAs with the library fatigue from assembling and updating every dependency.

Now it feels like the ecosystem is swinging back to: standard web APIs, modern browser features instead of unnecessary javascript, and lightweight progressive enhancement instead a SPA or a heavy UI hydration.

Libraries like hono / htmx already do similar things, but what's exciting about Remix 3 is that it promises all this with batteries included, closer to what Angular was for the frontend or Django/Rails was for the backend, but using all the modern tech and patterns that was developed since then.

The animation in the article shows GPT-5.6 Sol Ultrafast solving a question at 3 secs vs Fable's 27 secs. The "11 hour vs 78 hours" animation implied that they were solved in sequence and not in parallel

Yeah, I also notice that a lot in vibe coded apps. Tbf it's what a mid level dev would write as copy if they were given no product requirements. Kinda hard to shift from engineer brain to product brain in the middle of implementation. During a hackathon I kept a PRODUCT.md file with the product "vision", and ask a strong frontier model to put on a "product manager hat" to review the copy before committing changes.

I would have loved to try locally, but the installer asks me to create an account and I don't want to do that yet.

The main site mentions being able to "mount" a branch, vs. cloning a new repo or using git worktrees. And messageless commits for intermediate work. Besides that tho I don't see a compelling reason to ditch git, but looks interesting enough that I want to keep an eye on it

Same thing happened to me. Except I created a new Facebook account using my work email. I had to use my personal Facebook account. Meta has become so awful.

I work on a small team. I talk to coding agents a lot. I also talk to my human team members a lot. So I have decent experience with interacting with both LLMs and humans.

My two ¢: I also get fatigue when reading too much AI generated words. There's something about the over-polished nature of AI text and the missing feeling that you are interacting with a real human that makes it tiring to engage with for long periods of time. I don't have any evidence to support this, but my gut feeling is that - in contrast to AI - there is some "roughness" with interacting with humans that makes it easier for me to mentally "latch on to" their words that doesn't come with AI.

This new product might be better, but Shimmer was publicly criticized exploitative when it launched. I saw those criticisms at the time, gave the product a fair chance anyway, and unfortunately found them to be accurate.

I used Shimmer in 2022. The app had poor UX and frequent bugs, and the core offering (weekly Google Meet sessions with a “coach”) felt like generic self-help and not personalized coaching. The promised between-session support mostly consisted of DM'd article links, even after I raised that concern directly.

The sessions themselves often felt unprofessional, with background noise, unstable connections, and poor audio quality. The coach WFM'd on their couch during call. Given the price (hundreds of dollars per month at the time), the gap between what was marketed and what was delivered was significant.

Hopefully the new product addresses these issues, but I’d encourage people evaluating it to look at Shimmer’s prior execution and customer feedback, not just the announcement.

Yeah true, I'm starting to remember the headaches with yaml when I was using kubernetes or cloudformation....

Yep, I think the compelling reason of humans writing code is key here. SQLite would make it less accessible for people to write external tooling to integrate with an obsidian vault. There are lots of existing and open that support diffing/parsing/syncing/manipulating json, while with sqlite you have to not only know sql but support another application’s database schema, which third party developers are less likely to do

I haven’t had any issues with yaml in markdown frontmatter or openapi specs. What kind of issues do you see with list and maps that make you against yaml? I agree that for computers and consistency json is preferred. I already use a linter for my markdown files so I would do the same with yaml to keep lists and maps consistent

I completely agree. Even if they completely tank I can open my obsidian directory in a text editor or command line and still use it. I would still have access to features that are common in other apps like full text search or plain file sync. Attachments are just files in the filesystem that can be opened in any image viewer. Basically if i can’t use obsidian anymore i can still use my notebook and take notes without implementing or finding new software

Any reference for obsidian's specs? The closest thing I could find is this: https://docs.excalidraw.com/docs/codebase/json-schema but it seems to be really minimal and doesn't go into detail on what properties belong in elements

Sometimes you have nodes that overlap each other, so you want to control whether or not a node is in front of or behind another node.

Though yes, they could have explicitly defined a z-index or defined a convention on how the ordering should work (first nodes top and last nodes bottom or vice versa?). It's interesting to think about the trade offs between explicitly defining these things vs. leaving the application to implicitly make the choice. JSON Canvas seems to be designed to use in tandem with markdown files in a note taking app, so it makes sense why they opted for the more implicit design to be similar to markdown

I think you're talking about the trade offs between supporting features like "DOM manipulation, state management, animation, etc." and "shipping updates" out of the box, versus only storing the data as simple files and leaving everything else to the implementation.

Sqlite as an application file format is great [1], but for a knowledge base / note taking app the benefits are not worth the tradeoffs in my opinion.

Sqlite is more performant more performant and provides lots of built-in features. However, most note taking users do not have enough notes or files to benefit from that performance. Sqlite will also lock the user into the application, whereas a "pack of files" can be used in the shell as a text editor. Using markdown files + a open json format has the benefit of being supported by multiple applications (e.g. sometimes i open my obsidian vault in vscode), while a sqlite database would need a proprietary schema coupled with a single application

I prefer an open file format that isn't tied to a vendor. A "data bridge" might handle syncing and diffing more efficiently than plain files, but it is still tied to the vendor. For example, I prefer not to pay for Obsidian Sync, and I'm able to use a git plugin and storing my files on nextcloud to sync between my devices. This leverages existing tech without having to implement features from the ground up

[1] https://www.sqlite.org/appfileformat.html

An object in JSON is meant to be unordered [1], so arrays are better if you want order to be preserved.

[1] https://www.json.org/json-en.html

I agree with a lot of comments that it's minimal, but in my opinion that is a good thing. I'm a big fan of Obsidian, and of the things I like about it is the data source is all markdown files. Markdown is meant to be very lightweight and portable, and overcomplicating it will limit adoption and extensibility (imagine markdown vs pdf).

JSON Canvas seems to follow in that spirit by being very lightweight, so a lot of implementation details (i.e. how are files rendered, what file formats are supported, etc), edit tags, etc) are left open to implementation.

Markdown and JSON are meant to be non-opague file formats that prioritizes portability and human readability over other features. An application format like Sqlite has a lot of benefits over markdown, but it loses the benefits of text based formats like being compatible with git and is less portable.

What I would like to see is a convention for extending the node and edge definitions, similar to frontmatter in markdown files- something that is not required for basic rendering but is a nice-to-have for applications to consume) - that way portability between apps of varying complexity can be maximized while still allowing for more complex features that some apps might implement. Markdown has the benefit of supporting extensions (for example like tables in GFM) - apps that are not compatible can still render the unsupported markup. But there should be an explicit way to extend open JSON formats.

Some feedback off the top of my head and from reading the comments:

1. *Specifying node ordering*. Obsidian seems to just send whatever is last touched to the top, but this makes a common feature in many apps (move up/down/back/front) more difficult to impement

2.*More explicit definition for line shape*. Adding a way to "bend" a line in a specific way. Useful for creating more complex diagrams.

3. *Relations between nodes*. Group nodes contain child nodes, but the spec doesn't specify how the child nodes are defined. I would expect it to have a `children` property to nest nodes. Obsidian seems to implicitly link nodes to groups based on whether their bounds intersect. This makes it difficult to implement some common features:

a. nodes that exist outside of the bounds of its group, for example a node that "floats" just outside of the edge of the group's borders.

b. nodes that are not part of a group even though it exists within the bounds of that group.

There are many different ways for a canvas app to extend the spec to implement those features, but it seems like something that should be defined in the spec to maximize portability

4. *Extensibility.* Either explicitly support or provide a standard for defining more styles for nodes and edges, such as stroke width, stroke style, rotation, etc. It seems like "color" should be a part of this as well, rather than being an explicit property of a node.

5. *Embeds.* Supporting "embeds" as a node type. I even think the "file" node should be redefined as `embed` with a `uri` property to support different schemes (`file://`, `oembed://`, `https://`) and maybe a `mime-type` (`text/markdown`, `image/webp`). The file node's "subpath" property seems to be only relevant for markdown files, so I think that should be an extension rather than an explicitly defined.

6.*YAML* :) (Should just seemlessly convert from json, but yaml is more readable than json)

Being able to design standards that evolve over time and making tough decisions about what what to make explicit and what to leave implicit is a skill I want to improve on as a developer this year. Does anyone have any resource recommendations or best practices to recommend for me to research?

Looking at this with an open mind, I'm curious what benefits running SQLite in WebAssembly with a proxied web worker API layer gives compared to using localStorage or something similar.

* Using SQL has clear benefits for writing an application. You can use existing stable tools for performing migrations.

* Using SQLite in a filesystem offers many advantages w.r.t performance and reliability. Do these advantages translate over when using WebAssembly SQLite over OPFS?

* How does SQLite / OPFS performance compare to reading / writing to localstorage?

* From what I know about web workers, the browser thinks it is making http requests to communicate with subzero, while the web worker proxies these requests to a local subzero server. What is the overhead cost with doing this, and what benefits does this give over having the browser communicate directly with SQLite?

* I remember seeing a demo of using [SQLite over HTTP](https://hn.algolia.com/?q=sqlite+http) a while back. I wonder if that can be implemented with web workers as an even simpler interface between the web and SQLite and how that affects bundle size...

I somewhat agree, because as an end user all I had to do is disable the bundled apps (teams, etc) and switch the default browser to firefox. I agree with the criticism though, it really leaves a bad taste in my mouth to see all the extra prompts encouraging me to keep Edge, and the social media links (instagram, tiktok) in my start menu. But for someone who experienced bloatware, this stuff was pretty easy to remove / change. The main difference is that this "bloatware" came directly from Microsoft and not third parties.

Did your entire Google account get deactivated? My Google account is linked to Gmail, GCP/Firebase, Youtube, Drive, and a ton of SSO apps. Used it for the past decade, but I know now not to put all my eggs in one basket so I have backups of my most important data. Still, what happened to you is a big fear of mine.

Agreed, I have a small 3 node cluster at home and I use all of those things you listed. I had to dive very deep in the details and learn a ton of new things to get it right, and I had all the time I wanted because it was just for fun and learning. It's almost like having my open source self-hosted AWS (in terms of abstraction from infra, not in reliability)

Would I host any of my critical side projects on my cluster? Probably not. Kubernetes was made with large organizations (google made it after all) in mind. As a solo developer, it's better for me to host my apps on a VM and move to AWS/Azure/GCP if I need to scale.

Agreed, I used lastpass in 2016 and tried to switch to keepass. I'm more than technical enough to use keypass and sync a vault across all my devices, but I needed this to be as easy as possible. I know myself enough to understand if something doesn't feel as easy as humanly possible, I'm much less likely to use it. A decent chunk of people are not like this, which is why I believe there is this huge debate over "Keepass vs 1Password". But anyway, I switched to bitwarden and the UX was more than good enough for me. It "just works".

I even started self hosting it this year and it continues to "just work" - although I don't recommend it to most people since I now have to manage a server. I was already self hosting a lot of other things last year (wanted to move away from google/apple services) so the "cost" of self hosting Bitwarden was negligible.

Anyway I know I rambled a lot, but just wanted to chime in and throw in my opinion about bitwarden

I got pretty proficient at using vim in vscode, and personally for me the investment was worth it. It's great for working in HTML with chords like `va"p` (replace selection around quote with clipboard) and `dip` (cut out the contents inside this xml tag). YMMV depending on the type of work you do.

I understand where you're coming from, but I'm going to play devil's advocate and think through everything that needs to be considered for a simple, "back in the day" solution that involves apache, php, and a mysql database:

1. Provisioning the server, either via VPS or setting it up on your local machine and exposing port 443.

2. Installing Apache on your operating system

3. Installing a cert, getting it signed by an authority

4. Installing php, enabling it in apache

5. Installing mysql

At this point you'll have to write your php from scratch or use something like wordpress. Assuming we want to keep it as simple as possible and write php from scratch, you'll want to consider file permissions so your database credentials aren't accidentally leaked.

6. Creating the schema and tables on your database

7. Distributing your site's static content through a CDN

And this doesn't even involve automated deployments, which these services give out of the box.

My point is that a "traditional" approach can appear just as overengineered and convoluted if we want to replicate the scalability, stability and security of solid PaaS services like Vercel and Fauna.

I get that a hit counter is very simple, but I assume the point of this article is to provide a simple "hello world" example that uses these PaaS services, which again, provide a lot of benefits over manually configuring infrastructure.

Brain dump: Looks very cool. From what I can tell...

pros:

* No tooling to set up, don't have to think about project structure or computation (VMs or cloud functions)

* Don't have to think about databases, connection strings, etc

* Fast deployments

* Perfect for rapid prototyping or hackathons

cons:

* Vendor lock-in at the language and infrastructure level

* Not open source

* Have to learn a new language

Compared to serverless (for a CRUD application), I wouldn't have to write configuration to set up the API endpoints / dynamodb tables. Also, deployments would be super fast which closes the developer feedback loop. I shouldn't have to worry about emulating my stack locally or deploying my stack every time I want to test my code.

The cons make this very hard for me to buy though. My ideal framework would be open source in a popular language (JS / Go), runs on cloud (AWS / Azure / GCP), fast deployments (no cloudformation), low configuration / convention based (like nextjs), and integrates with popular NoSQL data stores (mongo, redis, etc). Basically it would be completely conventional with an opinioned data access and the ability to override features to add more complicated functionality like optimizing data access after the initial prototyping.