I need you to take a moment and think about the second. It is the SI unit for time.

The International System of Units defines it with exact precision: the duration of exactly 9,192,631,770 periods of the radiation corresponding to the transition between the two hyperfine levels of the ground state of the caesium-133 atom. Not approximately, not roughly, exactly! Every laboratory in the world, every telecommunications system, every financial settlement network, every GPS satellite agrees on what a second is. That agreement did not happen by accident. It happened because civilisation decided that a unit underpinning so much commerce and science was too important to leave undefined.

The token is the fundamental unit of the AI economy. It determines what you pay when you use an AI service. It determines how much information a model can hold in memory at once. It shapes how developers build applications, how researchers design experiments, how businesses forecast costs, and how governments procure AI infrastructure. Billions of dollars of contracts are being written in tokens. Entire technical architectures are being designed around tokens. The AI industry has staked its commercial model on the token.

Not in any way that holds across vendors or survives a model update. The most important unit in one of the most consequential industries in the world is, at this moment, undefined.

That is the problem I'm here to bitch about.

To understand why the lack of a standard matters, you first need to understand what a token actually is in technical practice, and why the answer is less satisfying than it should be.

Modern AI language models do not process text the way humans read it, word by word or letter by letter. They operate on chunks of text called tokens, produced by a preprocessing algorithm called a tokenizer. The tokenizer takes raw text and segments it into sub-word units,  fragments that may be whole words, parts of words, punctuation marks, or individual characters, depending on context.

The most widely used family of tokenization algorithms is called Byte Pair Encoding, or BPE. It works by analysing a large corpus of text, identifying the most frequently co-occurring character sequences, and progressively merging them into single vocabulary entries. The resulting vocabulary (typically between 32,000 and 100,000 entries) becomes the model's alphabet. Every piece of text it will ever see must be expressed in terms of that vocabulary.

The rough rule of thumb you will encounter across the industry is that one token equals approximately four characters of English text, or about three-quarters of a word. OpenAI, Anthropic, and Google all land somewhere near this average for standard English prose. But that similarity is coincidence, not coordination. Each lab trained its tokenizer independently, on different corpora, with different vocabulary sizes and different algorithmic choices. The word "unbelievable" might be one token in one system and three in another. A space before a word can change how it tokenizes. Emojis, code syntax, and non-Latin scripts all behave differently across systems.

There is no shared definition. There is no reference standard. There is no conversion factor published by any of the major labs. There is just a loosely similar engineering approach producing meaningfully different outputs, all marketed under the same name.

This would be a minor technical curiosity if tokens were only used internally. They are not. Tokens are the unit of commercial exchange in the AI industry, and the consequences of their non-standardisation are concrete and growing.

When Amazon charges you per kilowatt-hour, a kilowatt-hour is a kilowatt-hour. When a cloud provider charges per gigabyte of storage, a gigabyte is a gigabyte. When OpenAI charges per million tokens and Anthropic charges per million tokens, those are not the same million. A business trying to forecast AI infrastructure costs across providers is comparing currencies without an exchange rate, and nobody is publishing one. Cost modelling exercises that treat vendor tokens as equivalent are with all due respect, wrong.

Context window comparisons are meaningless without a common unit. When one model advertises a one-million-token context window and another advertises two hundred thousand tokens, those numbers cannot be directly compared. The model with the larger window may actually process less real-world information if its tokenizer is less efficient. Cross-vendor performance benchmarks are contaminated by the same problem. The industry talks about tokens as if they are interchangeable. They are not.

Tokenizers change between model versions. The tokenizer underpinning GPT-3 was probably not the same as GPT-4's. Systems calibrated against one version may behave differently after a model update. Not because the model's reasoning changed, but because the unit of measurement shifted underneath the application. There is no versioning standard, no changelog obligation, no notification requirement. Developers absorb this instability silently.

Any developer building a RAG pipeline, a summarisation system, or an agentic workflow has to make token assumptions somewhere. In how they chunk documents, manage context, and estimate costs. Those assumptions are vendor-specific and version-specific. Switching providers is not just a business negotiation; it is a re-engineering project, partly because the fundamental unit does not transfer. This is not neutral market competition. It is incompatibility masquerading as differentiation.

Of all the consequences of token non-standardisation, one deserves to be named loudly and separately, because it is the one most likely to be treated as a footnote when it should be a headline.

Tokenizer design is not a neutral technical decision. It is a decision about whose language is treated as the default, whose vocabulary gets compressed efficiently, and whose community pays a structural premium for access to AI.

