Forem: Fyodor

These ever-popping and ubiquitous posts with titles saying something like "Here's The Topic That Will Blow Your Mind (Especially If You Have One)" — with unnecessary unsolicited text in parentheses specifically — are so freaking annoying, FWIW... 👴🏻

Fyodor — Tue, 10 Feb 2026 08:51:12 +0000

Discussions on DEV seem to become much more active lately... Like, orders of magnitude probably... What happened?! 😲

Fyodor — Wed, 04 Feb 2026 12:11:48 +0000

TIL… would be fun to see it evolve indeed.

Fyodor — Wed, 08 Oct 2025 15:59:50 +0000

Christian Heilmann

Oct 8 '25

Abandonware of the web: did you know that there is an HTML tables API?

#html #javascript #tables

Comments 4

2 min read

One niche dev newsletter: lessons learned

Fyodor — Mon, 01 Sep 2025 17:28:29 +0000

About seven months ago I had published the first issue of my first newsletter — Metaframeworks Weekly, dedicated to JavaScript-based tools like Next.js, Nuxt, SvelteKit, and Astro and their place in the modern web development. Today I'm renaming it to Metaframeworks Records and sharing some why's, pains, and gains here, following up the initial post from the last days of the last year. I'm not going to teach anyone with this lessons format, not at all (would be boring, and I'm not that old) — it's rather the list of things one can learn even during such a short amount of grind time over something new that needs to be repeated regularly. Sounds obscure, I know, so let's dive deeper.

Lesson 1: Roll up your sleeves

I love reading newsletters. Well, some of them. Most of the stuff on the Internet, including the niche dev projects, are pretty basic and represent some sort of list of resources with basic meta derived from... well, the resource meta. There are some examples I really like though, like Bytes, where the author adds some [in]sane humour and pop-culture references to that, with some short essays on the most interesting stuff. But most of that is pretty generic anyway. What I always wanted is some deeper chronicles of the industry I'm into without unnecessary noise at the same time. So, as I mentioned, something like that pushed me to creating my regular list of interesting resources dedicated to metaframeworks topics specifically. And I thought some details for each of the findings in the list would make it more alive.

Long story short, making something alive is [un]surprisingly difficult. That is something I'm still trying to figure out the mechanics of, but one obvious thing is it's hard, and it requires time, especially if you do it manually. I have some tricks in my pockets already, but in essence it's still a lot of reading things, and trying things, and writing about things.

I honestly underestimated the amount of effort and am now trying to adjust to proper operation mode instead, taking into account my day job in a "fast-pace startup environment", and my family life, and my migraines, and learning Rust (which can be a sort of migraine of its own at times). What is true is that you need to re-visit and re-assess your attitude and cut yourself some slack if you plan to save your mental health not to go mental. Which leads to...

Lesson 2: Form the shape as you go

During these months of working on the newsletter I tried different tools and approaches to everything, starting from information gathering, through website source code changes, and finishing with the resulting text format. I found that at least in the early stages you need to change a lot and cut away stuff that doesn't look good, and emphasize things that work best and bring personality to the project.

The newsletter had started as Metaframeworks Weekly, and because of the Lesson 1 above I quickly realized that the cadence is probably not something that should be set in stone this harsh way. At the same time, from the very beginning, the content was tightly tied to music, which is a big part of my audiophile life: each issue is called after a song with a tagline from it as an epigraph, relevant to the key topic of the week. So that was the reason I eventually decided to rename the project to Metaframeworks Records, which sounds much better to me because:

It eliminates the pressure of weekly updates — now I can publish bi-weekly, or twice a week, or even go to a vacation sometimes.
It's much more relevant to music, which is so cool (especially as all these records provide a lot of releases in the end).
It's relevant to records as notes on something (which is closer to my heart than "issues" as the latter is still associated with bugs for me).
It's more relevant to news I write about being some sort of records in its area — some outstanding, or the most awful, or unexpected things peer developers praise or shame out loud.
It's even much more relevant to Computer Science, especially if you consider the fact I started my newsletter with the Issue #0, as them records ~~classically~~ sometimes do.

All in all, it's a good example of shaping something as you go, when you realize that, even with some unhabitual changes, the results may get more straightforward, relevant and even... simple?

Lesson 3: Simplicity is great until it's not

