My journey started casually enough—working on Tixie, I was looking into simpler ways to deploy Rust-based Lambda functions when I came across Cargo Lambda. What got my attention was that it is so easy to cross-compile with it, mainly due to Zig's powerful build system. Even though it was built for Rust developers, it utilizes Zig for cross-compilation, allowing me to compile ARM binaries that worked on AWS Graviton on my Apple Silicon Mac.
That was the start of a series of rabbit holes that consumed me for more than a week.
I have heard about Zig prior but had not looked into it deeply. This new brief encounter quickly turned into a deeper dive, pulling me into an engaging exploration. It also seems like Zig community consists of quite a significant "Rust refugees".
Rust is memory-safe, extremely, but it can be rather annoying and unforgiving for developers on many of its designs. Personally for me, what annoyed me the most is its error handling.
Notable projects such as Bun—a JavaScript runtime gaining popularity—are turning to Zig for its simplicity, clarity, and efficient build system. I spent more than a week learning and diving deep into Zig – I like it so far for its C-like syntax, being a low-level language like Rust, and more straightforward language design choices compared to Rust.
I am working on a project which I have started on Rust for a bit.
As I got deeper into Zig, I stumbled upon Jetzig, a Model-View-Controller (MVC) web framework built on and for Zig. What particularly intrigued me about Jetzig was that it seems to be very suitable for HTMX and Hypermedia Systems, a development stack and philosophy that I gravitate towards lately for my goals in simplifying build process.
I spent the next few days learning and experimenting with Zig and Jetzig.
Jetzig's built-in template language is Zmpl. However, with it being a rather new language, there was one problem — working without syntax highlighting felt uncomfortable.
No Zmpl syntax highlighting extensions was available yet on the VS Code extension marketplace. Zmpl's page did mention one. Unfortunately, I could not get the extension installed. Also, looking into it, it seemed like it lacked some comprehensive definitions. I thought about fixing it by creating one; how hard could it be?
First thing to learn: tmLanguage, a syntax grammar definition structure originally created for TextMate. It is still widely used by most popular code editors today, surviving TextMate, such as Visual Studio Code, Cursor, Sublime Text, and Atom. Unfortunately, resources for tmLanguage were strangely limited. This blog by Matt Neuburg was helpful in explaining the concept. Interestingly, it was written more than 11 years ago in February 2014.
That took a few days of intense development, testing, and refining and finally created something functional. While it wasn't perfect especially for multi-level nested mode switches, it was a significant improvement over existing solutions and met my needs for now.
What started as a small personal inconvenience turned into multiple rabbit holes that consumed me for more than a week, but emerging with an appreciation for Zig, and learned about tmLanguage and the VS Code ecosystem.
If you run a company, do not release roadmaps or make future promises. You owe your customers nothing beyond what they're paying for right now. Your customers pay for what you sell today, not what you will be selling tomorrow.
I call this the Roadmap Pitfall. It is a common mistake and trap that many companies, especially startups, fall into. The tech landscape is littered with companies that have overpromised and underdelivered through their public roadmaps, hurting their reputations. Some infamous examples are Tesla's Robotaxi, Meta's Libra and Metaverse, Google Stadia. They are selling products that might become revolutionary tomorrow but not today.
The latest victim is, surprisingly, Apple – yes, the world's largest company. Apple historically not only avoided publishing roadmaps, but went to extraordinary lengths to keep upcoming product leaks and rumors at bay. In 2005, Apple sued people who leaked product details online, and famously forced the shutdown of Think Secret, a prominent rumor website, as part of a settlement in 2007.
Yet they've now fallen into the Roadmap Pitfall with Apple Intelligence – announcing features before they were anywhere close to ready and setting expectations they couldn't meet. Apple has started removing features from their iPhone 16 and Apple Intelligence page.
In a statement last week, Apple confirmed that it needed more time to finish developing the new Siri features. Apple said it aimed to begin rolling out the features "in the coming year," but it did not provide a more specific timeframe.
from MacRumors
I agree with the widespread criticism of how badly Apple Intelligence flopped, not only regarding delays but also on features that were actually released. Notification summaries are so problematic that Apple had to disable them for news applications after generating inaccurate content. Writing tools are hardly usable in their current state, and Image Playground was fun for approximately 30 minutes – the total time I've spent on it – before my iPhone heated up significantly.
I still think the idea of Apple Intelligence – AI that lives and runs securely on your device – could be a massive life-changer. If I were to bet on the company that would deliver "AI in your pocket" well, with great UX without compromising security, it would be Apple. My issue isn't with the vision but with the over-promising of features that were nowhere close to being ready. In fact, I would have been perfectly fine with an iPhone 16 Pro with no AI. Let the competitors play the feature one-upping game with their gimmicky flip-phones and touchscreen-laptops.
Roadmaps and projections are for investors, who might pay a premium in your company's valuation, counting on you being able to deliver the promised goals. Customers are not investors – they buy your current products and services, not your future promises.
The next time you see a company selling dreams and futures, with "coming soon" banners plastered across their website, proceed with caution. There are often significant problems beneath these promises – forcing them to sell what-could-have-beens rather than their products. If you're running a company, remember: it's better to surprise and delight customers with unexpected new features than to disappoint them with promises that never materialize.
Spelling, or 听写, is a very familiar process for parents of Singaporeans with primary-school-going children, or in fact, for parents worldwide. Every week, each of our children is to learn two sets of words and phrases, one in English and one in Chinese, to be tested in school. Each set consists of 15-20 phrases and sentences.
A usual process for us would be first having each of our children study, on their own, the words or phrases for the upcoming spelling test, and once they are ready, passing us parents the list for us to read aloud to test them. I'm sure many parents in Singapore are very familiar with it. Rinse and repeat every week.
I created Tixie to facilitate the latter read-aloud process, allowing it to be conducted solo by the students only, without involving parents or another person.
Read the list back, one line at a time, in optionally random order.
Shows the final list in the order being read out to allow students to mark on their own.
To save time from having to recreate the same list if a child would like to retake the test, Tixie also automatically saves the list and provides a 9-digit Tixie code for the test to either be retaken at other times or shared with peers. Try out the code above.
Teachers can also pre-create a list and share the saved Tixie code with the students in class for their self-practicing at home.
Tixie is a wordplay of tīngxiĕ (听写）and rhymes with pixie🧚. The logo is in vector form, designed and created by my 8-year-old daughter, Melinda, on Scratch (check out the source!).
She publishes her Scratch projects from time to time, give her a follow if you think her work is cool.
Tixie is entirely serverless as I do not want to maintain servers and infrastructure if I can avoid doing so.
Frontend:
Pure HTML
Vanilla JS
Tailwind CSS
Served statically via AWS CloudFront CDN
I am not a big fan of monstrous and complicated build-steps. I deliberately chose not to use React, JSX, or any sophisticated JavaScript libraries. Vibe coding via Claude Code does help in managing vanilla HTML and JS codebase without over-complicating things.
The backend is solely for saving and retrieving saved spelling tests; serverless architecture fits such requirements perfectly.
While I am not new to Lambda, this is my first time doing it in Rust. My past usage has been via Node.js. Cargo Lambda helps in local testing, and most importantly, it supports cross-compilation for ARM processors on my macOS-based laptop – allowing the final production code to run super efficiently on AWS Graviton, a highly efficient ARM-based processor and with very tiny memory footprint.
The code runs on AWS Lambda without requiring any runtimes, which Node.js scripts would. That helps significantly with the often-criticized slow cold start oftentimes associated with Lambda functions. Tixie's API is lightning fast and yet very light!
While it is not meant to be a feature, it is crucial to point out that the current version of Tixie contains no AI components.
Speech is generated entirely on the client devices on which Tixie loads on. This is why there needs to be a language selection at the top, to allow language mapping to commonly-available voices on devices.
I have only tested these on some of the devices I have access to; if you would like to add other voices or languages to the shortlist, please drop me a note.
The project did not start out without AI. The early prototypes/experiments with some AI components, and that made it somewhat cost-prohibitive for a free app:
Voice-only use, using real-time voice AI API. Users can say "Next," "Repeat the word," or something similar in another language to control the flow entirely via voice. Users can leave their device face down when taking the test.
Automatic test setting. A user just has to take a photo of the test sheet given by the school, and the test will be automatically populated.
Automatic marking. At the completion of a spelling test, the user can snap a picture and have it automatically marked. This process involved prompt engineering and some fine-tuning, especially for Chinese handwriting recognition, and being a little bit more forgiving in handwriting recognition for the users, whom are often kids below the age of 10.
I made an early prototype. You can find it at https://uzyn.github.io/tixie/ while stocks last. Took only a few hours to make.
It was done without server-side component, with the list save-able entirely using URL parameters. My children were using these for the past few weeks before Tixie.org is ready.
Key takeaways with URL parameters for real-world use:
Apple's iMessage strips away anchor tags, the stuff after # in a URL.
Encoding and decoding gotchas for non-ASCII characters.
Digg was one of the very first social news aggregators back in the 2005-ish. It's one of the inspiration that led to me creating and launching Ping.sg in 2006. Ping.sg was a social blog aggregator for mainly Singpaore blogs.
To me, that's a sign of revival of free and open web independent of big techs.
I'm happy to see it. It's a glimpse of a validation of a few things that I am working on in the space of open web.
I like what my friend Ridz call it: Make the web personal again.
Also check out my friend KahWee's new blog. It is not built on any blogging engines nor any off-the-shelf static site generators. It is built entirely with Claude Code!
This could normalize the way how models are trained in the future. I'm not sure yet if this is good or bad in the long term because we may not know what we might miss at high precision with improved techniques and compute resources if we continue to train at low precision due to the pressure from competitors.
Before DeepSeek, training was often done at high precision, requiring more resources. Precision was usually reduced (quantized) only at testing (interference or usage) time to reduce compute requirements for everyday use.
It is also important to note that while DeepSeek demonstrated how effective low-precision training can yield effective results, DeepSeek's team did not invent low-precision training.
My workflow with generative AI has been changing quite rapidly over the past two weeks. DeepSeek's release really sped up innovation and release cycle among its competitors.
I may draft a longer note covering my workflow next time; I'm writing a quick one to share how impressive Claude Code is.
I have been trying, and failing, to get this straightforward task executed by GitHub Copilot using a series of models and tweaking of the prompts. Here's the gist of the prompt:
Extract inline SVGs from index.html into individual SVG files and load
them via <img> for better code and file management.
It seems relatively straightforward, but GitHub Copilot managed to get five strikes with it. Models I have attempted include both Claude 3.7 Sonnet (Preview) and Claude 3.7 Sonnet Thinking (Preview).
GitHub Copilot would either manage to screw up the alignment of the page or tweak it so much that it affects the Document Object Model (DOM) of the page and affects its accompanying JavaScript.
I decided to check out Claude Code, which has been all the rage lately among the software engineering community. Lo-and-behold, it got it right at the first attempt! The document DOM stays fully intact, the layout remains perfect, and my JavaScript continues to work fully.
Claude Code's final output:
The SVGs have been successfully extracted from the HTML file and properly
organized in the assets/icons directory. The index.html file has been updated
to reference these SVG files using thetag instead of embedding them directly
in the HTML.
Here's a summary of the changes:
Created an assets/icons directory for SVG files
Extracted 8 SVG icons from the HTML into separate files:
mail.svg - Email icon
back.svg - Back arrow icon
forward.svg - Forward arrow icon
share.svg - Share icon
sound.svg - Sound icon
refresh.svg - Refresh/repeat icon
volume.svg - Volume icon
chevron-right.svg - Right chevron icon
Updated the HTML file to usetags to reference these SVG files
Updated the JavaScript file to usetags for dynamically generated content
This improves code and file management by:
Reducing HTML file size
Making SVG icons reusable across the application
Enabling browser caching of SVG files
Making it easier to update icons in the future
Improving code readability and maintainability
The application should function identically to before but with a cleaner organization.
Another thing I love about it is that it is billed through Anthropic API rather than through Claude's subscription plan. It's a win-win for both parties: Anthropic does not have to worry about overutilization with a fixed-cost subscription plan, and I do not have to worry about subscription fatigue.
Since the introduction of Perplexity's Deep Research on Feb 14, 2025, now the 3rd major deep research AI offerings after OpenAI ChatGPT's, and Google Gemini's, I have been using it rather extensively. It helps greatly on a research project I am working on.
Early findings on Perplexity Deep Research, it often takes 5-20 minutes, not quite 2-4 minutes as advertised. Perhaps it is due to the spike in usage since the introduction, or perhaps it is a tweak to make it appear as if it's working comparatively hard as the other 2 Deep Research offerings. Overall, I do not have an issue with the response time. I can also see its thought process throughout the thinking time.
I am a subscriber of ChatGPT Plus ($20/month) and Perplexity Pro ($20/month). As such, I do not yet have access to ChatGPT Deep Research, which, as of today, is only available to ChatGPT Pro ($200/month) subscribers.
My preliminary findings on Perplexity Deep Research after about 24 hours of rather extensive use.
It takes 5-20 minutes and hardly 2-4 minutes, as mentioned.
It likes Reddit a lot. The cited sources tend to include Reddit a lot if you allow social sources. On the web version, I would often explicitly exclude social sources, but on the mobile or desktop version, it seems to be lacking such an option – I prefer including both web and academic sources but not social sources.
Its response seems rather brief (~1000 words) as compared to what I have seen on ChatGPT's Deep Research. It often leaves me wanting to learn more by asking follow-up questions. I am on the fence if this is better, as a brief response allows me to consume its response within 2-3 minutes, as compared to what I seen some ChatGPT's Deep Research users do, feeding its response to Google's NotebookLM to help in digesting its very lengthy response.
Perplexity goes into deep research mode on the first query immediately, without any clarifications first, like that observed on ChatGPT Deep Research. I do not like this as much for the following 2 reasons:
It forces the user to be highly verbose in prompting because you do not get a chance to clarify after LLM's first take. This takes up a lot more effort and guesswork. If you miss it, you get only to correct yourself 15 minutes later.
It makes a wrong interpretation of your intention and gives you output that is not accurate. One example for mine would be as I asked it to research the early history of the web, and it covered broadly on the ARPAnet and Internet.
It has no usage cap, which is good!
UX issue: I like to see its chain of thoughts, but if you navigate away, often because you want to start a new thread as Perplexity works, you are unable to get back to an in-progress thread before the response is generated – which would then hide the thought process.
Bug: This is likely a teething issue. I would be losing threads or find the same queries being generated multiple times.
Overall, I am a happy user. I am looking forward to when ChatGPT's Deep Research is made available to Plus users. I now split my usage as follows:
ChatGPT 4o/o1 for usual queries, quick research and planning tasks.
ChatGPT o1/o3 or Claude for coding assistance.
Perplexity Deep Research for... deep research with citations.
Q: Would you consider releasing some model weights, and publishing some research?
Sam Altman: yes, we are discussing. i personally think we have been on the wrong side of history here and need to figure out a different open source strategy; not everyone at openai shares this view, and it's also not our current highest priority.
It is interesting that Sam Altman said what he said, considering the ongoing legal battle between Elon Musk and OpenAI on the similar topic. It is even more intriguing that DeepSeek appears to be a catalyst for this shift in thought.
Among some of my peers, there have been some general extrapolations concerning the DeepSeek shockwave, suggesting that China is demonstrating to the world, particularly the U.S., how an open-source strategy can be effective. However, this conjecture seems far-fetched, as open-weight AI models not only originated in the U.S. but thrived. The real catalyst for popularizing open-weight models was Meta's Llama, released in early 2023. Many of the open models available today are modeled or structured based on Meta's Llama.
Regardless, this is beyond country lines and should not be politicized.
Open models are compelling but challenging to monetize. For Meta, this is manageable because they have substantial financial resources and revenue streams independent of their AI initiatives. This has given Meta ample room for experimentation, including the not-so-successful metaverse venture that cost hundreds of billions of dollars.
For OpenAI, however, AI is their sole focus, making it difficult to convince their board to adopt an open approach. This is even more challenging considering the switching cost of their clients is negligible.
We have witnessed how open-source technology has enabled companies and researchers across national borders to build upon previous knowledge more easily, leading to better results and products in a remarkably short time frame.
For the sake of humanity, I sincerely hope that this trend persists.
It must have been be a challenging week for the folks at OpenAI and other similar closed-source foundational AI model companies. The release of DeepSeek, which is not only better than OpenAI's o1 model but also free, has sent shockwaves through the industry. The fact that DeepSeek has managed to achieve this feat with only a fraction of the resources that it took for other comparable models to be trained is even more surprising.
Foundational closed-source AI companies are usually making a loss on the consumer products through the likes of ChatGPT Plus, Claude Pro. It is also commonly believed that these consumer subscription-based AI products do not bring in much profits. It is not surprising to find that some of these subscription plans are even loss-making, such as that of $200 a month of ChatGPT Pro plan.
The foundational AI companies are still figuring out ways to turn profitable. The revenue model today is largely relying on the API and enterprise sales, i.e. the "AI wrappers" and existing apps racing to support AI feature.
Sam Altman: The honest answer is we have no idea [on how to bring in revenue]. We have never made any revenue. We have no current plans to make revenue. We have no idea how we may one day generate revenue. We have made a soft promise to investors that once we've built this sort of generally intelligent system, basically we will ask it to figure out a way to generate an investment return for you. [The Journal by WSJ]
While we, fellow AI enthusiasts, are excited seeing newer models outdoing one another every other day, the reality is that these models are all based on the same foundational API. This makes the switching cost for AI models for API users is practically close to $0. With DeepSeek's API reportedly costing less than 5% of OpenAI's o1. The costs can potentially be even lower if you run the open source model on your own servers, reducing it to only hosting costs. Memories, fine-tuning (LoRA and the likes), and retrieval-augmented generation (RAG) applications can be ported to competing models with relative ease, in fact more so with open source models than the closed-source counterparts.
DeepSeek proposed a cut-price fee offering for accessing and using DeepSeek-R1, at 16 yuan ($2.20) per million tokens, considerably less than OpenAI's o1 438 yuan ($60.00) for the same usage. [Reuters]
It is going to be really challenging for foundational AI models to figure out a way to create stickiness or introduce switching costs, artificial or otherwise, similar to how it is for cloud operators, especially email and office suite providers. A Google Workspace user will not be switching just because a competitor is offering email services at 50% discount, even if the competitor provides 100% of all the services available at Google Workspace. Technical and data migration pain is sticky, for better or for worse.
A proud moment that started with a simple catch-up with a good friend.
I briefly shared that I am working on a project related to self-publishing. My friend, Chandra, shared that he has been considered blogging and asked me to set one up for him on the spot. He also shared that he would prefer self-publishing than contributing content on social media platforms. That was music to my ears!
I am on a mission to bring self-publishing back. More on that later.
Being put on the spot, I was thinking what would be the best solution to enable self-publishing without over-complication on the writing process and being light on maintenance.
I thought of WordPress.com within a few seconds for many reasons: mature user-facing ecosystem, straight-forward UI, low maintenance. Sure, I am aware of the mixed views on surrounding Matt Mullenweg/Automattic/WordPress, but WordPress.com is possibly, today, still the best self-publishing low-maintenance software out there.
Chandra blogs at cmr.sg. Despite being newer than my site, there has been a lot more postings at cmr.sg. I have subscribed to it.
Software engineering has become overwhelmingly complex.
Want to build something today? Good luck. First, you’ll need to wade through an ocean of decisions: which tech stack to choose, how to set it up, which JS/CSS/TS/TSX frameworks to use, which build tools, linters, and testing environments to adopt, how to structure your project, organize your repository, and configure CI/CD pipelines. The list goes on. If this is something to built by a product + engineering team, despite more headcount, the complexity is often compounded even more.
Even after spending days setting everything up, you’ll never quite feel satisfied. You’ll tinker, tweak, and second-guess every decision for weeks. You’ll obsess over improving your stack, striving for a perfection that always seems just out of reach.
Meanwhile, only 5% of your time goes into building your actual product. The other 95%? That’s spent on the stack.
Back in 2005, things were simpler. We didn’t have CI/CD pipelines, JSX, HTML5, or a hundred other acronyms to wrangle. We worked with what we had, and we got things done. If that meant coding in PHP, so be it. If that meant using Notepad to write code, so be it. If that meant aligning layouts with <table> tags and <br>s, so be it. And yes, debugging live wasn’t unheard of—as long as no one accidentally dropped the production database.
We mainly had one major problem to solve back then: Internet Explorer 6. We overcame it, and we laughed about it later.
In 2005, building was fun. It wasn’t bogged down by layers of complexity. We focused on the joy of creating, on bringing our ideas to life.
It’s 2025 now, and I’m ready to reclaim that joy. I’m resolving to build like it’s 2005. No over-engineering. No unnecessary complexity. Just building.
So here’s to simple tools, straightforward solutions, and rediscovering the fun in creation.
Zola is a static site generator, which means it creates a bundle of self-contained, portable files that can be easily hosted anywhere without the need for dynamic server-side processing. It’s fast, lightweight, and just works.
Zola is built on Rust. I’ve been learning Rust and I am loving it. While there’s no real need to modify Zola itself, the fact that it’s Rust-powered resonates with me.
Zola is Markdown-based. Writing in Markdown is second nature to me. It’s clean, simple, and distraction-free.
Zola uses Tera, a simple templating language. It reminds me of PHP, the good side that is. It’s a refreshing change from the complexity of JSX.
I’m excited to return to the roots of blogging: self-publishing, owning my content, and keeping things simple.