English was the dominant language in most tokenizer training corpora. The result is that English text tokenizes efficiently. Roughly one token per four characters. A model with a two-hundred-thousand-token context window can hold a substantial amount of English text in memory. The same model, processing an equivalent amount of information expressed in Yoruba, Igbo, Hausa, or Swahili, may consume two to three times as many tokens to convey the same semantic content. The context window effectively shrinks. The cost per idea expressed rises. The API bill for the same cognitive task is higher.

This is not an edge case. It is not a minor inefficiency affecting small communities on the periphery of the AI market. Africa has over two thousand languages and a rapidly growing technology sector. Nigerian startups are building AI-powered products. Kenyan developers are integrating language models into financial services. African governments are beginning to procure AI infrastructure at scale. Every one of them is doing so from a structurally disadvantaged position. Not because of application-layer decisions or pricing tiers, but because of tokenizer design choices made by engineers in San Francisco and London who were not optimising for Igbo vocabulary.

This is not intentional discrimination. It is the emergent consequence of building a global standard on a narrow corpus. But the effect is the same. And unlike many inequities in the technology industry, this one is relatively tractable. It is a solvable engineering and policy problem. It just requires the communities most affected to be in the room when it is discussed. Currently, they are not.

It is worth being honest about why this problem persists rather than simply noting that it does.

The commercial disincentive is real. Proprietary tokenizers create switching costs, and switching costs are moats. A developer who has built their application around one vendor's token assumptions has an implicit reason to stay. Standardisation would erode that lock-in, which is precisely why no major lab has volunteered to lead the effort.

The technical complexity is also real. Agreeing on a single tokenization standard would require negotiating vocabulary size, segmentation algorithm, handling of special characters, multilingual coverage minimums, and update protocols. It would require resolving genuine tradeoffs. A tokenizer optimised for multilingual equity may be slightly less efficient for English, and vice versa. These are tractable problems, but they are not trivial ones.

And standards bodies move slowly. The ITU took decades to standardise telecommunications protocols. The internet's foundational standards emerged through years of rough consensus and running code. The transformer-based language model era is less than a decade old in practical deployment terms. The argument that formal standardisation is premature is not entirely without merit.

But none of these obstacles is an argument for waiting. They are arguments for starting. The window in which the standard can be shaped (before it hardens around assumptions that were never designed with non-English communities in mind) is open now. It will not stay open indefinitely.

Standardisation does not require every lab to use the same tokenizer. It requires common measurement and mandatory disclosure. Those are different, and considerably more achievable, demands.

A neutral standards body (NIST in the United States, ISO/IEC JTC 1 internationally) could define and maintain an open-source reference tokenizer: versioned, frozen at each release, publicly auditable. Vendors would not be required to use it in their models. They would be required to publish the conversion factor between their tokenizer and the reference, across a defined set of languages. This is analogous to how industrial measurement standards work. You do not require all manufacturers to use the same ruler. You require them to calibrate against a common standard and disclose the result.

Even before a reference tokenizer exists, regulators could require vendors to publish token efficiency ratios across languages relative to a declared baseline. The European Union's AI Act, already the most substantive AI regulatory framework in force, is a plausible vehicle for this kind of disclosure requirement. The UK's AI Safety Institute and the United States' NIST AI Risk Management Framework are others. These mechanisms exist. They need to be pointed at this problem.

African governments and large enterprise buyers do not need to wait for international standards bodies. Procurement standards for AI services can require vendors to disclose token efficiency ratios across relevant languages as a condition of contract. If the Nigerian government, the Kenyan government, and the South African government all made this a procurement requirement, the major AI vendors would publish the data within a quarter. Procurement is a form of regulation that does not require legislative consensus.

While formal standardisation lags, the research community can publish systematic cross-tokenizer equivalence tables — empirical exchange rates across major models for different languages and content types. These would not be standards, but they would be working tools. African AI research institutions are well-positioned to lead this work, and doing so would simultaneously raise the profile of the language equity dimension in international standards conversations.

The token is not a technical detail. It is the unit of account for an economic system that is rapidly becoming critical infrastructure. For businesses, governments, researchers, and individuals worldwide.

We have never allowed critical infrastructure to self-define its own units of measurement without oversight. We do not let electricity providers define what a kilowatt-hour means. We do not let pharmaceutical companies define their own dosage units. We do not let financial institutions invent their own currencies and charge for services denominated in them without disclosure. The principle that commercial units of exchange must be standardised, transparent, and auditable is not controversial. It is foundational to how functional markets work.