The initial idea of mine was to make the project itself (the code base) as simple as possible and (even though it started as an Astro-based project) come to some framework-less solution and avoid vendor lock-ins of any kind. But eventually I realized a good tool goes a long way, and with some of them it turned out into a real attachment:

I still use Astro, and it helps me a lot to quickly iterate on new ideas and features without clunky contraptions of self-made analogues for well-thought features the guys deliver.
I use Buttondown for the actual newsletter services (and I'm ashamed to confess I hadn't even went out of the boundaries of the free tier yet), I can compare it with other solutions which I used professionally, and it's much simpler than competitors (literally one line of HTML code), while allowing me to avoid the pains of maintaining my own mailing solution.
I use Bluesky for communication around the newsletter (not a lot of though, wouldn't call it marketing or something) and for following the real-time news from the metaframework world, and I need to accept this project is very close to something one would call an ideal social media for humans.

Probably without all that I'd feel myself more accomplished, but I also would suffer a lot more too. With one caveat related to being slightly opinionated and selective about some technologies, but you know what?

Lesson 4: Opinions are inevitable, and that's OK

Again, while I still try to be the most unbiased person as I write about the technology news of my niche of choice, I can not avoid some judgements from time to time, not to say about having some of already mentioned favorites. However, I was told once, and I pretty much agree with the saying, that without opinions you lose personality. I'm still sure there's no black and white in our technical world, there is no absolute, and I try to float at a sane distance from love or hate for this or that technology. But being a curator of the metaframeworks-related newsletter already makes me an opinionated person by default. That's why I have a "The Bad" block in each of my records, where I inevitably find something bad about metaframeworks and related technologies each week. And this block is a part of something important too, specifically...

Lesson 5: Patterns are extremely useful

Each newsletter issue consists of three blocks as a rule: the Good, the Bad, and the Noteworthy. You quickly get an idea of what that's about, and it becomes a habitual and anticipated structure. Besides, it makes it easier to prepare each record for me, and makes cross-record connections possible (and quite interesting). There are lots of other patterns in this project too, starting from the Astro's content collections (powering not only issues and tags but also stuff like the items on the Metaframeworks Comparison page, or FAQ pairs), the song title and tagline as "my thing", posts on Bluesky, and more. As we developers know, patterns are powerful tools to simplify maintenance, and it's a shame not to use them. Like many other things too, for instance...

Lesson 6: AI is extremely overrated

AI and LLMs are parts of our lives now. It would be dumb to dump them these days, but... As Rich Harris had said recently, "I keep giving LLMs a chance to impress me, whenever I encounter a boring task that they should be good at, and they keep shitting the bed". That's spot on. I experiment with code assistants (and online webapp builders like Bolt and Lovable) a lot, as they mostly generate code for web projects in metaframeworks wrappings by default. But as many of us know from the professional experience, the last 10% remaining from the initial (often AI-generated) implementation of a project take 90% of the time, or even more, and sometimes dealing with the AI output, or collaborating with AI over these 10% is a real torture, as even on simple tasks the code assistants fail spectacularly (and too stupidly) too often. And even for simple stuff LLMs are born to be perfect at (like text proofreading) they need thorough supervision (even more than myself, being a non-native speaker, so we fight a lot and I often prefer my clumsy draft versions). But they're not the only burning problem of our industry, as...

Lesson 7: Security is important, from back to front

I am genuinely intimidated by how often you face new and new security threats and issues with the technology like metaframeworks and tools around that. You can check the "security" tag, I'm not kidding: that's a whole new specialization for some bounty hunters these days. The problems the metaframeworks industry raises are quite unique very often, considering their hybrid approach to building full-stack web applications. So it's hard to overestimate how important it is to keep your finger on the pulse of what's happening in the industry in this regard and how different tooling vendors try to prevent adversaries from messing with your code. We, developers, too often neglect that, but there's some hope that metaframeworks can actually (and surprisingly) be an answer to this problem too. But that's a long journey and...

Lesson 8: It only starts here

I like Metaframeworks Records — that's my labour of love. I write a lot, I learn a lot, and I explore how much I still need to learn about the technology and the ways to make it work in a better way for us. I have a lot of ideas to make it easier for myself and other interested developers, and to subside further beneath the tip of the iceberg we have discovered during these several month, like:

The metaframeworks encyclopedia,
The metaframeworks comparison (which I plan to turn into an interactive quiz!),
The dedicated Bluesky feed,

and a lot more (not even saying about "simple" stuff like records search, pagination, and alike), just stay tuned! Suggestions are welcome too, as well as any feedback (the simplest way is to ping me via fyodor@metaframe.works).

And if you have any new metaframework in mind (it happens, you know) — spit it out without a doubt! Who knows, maybe it will take its place in the metaframeworks Hall of Fame another day.

The cover photo by Jon Tyson from Unsplash

Inspiring amateurism, or a couple of success lessons from random podcast episodes

Fyodor — Fri, 29 Aug 2025 17:43:33 +0000

I listen to a lot of programming-related podcasts, that's one of the ways I both educate myself with some occasional technology aspects on the background, and keep myself acquainted with the latest and the greatest in the software development world (not much, TBH). I have a curated list of podcast episodes I get to when I'm doing chores usually, or woodworking, or dogwalking, or whatnot. Sometimes it's new stuff from shows I follow, sometimes it's something I found during targeted search about some technology I'm currently interested in.

One of my favourite tech shows of all time is "Software Unscripted" — always thoughtful and long no-bullshit conversations about different aspects of computer science, programming languages, and a lot more from the host who is themselves a great person and educator — Richard Feldman (I love their courses on FrontendMasters so much too, the cleverest and the most modest teacher on the interwebs!).

There was this guy on the show once (quite some time ago, found this episode accidentally), Casey Muratori, who's an expert in software performance selling their courses and other educational materials and considering themself proficient in different technologies including web development. And when Richard started to talk about ORMs with them, Casey admitted they were hearing this term for the first time in their life and was genuinely surprised that people do such things to SQL...

Another show I love is "Rust in production", where Matthias Endler speaks to seasoned Rust developers about their experience in building future-proof production software systems. There was an episode recently with Andrew Burkhart, Senior Rust Engineer at 1password. This episode was particularly exciting because of the clear "fake it til you make it" philosophy of the guest. When you think about Rust system engineers developing low-level software — mentally coding in assembly and then translating it on the fly to some formal language that you, as a web developer, can only have nightmares about — you imagine some Yoda-level gurus (and don't get me wrong, they often are). But as a matter of fact, usually these people have no idea what they are doing at the beginning and learn on the fly (at best!), growing their craftsmen wings in process (or pretending they do).

What this taught me was to give some perspective to my inner critic and impostor alter-ego: if the people we all admire often have no idea what they're doing on a professional level they're paid for and still are considered to be the experts, I think we all, usual software developers from the darkest corners of the software world, have a chance to some day say to ourselves, "well done, pal!"

I mean, we all constantly hear and see these memes and shitposts on social media about "hey, I'm a seasoned software developer and today I asked ChatGPT how to center a div", or "programmer's mind is constantly fluctuating between 'I am a God!' and 'I have no idea what I am doing'" but usually that's just self-deprecating humor, or a well-worn joke for the approval of fellow programming plebs. But in fact, many people in the software world pave their way to success through lots of empty stares at dark screens with blank minds over some simple programming task.

It's possible to be a know-it-all. It's just that usually we are not in a position to. There are other things to do as well. So it's fair to take it easy, slow down the pace, and give yourself some friendly pat on the shoulder and say "it's OK, you'll learn the borrow checker tomorrow, today you can just watch Netflix with the kid... or play you some harpsichord... like that guy from the Rust in Production podcast... like a PRO..."

Cover photo by Drew Gilliam from Unsplash

Wait a minute, where's this week's Meme Monday post?! 😱

Fyodor — Tue, 12 Aug 2025 04:44:04 +0000

I see C book in 2025, I subscribe 📖

Fyodor — Thu, 31 Jul 2025 05:14:15 +0000

Paul J. Lucas

Jul 31 '25

“Why Learn C” Book Announcement

Comments 15

6 min read

UmiJS: the Shaolin of web frameworks

Fyodor — Sun, 30 Mar 2025 14:18:23 +0000

I stumbled upon UmiJS accidentally when reading about Mako — a Vite analog built with Rust (of course) which I'm very interested in. When I started to dig, I had fallen into a whole treasure trove which I wanted to share with other people who hadn't heard anything about the Umi ecosystem. Maybe it's just me living under a stone, so feel free to skip it if you're already a UmiJS kung fu master. Otherwise, welcome to the ride.

(And just in case someone may consider this journey somewhat derogatory in terms of China and its culture — it's not. I'm a big fan of everything related to this part of the world, and the Shaolin and kung fu reference is not arbitrary — I am myself a certified oriental martial arts instructor, and this philosophy is not an empty phrase for me.)

Why Umi
What is Umi
Tooling ecosystem
People behind
Project example
- Prerequisites
- Project scaffolding
- Project structure
- Running the app
- Working with Umi CLI
- Build and deploy
My opinionated impressions
Conclusions

Why Umi

I have a soft spot for metaframeworks, you know. So I eagerly dig into info related to any metaframework projects and tools. There's no shortage of that these days, of course — the landscape is versatile. But some projects are quite esoteric and hidden from external eyes — either because of geographical and cultural reasons, or because of language barriers. Here it is both. UmiJS and tools around that are developed predominantly by the Chinese community of commercial and non-commercial open-source contributors. However, as with many Chinese technological innovations (looking at you DeepSeek), this one sparks curiosity because of how rich and self-sufficient the ecosystem is. So armed with this curiosity and intrigued by the original GitHub source code findings, I had decided to explore it further. Consider it a kind of "Umi for React/Vue/Angular/Svelte developers" research, often resting on the corresponding habitual analogies.

What is Umi

UmiJS is an [extremely] pluggable enterprise-scale React-based web application [meta]framework, offering (as many analogs) routing, build tools, dedicated design system, and everything in between. From what I could see during my reconnaissance, its main market is huge enterprise monorepos for React websites and web applications (something very opposite to tools like, for instance Waku, if you will). Umi itself is not exactly a metaframework though, as I'd say, but rather something React would be if it aimed to resemble Angular as of version 19 — the powerful SPA framework with optional support for SSR/SSG and a whole lot of build options making it very customizable and approachable for performance optimizations specific to each particular use case. Its plugins-driven extensibility is something resembling Vite but for a more dedicated goal of building rich user interfaces. And there's more.

Tooling ecosystem

In addition to the framework itself, the developers behind UmiJS maintain and connect the dots for a whole huge ecosystem of very clever tools and technologies, some of which have gained popularity even behind the Great Wall of China:

Mako. A bundler and web server — a kind of Vite for the UmiJS web apps. It's a fresh development among other tools (as far as I understand, the team used mostly Webpack and Vite before this in-house tool got up to speed). Built with Rust and declared to be even faster than other Rust-based analogs, not to mention the lame tools like Webpack and such (just kidding, I ❤️ Webpack forever!).
Dumi. A static site generator specifically designed for component library development. Look at it as something between Storybook and Docusaurus inside the Umi world (but much better integrated between each other, presumably).
Ant Design. A top-level UI component library that provides a set of high-quality React components. Quite popular even outside of the Umi toolset and can be used independently, but integrated beautifully with Umi — to the extent I had a hard time figuring out where to find the actual components (see below, in the project section).
Father. A tool designed specifically for building libraries. Used widely by all other tools and from the first look it's hard to find any analog in the world I got used to. Very often dev teams develop some custom approaches for that, but here it's a good set of best practices combined into a decently looking (and functioning) craftsman's hammer.
Qiankun. An implementation of micro frontends for easier and painless building of production-ready microfront-end architecture system.
Dva. A plugin-based state management solution (Redux + Sagas). Also quite popular in narrow communities outside of the Umi world.
CLI. An interesting DX booster for Umi I'll talk about in detail a bit later.

Moreover, with Umi you get a strong plugin system, some of which are included by default with each project scaffolded with Umi CLI. These plugin provide, for instance, capable site analytics, rich charts, robust data storage presets, internatiolization and localization capabilities, and many other enticing (though obscure still, until you try them) things.

There's also something even more huge than Umi itself: the misterious "Bigfish" project (don't search for meaningful resources links, at least if you're not fluent mandarin speaker) — an enterprise-grade wrapper around UmiJS, designed to enhance the capabilities of the framework with additional predefined and finetuned configurations and plugins. It serves as an internal framework for Ant Group, owning the world's largest mobile payments platform Alipay (and if there's something requiring more security and complexity than fintech, I definitely have no idea about it).

Not surprisingly, the Umi organisation on GitHub even has a repository for some AI tool which, I'd assume, will be analogous to Vercel's AI SDK.

People behind

The father of UmiJS and many other tools I mentioned is Chen Cheng, the person leading the Ant Group's front-end work. They're a very productive and insightful person and open-source enthusiast, to the point of curating one of the most popular JS awesome lists — Awesome JavaScript. I would follow their blog or anything willingly but looks like everything they write is behind some esoteric type of a popular Chinese paywall service so I had left my attempts. Their and their team's repositories are quite popular, especially among the Chinese audience (which is fair).

Doesn't all that mean that there is no smoke without fire? Would be too stupid not to check it.

Project example

So I have decided to play with UmiJS CLI and generate a project with a maximum staffed setup to take a look how the results look and feel like. There will be some short tutorial-like guidings and impressions shared, but to dig deeper you can explore the official docs (in English 🎉).

Prerequisites

The code for the described project can be found here. Umi suggests (and supports) quite a bunch of build tools and package managers, but the default one is pnpm, for which you'll need to have Node.js v18+ installed.

Project scaffolding

To scaffold a template app with UmiJS you need to run:

pnpm dlx create-umi@latest

which results in somewhat similar CLI dialog:

By selecting the Ant Design Pro template I had implicitly opted-in to using Umi Max which by itself can be considered a kind of metaframework configuration of Umi with a ton of shenanigans. This config comes with pre-installed and on-demand-enabled features like state management, analytics, charts, i18n, and more.

Project structure

The resulting project structure creates the impression of a well-thought-out and best-practices-based opinionated set of dedicated places for everything, starting from Ant-based components, and finishing with API mocks to help you with testing the app locally at any moment.

.
├── mock
│   └── userAPI.ts
├── src
│   ├── assets
│   ├── components
│   │   └── Guide
│   │       ├── Guide.less
│   │       ├── Guide.tsx
│   │       └── index.ts
│   ├── constants
│   │   └── index.ts
│   ├── models
│   │   └── global.ts
│   ├── pages
│   │   ├── Access
│   │   │   └── index.tsx
│   │   ├── Home
│   │   │   ├── index.less
│   │   │   └── index.tsx
│   │   └── Table
│   │       ├── components
│   │       │   ├── CreateForm.tsx
│   │       │   └── UpdateForm.tsx
│   │       └── index.tsx
│   ├── services
│   │   └── demo
│   │       ├── UserController.ts
│   │       ├── index.ts
│   │       └── typings.d.ts
│   ├── utils
│   │   └── format.ts
│   ├── access.ts
│   └── app.ts
├── README.md
├── package.json
├── pnpm-lock.yaml
├── tsconfig.json
└── typings.d.ts

Running the app

Running pnpm dev results in the following:

(A bit more about the ubiquitous MFSU thingy later...) And then in the browser, after slight loading with a fancy dedicated animated loader:

You'll get something like that:

Working with default UI generated in Chinese can be a bit intimidating:

No problem, we're seasoned vibe-coders, we can use Cursor to translate that!

Which helps a bit but not too much, unfortunately, as many parts come from integrated And Design components which require separate configuration to work with English:

That's a starting point. But we want more, aren't we? Umi got us covered guys, with something awesome that will help us think less and move faster.

Working with Umi CLI

The Umi CLI can be considered something similar to Angular CLI (for instance), with it's helpers and utils, but probably even much more that that. Here's what we've got:

build           build app for production
config          umi config cli
dev             dev server for development
help            show commands help
lint            lint source code using eslint and stylelint
setup           setup project
deadcode        check dead code
version         show umi version
plugin          inspect umi plugins
verify-commit   verify the commit message, which is usually used with husky.
preview         locally preview production build
run             run the script commands, support for ts and zx
generate        generate code snippets quickly

If you use max configuration (as I did during scaffolding, if you recall) you have many stuff (like linting) enabled by default, often implicitly (doh! 😖). It provides you with some coding best practices adhering with the opinionated automated style guide.

Interesting thing is the so-called microgenerators allowing you to scaffold some stuff like pages, data stores, or mocks easily.

I had tried my luck with pages. It looked a bit awkward and not very productive to be perfectly honest (I still needed to edit a lot of stuff manually) but it's a good way to enforce project's best practices, if you apply proper conventional configuration, I assume.

You can check my resulting awesome "About" page with an inevitable counter (fancy, I know 😎). Nothing too original but it's good to know that everything resides on its place right where you expect it to be.

Build and deploy

As we got used to, everything we built needs deployment. I hadn't found any popular deployment adapters for Umi unfortunately from a first glance (but I'm pretty sure there are some plugins for that 🤞), but Google gave me a bunch of seemingly easy deployment options targeted directly to Umi.

Long (and painful) story short, the UmiJS-dedicated tiiny.host deployment story is quite weird. First of all, you can deploy only by uploading your dist folder which neglects all the continuous deployment story. Second of all, if you replace the content of your website, it gets broken — looks like some files get cached or something. So I needed to recreate the project while changing it. Basically, it's just a simple one-off static site deployment service so probably it won't work for even lightly sophisticated and regularly updated scenarios.

Good thing is that you can just deploy your repo to Netlify using their pnpm configuration which is pretty straightforward and works like a charm. Well, not exactly like a charm, I'd need to correct the SPA routing quirks there definitely if I'd want to make it real serious, but that's probably for the other day.

My opinionated impressions

Here I come with a sheet of random thoughts borne by the results of my successful UmiJS testing.

🧙 In general, UmiJS provides developers with a clever Angular/RedwoodJS-like approach with out-of-the-box tools and scripts for streamlined web development in big teams. The corresponding inevitably huge amount of abstractions and hidden complexity brings a decent level of obscurity and magic, which might be good or bad, depending on the number of dedicated wizards of high level in your team.

㊙️ One problem these wizards will face though will be poor ~~wizarding library~~ documentation in English because all the development happens to be in Chinese and English support is quite secondary and lacking. However, you'll have a sufficient amount of general documentation in English anyway, and you'll always have access to the source code — because that's what them wizards do, right?

🏗️ The Umi's plugin system and API is quite interesting. You can do a lot with that. The approach is quite common for dev tools and in this case resembles both Vite and Nx with their extensibility and community orientation. There's a huge ecosystem of plugins of all sorts, and you can always complement them with your own (which is quite important for sophisticated enterprise development). I'd assume you could build pretty decent metaframework mechanisms with this flexible approach. At least, as I mentioned already, you have a bunch of thoughtful building blocks for that.

🎨 LESS is recommended by the Umi team officially as a styles preprocessor which is a bit weird and original. I didn't see it often (never, actually) in other tools (which doesn't lessen LESS's awesomeness, of course) and it creates some vibe of exclusivity and rebellion (as everything in Umi, TBH).

🗃️ MPA mode is quite obscure here. I wasn't able to quickly turn my demo app to an MPA as I planned, but I believe digging into configuration and plugins deeper would provide a solution. It's just it's a bit tough, meaning the focus is actually SPAs (though as I mentioned, the client-side routing has runtime quirks too requiring some further unsolicited setup which everyone likes, right?).

😶‍🌫️ TypeScript support is quite obscure and weird. My WebStorm's language service got fed up with that from time to time (which probably can be attributed to lack of out-of-the-box support for Umi in particular, but nevertheless). Again, the matter of configuration, but you know — we, spoiled-with-zero-config-tools developers of 2025, totally forgot what it actually means (along with the dirty words like "Webpack" and such).

🚫 The linting and formatting capabilities are quite cool in Umi — the default config provides you with a predefined strict and opinionated set of rules which of course can be extended (or limited) but which would be a good foundation for any developer team from the get-go. Not to mention the possibility to start your CI/CD pipeline from the very beginning and enhance it further on.

🔞 No React 19 support (yet?) with some expected "blood" in the browser console caused by corresponding deprecations. It's not a big deal, and I can imagine how harsh the potential migration may get, but still. If you're into shiny and new, that's probably not for you. But hey, what are you doing here then, on this chapter?!

💚 You can use Vue instead of React (via a dedicated configuration) even though the app becomes quite a contraption in this case. Vue is quite loved in the oriental web development tradition so it's not a surprise, and I'm really glad that, as opposed to many other metaframeworks, here you can have options, similar to the loved and only Astro.

⏳ Not very fast build time, both during development and for production even though it uses the so-called MFSU (I assume it's something like Module Federation Speed Up) under the hood. You can use esbuild as an alternative to webpack though, or even engage Mako itself (which I hadn't figured out how to use directly in Umi TBH — though there's a short note on it in the CLI, as you could see above), so maybe there's space for improvement here. Also using MFSU and its overheads on smaller projects is most probably leveled out by incremental build improvements for larger monorepo projects (which obviously get a lot of enablement via MFSU, as we saw).

🎓 Lack of learning resources around is definitely a problem for Umi. The only comparatively meaningful article about that I found worth attention was this LogRocket's writeup from 2020 (which validates the age of existence of the framework but confirms the limited adoption in the English-speaking world).

❓ The ideal target market (or ideal customer profile, as the startup bros say) for Umi is probably the folks who use tools like Angular or Next.js in production for huge enterprise apps built by huge multi-squad teams. The capabilities of opinionated project control the Umi ecosystem and plugins provide is exciting but probably a bit overwhelming for smaller teams and less demanding projects.

Conclusions

So this was just an overview (and a test drive, FWIW!) of the capabilities of this interesting tool used by lots of Chinese software industry monsters like Alibaba Cloud, Taobao, ByteDance, and many others.

The official UmiJS repository provides a whole bunch of examples of using UmiJS with multiple tools and packages (figured you could actually use it with Vite itself, or Remix, for instance). Check them out and decide for yourself.

Umi is definitely not a tool for everyone, but it's obviously a labor of love of many talented developers and I was really excited to dig deeper and get my hands dirty with that. Who knows, maybe one day I'll need to cheat on my other favorite tools and come back to this dragon — I'll be ready and glad to proceed tinkering with that. Because as Lao Tzu said,

A journey of a thousand Li begins with a single step

The cover photo by Thao LEE from Unsplash

How Bun can help to revive a Gridsome project

Fyodor — Tue, 11 Mar 2025 10:46:37 +0000

Starting from this year, builds for this website's code through my Netlify account began failing.

Frankly speaking, I'm still not quite sure why. It could be updates to the corresponding Netlify's Ubuntu image used for deployment. Or perhaps changes in the building workflows for Node (which tend to be unnecessarily extensive at times). It was hard to find the reason, and the community support there is quite slow (as with any community support — hard to blame the guys here).

Meanwhile, on the surface there were some objective reasons for this beast to fail eventually.

This website is built with Gridsome — one of the oldest static site generators, which is practically not maintained anymore. It causes some troubles for working with websites based on it, specifically the necessity to use Node.js v14 which is quite obsolete and poorly supported on all the public deployment platforms, including Netlify.

I tried to go away from Gridsome and migrate to something else a couple of times, but eventually decided to stick with it for now, because it's just smooth — and when something works smoothly, you shouldn't invite unwanted trouble (yeah, that's the old enterprise software developer speaking in me, I know). Moreover, there's some vintage feeling and nostalgia in using Gridsome these fancy days, especially as it is my digital shed — a place of power and not just some random website I maintain occasionally. I got some interesting letters about this site. I met some people using the same random Gridsome starter I found a million years ago. You know what I mean.

All in all, before eventually migrating to some boring modern technology, I decided to try using Bun with it instead of Node. I didn't come up with this idea completely out of nowhere; I had some interesting experience with Bun already, and the promise of zero-config development had proven to be a working approach for me. So I decided to test the hypothesis of letting Bun handle the obsolete Node project to see what it would yield.

Long story short, here's what I did to make it happen:

Update Netlify settings (just in case) to use the latest available Ubuntu image for deployment
Remove /node_modules, /dist, package-lock.json, and stuff like .nvmrc or analogues (it can override the Netlify build settings)
Add netlify.toml file (I didn't have it before, delegating configuration to the Netlify's default dashboard settings) with the following content:
```
[build]
command = "bun run build"
publish = "dist"
```

Update package.json with proper command for start (if you will):

"scripts": {
-  "start": "npm run develop",
+  "start": "bun run develop",
   "build": "gridsome build",
   "develop": "gridsome develop",
   "explore": "gridsome explore"
}

And that's basically it. After that, you should run bun install and test everything locally before pushing your code to production (and also generate bun.lock on the background, it's mandatory, and you need to push it to your repo too — Netlify uses this file to detect it needs to use Bun instead of Node). To my surprise, it worked perfectly, and I didn't need to do anything additional. There was some trial and error, but mostly due to my experimenting or testing the limits.

A couple of spotted tradeoffs after this update were:

Default http://localhost:8080/ dev server route doesn't work anymore, only the network-exposed one (http://192.168.1.114:8080/ in my case).
Hot reloading doesn't work very smoothly, which is bearable for content editing (which I mostly do) but probably will be annoying for code changes.

These are definitely not showstoppers but something I want to tinker with further a bit later. It's an affordable price for resurrecting the website.

In summary, I'd say that if you're a noble gentleman or a lady, you probably should go the migration route and use something like Astro (supports Vue components) or 11ty (lightweight and simple), or basically any static site generator or modern metaframework. But as a bit of a tech eccentric, I'll personally reside here for now, thanks to Bun (which I'm now quite motivated to adopt and research further).

The cover photo by Museums Victoria from Unsplash

Hasn’t dev.to become much slower lately? Or is it just me? 🤔

Fyodor — Fri, 07 Mar 2025 18:31:22 +0000

[Boost]

Fyodor — Mon, 27 Jan 2025 13:51:29 +0000

Let's talk metaframeworks

Fyodor — Mon, 30 Dec 2024 20:08:24 +0000

My interest in full-stack hybrid rendering and the corresponding tools was sparked by Rich Harris’ talk at Jamstack Conf 2021 titled “Transitional Apps” (you can find the transcription here, thanks to Geoff Rich). At the time, I was in the middle of my personal JavaScript fatigue (and SPA fatigue) escalation, and the ideas expressed by Rich resonated deeply with me. There wasn’t a sticky name for this approach yet, so “transitional apps” was a kind of first attempt at naming it.

Several years later, this idea is ubiquitous and is more or less consistently called “metaframeworks.”

As the name implies, a metaframework is something that’s built on top of a framework, yet it also represents the intrinsic essence underlying the conventional framework entity. Yes, I see you yawning already. Practically, it’s a set of tools that complement a UI framework (like React, Angular, Vue, or whatnot) with server-side functionality and deployment adapters. Sometimes, there are many more features included, but that’s the gist of it.

There are lots of tools in this category, and I’m pretty sure you’ve heard of them — if not used them already (or on a day-to-day basis, like myself).

There are also lots of opinions about them, with complexity and developer experience often sitting on opposite sides of the scale. The only objective truth is that metaframeworks are something we need to live with, whether we want to or not, and they are, in most cases, a great example of good engineering, with many open-source contributors participating.

What I personally love about the metaframework movement and its rise in popularity is the emphasis on progressive enhancement and the flexibility that new technologies bring, including the possibilities of building your own bespoke systems using battle-tested tools and templates.

I want to dig deeper into this whole metaframeworks story, and that’s why I’d like to humbly share with you two things I’ve just started to give myself a good kick into 2025.

The first is the open-source Encyclopedia of Metaframeworks in the form of an awesome-list, familiar to everyone. I’ve gathered the tools and links accumulated in my closet throughout the years, and I invite you to check it out and join the ride.

fyodorio / awesome-metaframeworks

A curated list of awesome resources related to software development with metaframeworks

Encyclopedia of Metaframeworks

A curated list of awesome resources related to software development with metaframeworks.

Metaframeworks

Next.js. React-based framework for building full-stack web applications.
Remix / React Router. Web standards focused React metaframework.
Nuxt. Vue-based framework for performant and production-grade full-stack web apps.
Quasar. The enterprise-ready cross-platform Vue framework.
SvelteKit. A framework for rapidly developing robust, performant web applications using Svelte.
SolidStart. Fine-grained reactivity goes fullstack.
TanStack Start. Full-stack React framework powered by TanStack Router.
Analog. The fullstack Angular metaframework.
Qwik City. Qwik-based set of tooling for building extremely performant full-stack applications.
RedwoodJS. Batteries-included React- and RSC-based full-stack web framework for startups.
…

View on GitHub

The second is the Metaframeworks Records newsletter. This will be a regular, focused dive into the world of metaframeworks and the ecosystem around them — tools, news, releases, people, and so on. You’ll hardly find pompous odes to metaframeworks there; rather, you’ll find an unbiased view of the topic and objective, multifaceted opinions.

All in all, I hope some of these resources might be of use to you, and maybe you’ll even be willing to contribute to them — whether by providing insightful submissions for the encyclopedia or by dropping me interesting relevant findings from around the web via email.

With that, remember that the truth is always somewhere in the middle, and it tastes not like shiny Twitter influencer tarts but rather like your home-cooked, granny-recipe cakes.

Happy new year 🎄

The cover photo by Carter Yocham from Unsplash