The AI industry is not exempt from this principle. It is simply young enough, and has moved fast enough, that the institutional response has not caught up. That gap will close. The question is whether it closes with the right people at the table.

The communities with the most to lose from a bad standard being locked in are the ones building in Yoruba, Igbo, Amharic, and Hausa. They are the ones whose context windows are already effectively smaller, whose API costs are already structurally higher, and whose developers are already building on a foundation that was not designed with them in mind. They are also the ones currently least represented in the forums where AI infrastructure standards are being shaped.

The second was defined because precision mattered. The token will be defined eventually. By markets, by regulation, or by formal consensus. The only question is whether the communities most affected by that definition will have a seat at the table when it happens.

That seat will not be offered. It will have to be claimed.

A unit of exchange nobody defined. We need to standardize the AI token.

“Change is good. And you never know exactly what to expect, but if you go with the right attitude into that, then everything will be fine.”

Jurgen Klopp will live forever! At least to every Liverpool FC supporter. He's one of the most integral and significant figures in the clubs modern history, and it's not even because he delivered the trophies he promised. He reshaped the clubs entire identity, turning us from doubters to believers. With charisma and authenticity, he became a symbol of hope and pride for the club and city, so much so that he was awarded the Freedom of the City of Liverpool, a rare honor for a foreign national.

The news of him announcing his departure at the end of the 2023/24 season came as a heavy shock to every supporter, but when he said goodbye to Liverpool in May 2024, his parting words carried a lesson that stretched far beyond football.

It was the end of an era. His departure was a moment of uncertainty, but also of possibility. And that’s exactly the point he made: the way we approach change determines whether it feels like a threat or an opportunity.

Organizations face the same challenge. Markets shift, leadership changes, technologies disrupt, and industries evolve. In these moments, the strength of an organization doesn’t lie only in strategy or structure, it lies in culture. Culture sets the emotional tone for how people respond to change, and as Klopp reminded us, a positive mindset can turn the unknown into something extraordinary.

Change is the one constant every organization faces. In football, it can come through new managers, fresh tactics, or a shift in ownership. In business, it shows up as market disruptions, new technologies, or leadership transitions. Whatever form it takes, change always stirs the same emotions: uncertainty, fear, and even resistance.

Why? Because change threatens comfort. People naturally hold on to what’s familiar, even if it no longer serves them. Liverpool fans knew what Klopp brought: stability, identity, belief. The thought of moving into an unknown future without him was unsettling. It’s no different in organizations: employees worry about losing roles, influence, or clarity when change arrives.

But here’s the truth Klopp reminded us of: change itself isn’t the problem, our mindset towards it is. This is where organizational culture makes all the difference. A healthy culture can turn change into a launchpad for growth and innovation. A weak culture, on the other hand, magnifies fear and fuels resistance.

The Role of Organizational Culture in Navigating Change

At the core, organizational culture is simply “the way we do things here.” It’s the shared beliefs, values, and attitudes that shape how people respond when challenges arise. In times of change, culture becomes the invisible hand guiding whether people dig in their heels or lean forward with curiosity.

Klopp understood this intuitively. From his very first press conference at Liverpool, he spoke not only about tactics but about belief. He wasn’t just building a team, he was shaping a culture. One that embraced hard work, resilience, and above all, trust in the journey. That culture transformed a club that had grown used to disappointment into one that expected and eventually achieved greatness.

The same applies in business. When a company’s culture frames change as disruption, people retreat into fear and resistance. But when the culture frames change as opportunity, it sparks innovation, collaboration, and growth. Culture doesn’t eliminate uncertainty but it gives people the confidence to step into it with a positive mindset.

Lessons from Klopp: Leadership, Mindset, and Transition

Jürgen Klopp’s leadership was never just about winning matches. It was about how he carried himself, how he spoke to his players, and how he connected with us, the fans. He made people believe. When results didn’t go their way in the early years, he didn’t hide from it, he reframed the setbacks as part of the journey. That attitude seeped into the team and eventually into the culture of the entire club.

This is the essence of leadership during change: how you frame the moment shapes how people experience it. Klopp turned departures, defeats, and even his own farewell into opportunities for growth. He didn’t deny the difficulty of change, he gave people hope in spite of it.

We see the same pattern in business. Companies like Netflix thrived because they embraced transformation. Moving from DVDs to streaming to producing their own content. Contrast that with Kodak, which clung to the old model despite inventing digital photography, and collapsed under its own resistance to change. The lesson is clear: leaders who approach change with vision and optimism pull people forward and those who resist or fear it drag their organizations backward.

Klopp modeled this truth on one of the biggest stages in the world. His message (that attitude matters more than certainty) is as relevant in the boardroom as it is on the touchline.

Practical Takeaways for Leaders & Organizations

So what can leaders take from Klopp’s farewell message and apply in their own organizations? A few key lessons stand out:

Frame Change as Growth, Not Loss: People naturally fear what they might lose in a transition. Leaders must shift the narrative: what’s possible, what can be gained, what opportunities lie ahead.

Build a Culture of Resilience: Success isn’t about avoiding setbacks but learning from them. Celebrate progress, even in small steps, and remind people that setbacks are part of the story, not the end of it.

Model Optimism and Authenticity: Just as Klopp’s charisma and honesty won hearts, leaders must show belief in the future. Culture starts at the top. If leaders project fear, teams absorb it, if they project confidence, teams rise with them.

Keep the Human Connection at the Center: Klopp wasn’t just a tactician; he was a connector. In organizations, change feels less threatening when people feel seen, heard, and valued. Communication and empathy are just as critical as strategy.

Honor the Past, But Move Forward: Klopp always respected Liverpool’s history while steering it into a new chapter. Leaders should acknowledge what has been built, then invite people into the next story.

In essence, the real task of leadership in times of change is not controlling the unknown. It’s shaping the mindset with which people walk into it.

When Jürgen Klopp stood at Anfield and addressed the club, he wasn’t just offering comfort (because him leaving was a lot to take in) he was sharing a timeless truth about leadership.

Change is rarely easy. It disrupts routines, unsettles certainty, and demands courage. But as Klopp showed, the difference lies in culture and mindset. With the right culture, change becomes less about endings and more about new beginnings. With the right attitude, the unknown stops being something to fear and becomes something to embrace.

We can already see this truth playing out at Liverpool. Klopp’s successor, Arne Slot, stepped into one of the most daunting jobs in football, following a beloved figure who reshaped a club’s identity. Yet, instead of being crushed by the weight of expectation, he leaned into Klopp’s philosophy and delivered the club’s historic 20th league title in his very first season. That achievement alone showed that change, when embraced with courage and belief, can lead to something extraordinary. With humility, adaptability, and his own fresh ideas, Slot has shown that change, when embraced positively, can continue the story rather than end it. Now, as a new season begins, the club has faced another wave of transition: several key players have departed, and exciting new signings have arrived. Instead of crumbling under the weight of uncertainty, Liverpool has shown promising signs of adapting, blending fresh arrivals with the existing core to create a team that looks ready to build on last season’s success.

Organizations that thrive are not those that avoid change, but those that welcome it with optimism, resilience, and belief. Just as Klopp turned doubters into believers, leaders everywhere have the chance to shape cultures that see change not as a threat, but as the path to something greater.

Change is Good: Building a Culture That Welcomes the Unknown

So I recently stumbled across a fascinating article on AI News discussing how AI capabilities are advancing faster than hardware, with decentralization suggested as a potential solution to bridge the gap. You can check it out here. TLDR? That's fine. To summarize it, the computing costs involved in training large AI models is very high, and it's expected to rise in the coming years. We're looking at numbers in 12 figures. Basically, only the big boys will be able to afford it (Microsoft, Google, Meta etc... you know them). The risk of centralization is concerning, and while decentralization offers a promising solution, I think the challenges of implementing it on a large scale still remain. It’s a very insightful read, and I’d like to pen down my thoughts on this, so stay with me.

Introduction: The Rise of AI and Its Computational Demands

AI has pretty much become a cornerstone of modern technology, with tools like ChatGPT, Gemini and DALL-E integrating into everyday tasks. However, as AI capabilities grow, so do the computational demands. Researchers at Epoch AI discovered that the cost of the computational power needed to train AI models is doubling every nine months. This rapid increase means that by the end of the decade, just the expenses for hardware and electricity alone could reach billions, not even considering other costs like employee salaries.

The article correctly points out that big tech companies currently dominate the AI field, raising concerns about centralization, control over innovation, and data privacy. 

When a few large companies control most of the computational resources and AI technologies, they can dominate the market, reducing competition. This monopolistic control can limit innovation by making it difficult for smaller players to enter the field or challenge the status quo. Also, this level of control can also increase the risk of misuse, as these companies have the financial means to drive AI advancements on their terms. 

Centralization not only stifles competition but also creates the potential for monopolistic control over AI's future direction, raising concerns about the equitable development and application of AI technologies.

Just as in other industries, decentralization is seen as a promising solution to the issue of centralization. Technologies like Aigarth (Qubic’s Layer 1 blockchain) offer a way to spread computational power more evenly among users, potentially making AI development more accessible. This could lower entry barriers, reduce costs, and allow more innovators to participate, moving the industry away from the dominance of big tech companies. A decentralized approach could lead to healthier competition, encouraging a diverse range of advancements in AI.

By enabling many contributors to shape AI’s future, decentralization can ensure development reflects a broader set of values and perspectives. It also helps distribute computational resources, which can lessen monopolistic control and address data privacy and ethical concerns. However, implementing decentralized AI comes with challenges like scalability, security, and efficiency, which need to be carefully managed to achieve its full potential.

In as much as decentralization has potential, it also comes with practical challenges. Decentralized computing faces significant issues with scalability, efficiency, and security. Transitioning from centralized to decentralized systems is complex and requires a deeper look into these obstacles.

Scalability: Distributing resources across many nodes in a decentralized system can be difficult to manage, and as the number of nodes increases, network latency can become a significant issue. Communication between nodes can become slower, which end up impacting the overall performance and efficiency of the system.

Security: Decentralized AI networks can be susceptible to attacks. For example an attacker can create multiple fake nodes to gain control over the network. If successful, they might manipulate data or disrupt the training process. Ensuring robust security protocols to detect and prevent such attacks is critical.

Efficiency: To ensure reliability, decentralized systems often duplicate data across many nodes. While this makes the system more robust, it can waste computational and storage resources. For example, in a decentralized AI network, if every node keeps a full copy of the dataset, it leads to unnecessary duplication and higher storage demands. So, are we really saving costs in the grand scheme of things?

Coordination: Personally, I think this is one of the biggest challenges with decentralized systems. In fact I think true decentralization is a myth. It's simply not possible. As humans, without a central authority to dictate decisions, it can be difficult to ensure that all participants are working towards a common goal. Different participants may have conflicting rules or interpretations and coordination can be time-consuming and resource-intensive. For instance, in a decentralized AI system, if different nodes propose changes to an AI model, reaching agreement on which changes to implement can be complex. Disagreements among nodes can lead to delays and inconsistencies in the model’s development. Also, maintaining communication and consensus protocols in decentralized systems can be complex. For example, Qubic's "useful Proof-of-Work" (uPoW) involves not just securing the network but also performing useful computations. Designing protocols that balance security, efficiency, and useful computation is challenging and requires sophisticated algorithms and constant management.

Concerns about AI centralization include issues like limited competition and potential misuse of power. Decentralization is proposed to address these by distributing control and resources more broadly. However, it is not a complete solution on its own, as it introduces challenges such as increased costs from data duplication and complex coordination.

A more balanced approach might be necessary for the future of AI. Combining the efficiency and cost-effectiveness of centralized systems with the innovation and fault tolerance of decentralization could offer a better overall solution. This hybrid strategy could help foster continued innovation, ensure security, and promote fairness within the AI ecosystem.

A case in point is open-sourcing AI. Promoting open-source AI initiatives can foster collaboration, transparency, and accessibility. This can help democratize AI development and reduce the concentration of power in a few large corporations. Also, a well-designed regulatory framework could help address concerns relating to data privacy, bias, and the misuse of AI. This would provide a level playing field and encourage responsible development.

Navigating the Future of AI: The Promise and Challenges of Decentralization

Code abstraction is one of the foundational concepts in programming that allows developers to manage complexity and improve the maintainability of their software. At its core, abstraction is about simplifying the way we interact with complex systems by hiding unnecessary details and exposing only what is essential. This concept is critical in both small projects and large-scale software development, as it enables the creation of code that is easier to understand, maintain, and scale.

Imagine you’re using a car. You don’t need to know the intricacies of how the engine works to drive it. You just need to understand the basic controls: steering, braking, and accelerating. This is abstraction in action. The complexities are hidden, allowing you to focus on what matters most.

Abstraction isn’t just a fancy term thrown around in programming—it’s a practice that brings tangible benefits to your codebase. Here are some solid reasons why code abstraction is crucial:

Simplifies Complex Systems: Abstraction hides the intricate details of a system, presenting only what is necessary. This allows developers to focus on the task at hand without getting bogged down by unnecessary complexity.

Improves Code Maintainability: Well-abstracted code is easier to maintain. By breaking down complex functions into smaller, more manageable parts, you can update or fix issues in one part of the code without affecting the rest of the system.

Enhances Collaboration: In team environments, abstraction helps different developers work on different parts of a project without stepping on each other’s toes. By creating clear boundaries through abstraction, team members can work independently, knowing their changes won’t inadvertently disrupt other parts of the system.

Promotes Reusability: Abstracted code can often be reused across different parts of the application or even in other projects. By isolating specific functionality, you can create reusable components that save time and effort in future development.

Reduces Redundancy: By abstracting common functionalities, you can avoid writing duplicate code. This not only saves time but also reduces the likelihood of introducing bugs, as you’ll only need to maintain and update the code in one place.

While abstraction is a powerful tool, it’s essential to know when to use it and when it might be unnecessary or even harmful.

Complex or Repetitive Code: If you find yourself writing the same or very similar code multiple times, it’s a good indication that abstraction might be beneficial. Abstracting repetitive code into a single function or module can save time and reduce errors.

Large Projects: In larger projects with multiple developers, abstraction helps create clear boundaries and responsibilities, making the project more manageable and reducing the chances of conflicts.

Future Scalability: If you anticipate that your codebase will need to grow or evolve, abstracting certain components can make it easier to add new features or make changes in the future.

Over-Engineering: Sometimes, developers can get carried away with abstraction, creating layers of complexity that don’t add value. If a piece of code is simple and unlikely to change, abstraction might be unnecessary.

Early Stages of Development: During the initial stages of a project, it’s often better to focus on getting a working prototype rather than abstracting everything from the start. Once the project is more stable, you can then identify areas that would benefit from abstraction.

Code abstraction is a crucial practice in programming that simplifies complex systems, enhances code maintainability, and promotes reusability. By understanding when to abstract and when to avoid it, you can strike a balance that leads to cleaner, more efficient, and scalable code. As with any tool, the key to successful abstraction lies in knowing when and how to apply it effectively. By doing so, you’ll be able to write code that is not only easier to work with today but also more adaptable to the needs of tomorrow.

Code Abstraction Demystified

In the ever-evolving landscape that is the Javascript ecosystem, TypeScript stands as a formidable enigma, enticing developers with promises of enhanced code quality and safety, yet often shrouded in the mystique of a steep learning curve that hinders productivity. Is TypeScript an impediment or a stimulus for growth in the ever-changing web development landscape? This article offers a firsthand evaluation of the library, drawing from my own experiences working with this tool.

TypeScript has rapidly gained popularity in the world of web development as a statically typed superset of JavaScript. It provides various benefits that make it an appealing alternative for many developers. However, as with every technology, it has downsides. Some of the benefits and drawbacks are discussed below.

Honestly, I think this is one of the most fundamental benefits of TypeScript. The language incorporates static typing, a practice of specifying data types for variables and function parameters at compile-time, before the code is executed, hence reducing the chances of runtime errors. This means that you can catch issues like trying to add a string and a number or accessing properties on undefined objects before your code ever runs, making your code more robust and reliable.

There's simply not much else one can say about this. If you make use of the language regularly and use VSCode as your IDE, then you'll definitely understand this. TypeScript provides a rich set of tools and support for code analysis, auto-completion, and refactoring. This enhances developers productivity as a result.

When you refactor or make significant changes to your codebase, static typing ensures that you're less likely to introduce subtle bugs. The type system helps you ensure that your changes are consistent with the expected data types throughout your code.

I personally struggle with advanced typescript. I understand that these are powerful features for expressing intricate data structures and relationships, but I feel like in certain scenarios, they can slow down development time due to the potential for code complexity and reduced readability. Also, I believe codebases with an abundance of complex types may become harder to maintain over time. When requirements change or when developers need to make modifications, understanding and updating complex type definitions can be a time-consuming and error-prone process.

When working with libraries or APIs that do not include type definitions, you may need to build custom type definitions or utilise 'any' types, which negates some of TS's advantages. Not all libraries or APIs are accompanied by type definitions. In such cases, developers often resort to using the 'any' type to bypass TypeScript's type checking. While this lets you to interact with the library or API, it undermines TypeScript's type safety because 'any' types do not support type verification or inference.

So there has been a lot of debate in the javascript community when it comes to the experience with Typescript. I think the perception of TypeScript as a technology that people either love or detest depends on a variety of factors, including personal preferences, project requirements, and familiarity with the language. Here's a breakdown of these factors:

Projects with large development teams or those with large-scale applications may be better suited for TypeScript. Contrarily, the expense of implementing TypeScript may not be justified for smaller or less complicated applications, creating a negative reputation.

Like any technology, personal preferences play a significant role. Some developers may prefer the flexibility and lightweight nature of JavaScript, while others may appreciate TypeScript's type safety and tooling support.

Developers who are resistant to change or accustomed with their current tools and workflows may be more inclined to have negative feelings toward TypeScript simply because it represents a divergence from their established practices.

I wouldn't simplify the apprehensions around TypeScript to a mere matter of skill level. However, it's undeniably true that one's proficiency and familiarity with the language often correspond with their fondness or aversion to it. Seasoned developers, well-versed in TypeScript's intricacies and merits, tend to find greater satisfaction in working with it.

For those, like me, who occasionally grapple with TypeScript's nuances, patience is key. Just as it took years of continual learning and practice to develop a genuine appreciation for JavaScript, a similar journey may unfold with TypeScript. If your experience mirrors mine, don't anticipate a complete mastery of TypeScript within a few months. Instead, embrace the gradual process of understanding and acclimatising to its unique qualities.

I firmly believe that TypeScript delivers substantial benefits that far outweigh any potential drawbacks. While it may appear to slow down the initial development process, the advantages it offers from a maintenance perspective are invaluable. Personally, I have a simple rule of thumb: I am always willing to trade off some development speed if it translates to reduced time spent on maintenance and debugging down the road.

Whether TypeScript is the right choice for your project depends on you and your team's familiarity with it, the project's complexity, and your willingness to invest in the learning curve. Understanding these pros and drawbacks will help you make an informed decision for your next web development venture.

The Typescript Wrangle: Skill Barrier or Opportunity?

In the 2022 Stack overflow developer survey, over 2/3 (about 64%) of the developers that have used the framework love it. Yet only about 5% of developers who do not already use the technology have expressed interest in developing with it. I was honestly curious as to why that's the case. I've been working with Nuxt.js for over a year now. My first project was a simple weather app. It's probably my most used frontend framework, so it only makes sense that my first tech related article is about it. I'll try my best to give you an insight into the framework, a bit of how it works, why you should probably give it a try in your next project, and when I think it's probably not recommended.

Nuxt is an "intuitive" framework used for building simple and powerful Vue.js applications. It's a higher-level framework that offers a simpler development environment for universal and static Vue applications. The framework comes with a lot of features that improve developer experience and productivity. Some of the features being:

Server side rendering (SSR) and Static Site Generation (SSG)

The technology is composed of different core packages.  The core engine (Nuxt), bundlers (Vite and Webpack), server engine (Nitro), command line interface (Nuxi) etc. These packages abstract all the intricate pre-coding setups and configurations, allowing you to completely concentrate on creating a fantastic Vue.js web application. I'll be discussing the benefits and some limitations (at least in my opinion) of using Nuxt in the next segment.

"Development of Javascript applications has already been made simpler by Vue. So why should I choose Nuxt? ". Well...

One of the significant benefits of using Nuxt is SEO. Nuxt resolves the issues we tend to encounter when working on SPAs. From web performance and routing to enhanced meta tags. If you've developed or worked on Single page applications (SPA) you would know that one of their biggest drawbacks is SEO. This is because when a browser loads an SPA (say built with React or Vue), the server returns only barebones HTML without any rendered content. It sends a new request to get the JavaScript bundle, which is then run on the browser to render content. That's where SSR comes into play. Like the name implies, scripts are being run on the server that generate fully rendered HTML on page load. This results in faster page loads and optimal performance and SEO because all of the content is already rendered on the server and the application is properly indexed by search engines.

Nuxt by default employs SSR to deploy applications,  however you can still generate a static site with Nuxt if you want to avoid the server requirement while still reaping most of the SEO benefits. Nuxt makes use of vue-meta (a HTML metadata manager for Vue.js) internally to generate the contents of the <head> tag. This means that SPAs generated with Nuxt tend to be more "meta-enhanced" than our typical SPAs. 

Overall, sites built with Nuxt are more performant and SEO-friendly. 

If you're a developer, this is probably not the first time you've heard of code splitting. But for the benefit of those that haven't, it simply means dividing your code into numerous smaller bundles, commonly referred to as "chunks," which you ship to the browser. Basically just splitting your JavaScript code into separate files. The aim is to speed up the initial loading speed of the application, hence improving performance.

Nuxt automatically handles code-splitting for your application using its Webpack configuration. It does this every time you run the production build command (nuxt build/nuxt generate), producing code-split points for each route. For each page's "chunk," it only loads the components and dependencies that you need.

One of the really nice features about Nuxt is how it sorts out all the pre-configuration needed to create production-ready Vue applications. For example, in a large Vue app, the routing configuration may become lengthy. When using Nuxt, all you have to do is create or drop your Vue components into the pages folder, and Nuxt will automatically create your routes without any configuration.

Code organization becomes increasingly crucial as your application grows and scales-up. By default, Vue provides an asset and components directory, which is great, but Nuxt takes it further and configures extra folders like:

Plugins: For Vue & other Js plugins and to inject functions or constants before instantiating your Vue app

Middleware: Similar to plugins, only that the functions are executed prior to rendering a page or layout.

Modules: Functions that are called sequentially when booting Nuxt

This "dogmatic" approach makes switching from one Nuxt application to another and getting up to speed really straightforward.

Modules are functions that are called sequentially when booting Nuxt. The framework waits for each module to finish before proceeding. In this way, modules can customize almost any aspect of your project. What I really love about modules is that they can be incorporated into npm packages. This makes them reusable across projects and shareable with the community. Seen a use case that hasn't been covered in Nuxt? Create a module and make it open source. 

Some other benefits of using Nuxt include:

Easy setup using the command line interface (Nuxi) with the starter template

Nuxt makes it possible for you to get the most out of your universal web app without a server.

At the core of things, it's still just a Vue app, so you get all of those benefits. I honestly consider Vue the best Js framework. Simple, fast, lightweight, solid architecture, reactive two-way binding, not Jsx (although it has the option if that's your preference), etc.

For a relatively small community, the documentation is quite comprehensive.

Just like every framework and technology out there, Nuxt has its limitations and caveats. But before I go into them, there's something fundamental I need you to understand. Nuxt requires a slightly different way of thinking than Vue. The primary distinction being that Vue runs exclusively on the client-side, which isn't the case for Nuxt. This can lead to some silly bugs and errors if not properly understood. For example, on the server-side, the app is running on Node.js, hence we do not have access to some javascript objects like window, local storage, document, navigator and all the other objects and functions that are provided by the browser. These objects can only be accessed via the client-side lifecycle hooks beforeMount() and mounted(), so attempting to utilize them in any other hook could introduce bugs or logical errors. Vue does not have these problems because it is always running on the client.

Alright, back to the caveats. Here are some of the challenges I've encountered while working with Nuxt

Some Vue plugins don't function properly with Nuxt. The reason being that they weren't designed with servers in mind. The workaround for some would be to add a client constraint or check (e.g. process.client) so the functions only trigger on the client side.

It's gotten better with recent updates and releases, but debugging in Nuxt can be very difficult sometimes, especially on the server side and when generating a build. When some things break, it may be really painful to try to figure out what exactly went wrong. This is a problem that gets increasingly frustrating as your project gets bigger and more complex. The console will typically report an error, but it doesn't always provide you with any relevant information. There are different ways one can go about solving it depending on the issue. VS Code can be configured to make debugging a little bit simpler, but from a general perspective, it's a pain.

Another drawback I tend to experience when using Nuxt is setting up custom libraries. You might need to spend more time on it than you anticipated. So if you're working on a tight development timeline, it can get uncomfortable.

Nuxt is a very effective and powerful framework that offers so much and makes your life as a developer very easy. It has a lot of helpful features that make creating front-end applications simpler. However, it's not the best choice for all types of client-side applications. Depending on the objectives, specifications, and requirements of the project, you, the developer, ultimately decide which framework is more suitable because no one understands the scope of the project better than you. I usually recommend it when your project requires sustainable SEO (e.g. a blog page or company website), authentication (Nuxt middleware handles this properly) or a project with multiple pages (you would really appreciate the layout and pages directory). But if you're working on an in-house project (say an admin dashboard), a custom widget for a website, or a simple SPA that doesn't require SEO performance, you should probably just stick to Vue. It's scalable, lightweight and tends to handle all that in a much better way.

Articles

A unit of exchange nobody defined. We need to standardize the AI token.

Change is Good: Building a Culture That Welcomes the Unknown

Navigating the Future of AI: The Promise and Challenges of Decentralization

Code Abstraction Demystified

The Typescript Wrangle: Skill Barrier or Opportunity?

Nuxt-Js. An Objective Assessment of the Framework