
NOTE: Flexo can be downloaded [for free on the App
Store](https://apps.apple.com/app/flexo-focus-pomodoro-timer/id6469589285).

---

Coding is challenging. Developing software is a complex task. Creating a mobile application is a
demanding process.

Well, maybe not. Especially if you choose to use Swift (which, aside from iOS, can also be utilized
in MacOS and iPadOS!). My first experience with the language has been remarkably positive, and Apple
has streamlined the learning curve for newcomers, making it an accessible and user-friendly
language.

# Swift

But let's start from the beginning. Why should a web developer like me use Swift to build an app?
There's React Native, which I'm already familiar with, and even Flutter. Both of these can be
adapted to Android and other platforms without the need to rewrite the same code in another
language. However, there's a singular reason: I have a strong appreciation for well-designed UIs.
I'm genuinely impressed when I encounter a product with engaging UX. That's why, after initially
developing the app in React Native, I decided to mark it as outdated and start anew with Swift.

Swift may seem different when coming from simpler languages such as JavaScript, TypeScript, Ruby, or
Python. But once you get used to it, it's remarkably nice. It's a statically-typed language that
encompasses many features from other languages: Generics, Structs (everything is Structs!), Classes,
Extensions, Enums, a syntax for closures, and many other things! It just checks all the boxes I
could ask for, and it feels amazingly satisfying to write.

And hey, there's more. SwiftUI is the icing on the cake that makes everything remarkably easy. Apple
has created a set of reusable Views that allow us to create a decent app in less than the blink of
an eye.

# Why a pomodoro app?

I have been a fan of the Pomodoro technique for a long time, and I have used many apps to keep track
of my work sessions. However, the reality is that there's no simple, good-looking, free application
that satisfies my needs. So, I decided to embark on a journey to build the perfect, free Pomodoro
app: Flexo.

Flexo is simple, easy to use, and it allows you to keep track of your tasks. It's good-looking, not
necessarily an Apple look-alike app, while preserving some of its main interface elements.

Building Flexo with Swift and SwiftUI was a deliberate choice. The robustness of Swift allowed for
efficient code structuring, minimizing the chances of errors. SwiftUI's declarative syntax
streamlined the UI development process, resulting in a visually appealing and responsive app.

The goal was to create a Pomodoro app that not only serves its functional purpose but also delights
users with its design. Flexo borrows some interface elements from the Apple design philosophy but
maintains its unique identity, ensuring a fresh and enjoyable user experience.

# What's Next?

Flexo is an ongoing project, and I am committed to continually enhancing its features based on user
feedback and evolving productivity needs. The journey of developing Flexo has been exciting, and I
invite you to join me on this adventure towards mastering the art of productivity with style.

Download Flexo today and take control of your time in a way that's simple, efficient, and visually
pleasing. Happy Pomodoro-ing!

![Flexo screenshot](/flexo/web1.png)

![Flexo screenshot](/flexo/web2.png)

![Flexo screenshot](/flexo/web3.png)


On building my first Swift app

Have you ever felt the itch for change, the desire of something new and shining, even when you're
comfortably settled in a familiar routine? For the past decade, I've been immersed in the world of
coding, a journey that began in my university days with humble C code and led me to my current role
as a Staff Engineer at [Factorial](https://factorialhr.com). While this path has provided financial
security and professional growth, a sense of restlessness has crept in recently, compelling me to
embark on a new, more exhilarating adventuree.

# The comfort zone

Coding has been my bread and butter for the past years. I started as a junior developer in a small
company, and over time, I've steadily climbed the ranks, acquiring not only technical skills but
also invaluable insights into phenomena like impostor syndrome and the fear of deploying new code.
Yet, this journey has been more than just mastering the intricacies of programming. It's been about
growth, mentorship, and the bonds forged through collaboration.

As I reflect on my path, I've come to realize that the true magic of this world lies not only in the
lines of code but also in the camaraderie and collective problem-solving with my colleagues. It's in
the infinite pairing sessions and the shared victories and setbacks that I've grown to cherish. In
the context of my comfort zone, it's not just about the familiarity of coding; it's about the
profound connections and collaborative spirit that have defined my journey.

Leaving a job that you've poured time and energy into is never a decision to be taken lightly. It's
like stepping into the unknown, uncertain about where your next opportunity will lead you. But
sometimes, that leap of faith is precisely what's needed to reignite the dormant passion within.

# Vertigo

Vertigo – that's precisely what I experienced the moment I made the decision to leave my job and
embark on a new adventure. What lies ahead? Will I stumble upon a passion that ignites my soul, or
will I find myself back in the familiar embrace of comfort? Asking these questions sends me into a
whirlwind of emotions, a state I'm not accustomed to. I usually prefer to play it safe, satisfying
my controlling, rational mind almost all the time.



![Uncertainity, Uncertainity everywhere](/through-the-uncertainity/uncertainity.jpg)
_As Buzz would say to Woody: "Uncertainity, Uncertainity everywhere"_

Yet, I also recognize that this inner conflict is a sign of pushing my boundaries, a signal that I'm
seeking growth and refusing to settle for mediocrity. Now, don't get me wrong; I'm not here to call
anyone mediocre. I genuinely believe that great innovations and revolutionary products emerge from
restless minds. It's time for me to push myself to search for that elusive "click", to elevate my
game and become the most creative and passionate version of myself I've been in these past years.

# Pursuing my passion

I've always been the kind of person who thrives on challenges. Whether it's diving into a complex
coding problem or conquering a new video game, I find myself naturally drawn to the thrill of
mastering something, no matter how daunting it may seem.

Lately, I've been grappling with questions like, "What truly motivates me? What's the next big
challenge that will set my heart racing and rekindle my passion?" To be honest, I don't have all the
answers. However, as a committed engineer, I've been taking a systematic approach to uncovering
them.

One valuable resource I've been exploring is the book
[Designing Your Life](https://designingyour.life/the-book/). In this book, the authors, who also
happen to be experts on the subject at Stanford University, apply design thinking principles to the
realm of life and career. While the book primarily focuses on designing a fulfilling job, its
principles can be applied to various aspects of our lives. In the pages of "Designing Your Life", I
have been guided through a process of setting expectations and iterating on my life's path. It's a
fascinating approach that has helped me gain clarity on what I'm truly passionate about and how I
can align my career choices with those passions.

![Designing your life book](/through-the-uncertainity/designing-your-life.jpg)

# The beauty of the unknown

Even though it's scary, what's unknown to us is undeniably attractive. You've probably had one of
those nights when it's impossible to sleep because the next day holds an exciting trip or an
important meeting.

That's the state that currently summarizes my existence. I'm half scared, half passionate about the
next big thing for me. My head is constantly abuzz with thoughts about what to learn next, who to
meet, or what the next groundbreaking product idea might be.

Why? Because, my friends, what's not known is captivating. It pushes your boundaries and makes you
feel alive, more alive than ever. So, if you find yourself in a similar situation to mine, I
encourage you to let go and seek what truly motivates you.

As always, thanks for reading! I hope to see you next time. Chao! 👋

Through the uncertainty of career transitions


# About bundlers

JavaScript started as a language for simple, isolated tasks like changing an element class or
setting a timer. However, as the web evolved, new needs arose, and developers started using
JavaScript to create big, complex applications on the client side. The rise of AJAX revolutionized
the way web pages were built, allowing developers to create more dynamic and interactive
experiences.

Node.js appeared and new frameworks like Backbone, Angular.js, and React flourished. JavaScript,
which was once used for simple tasks, was now serving a completely different purpose. These new
tools allowed developers to create entire applications with a solid architecture that took
inspiration from backend applications while also creating new concepts. Companies like Facebook
started building massive client-side applications, and "frontend developers" became a popular job
title as this new way of building web pages exploded.

With the growth of JavaScript came an ecosystem of tools, including **bundlers**. Bundlers combine
all the separate JavaScript files into a single file that browsers can consume. In the early days of
JavaScript applications, this was the only way to serve these large, complex applications. At
Factorial, we've been using webpack for more than 5 years to develop and build our frontend
application.

# Webpack’s drawbacks

## Lack of Speed

Our frontend application has over 700k lines of code, excluding external packages. This means that
when webpack starts up, it has to bundle all that JavaScript into a single file and serve it to the
browser. And let me tell you, that takes a long time for a project of this size.

![Lack of speed](/webpack-to-vite/lack-of-speed.png)

While these numbers have improved over time, thanks to webpack's caching system and performance
improvements, it's still a slow process. The Hot Module Replacement (HMR), which is responsible for
bundling the code you're changing, used to take more than 10 seconds per change. This made
developers feel like they were waiting forever and slowed down our development process.

## It doesn't scale well

As our company grew, we added more features and more files to our application. This made webpack
slower and slower and consumed more of our machine's memory. We knew that at some point, our current
solution wouldn't be able to run in any of our dedicated environments.

## Out-of-memory crashes

At Factorial, we need to run several services in parallel, including a database, a Ruby on Rails
monolith, a Sidekiq instance, and our frontend application built with React, among other small
services. This led to frequent out-of-memory (OOM) crashes that disrupted our development flow and
forced us to restart the frontend service and hope it didn't crash again. It was a terrible
developer experience.

## Disposable environments

We use [Gitpod](https://www.gitpod.io) as our cloud-based development environment solution, and the
developer experience is [just amazing](https://www.gitpod.io/customers/factorial). However, dealing
with webpack in that scenario was a pain. As you can see from the table, the cold start time was
disastrous. It took longer for the remote environment to be available than it took me to read all my
Slack messages – and I get a lot of them.

We tried to improve the situation by using caching, but it didn’t go well. Webpack's cache isn't
easily shareable between environments, so we had to cold start the frontend application on each
workspace boot. This added to the already slow startup time and made the experience even worse.

# New tools on the horizon

Given all these previewed problems, as soon as we had some bandwidth, we started looking for
alternatives. New tools with revolutionary results appeared, so we investigated them deeply.

## Esbuild

[Esbuild](https://esbuild.github.io/) is a JavaScript bundler that shows promising results compared
to its older counterparts. It's written in Go and compiles to native code, and its performance is
impressive. However, it doesn't have development support, so we wouldn't be able to use it while
developing our code. Additionally, it doesn't support code splitting, so we wouldn't be able to use
it in our application.

## SWC

[SWC](https://swc.rs/) or "Speedy Web Compiler" is another bundler that uses Rust under the hood. It
has a large community and is used by many companies. Like esbuild, it's very fast at compiling and
transpiling, but it doesn't have development support, so we couldn't use it in our workflow.

## Vite

[Vite](https://vitejs.dev/) is not a bundler or a compiler, and it's not written in a modern
language. It's a wrapper of various tools that work together to solve the development and bundling
of front-end applications.

It uses esbuild for dependencies (the ones inside node_modules), bundling each of them into a single
JavaScript file and sending it to the client, and doing the joins using
[dynamic import](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/import).
It has impressive performance, with a fast cold start time. During the development process, it
serves all other files over the wire as is, only performing strict transformations like transpiling
TypeScript to JavaScript. It also uses esbuild for this purpose.

For compilation, it uses Rollup. As mentioned earlier, esbuild doesn't support code splitting, but
Rollup does. While we didn't see any improvement in this area, as webpack and Rollup gave us similar
results in terms of bundling times, Vite still seemed like a good fit for our needs. So we went
ahead and tried it.

# Adopting Vite

We encountered some challenges during the process of adopting Vite. Although, the process should
have been simpler with a smaller codebase.

## Sass

Factorial's frontend is over 6 years old, and at the time, the most modern way of dealing with CSS
was using [Sass](https://sass-lang.com/). We now mostly use
[vanilla-extract](https://vanilla-extract.style/) in new components, but we still have some tokens
in our design system that Sass needs to be aware of. So we use its
[JavaScript API](https://sass-lang.com/documentation/js-api/). This was one of the most difficult
issues we faced.

Although it's not documented, we were able to pass it to the CSS options inside vite.config.ts:

```js
css: {
  preprocessorOptions: {
    scss: {
      functions: yourScssJsFunction,
    },
  },
}
```

This allows us to read the design system variables and inject them directly into Sass.

## Code splitting our app

We have 7719 files in our frontend `src` folder. This means that every time we open the frontend
application in development, Vite would serve 7719 assets over the wire, plus all the external
dependencies.

We tried it, and it was a disaster. The initial boot time was so high that it didn't make sense to
switch to Vite. Even with some code splitting, the performance was still not acceptable.

So we came up with the idea of splitting the code into more chunks. The first approach that came to
mind, and also the most logical one, was to split it by the parent route of each page. This means
that all the components inside `/employees` are a single chunk. This saved us a lot of time during
the initial bootstrap and also benefited our clients by sending smaller JavaScript assets.

With this change, we were able to significantly improve the performance of our application on both
sides. The initial boot time was significantly reduced when developing, and the overall experience
was much smoother for our users.

Here's the code. We use [Loadable Components](https://loadable-components.com/) to be able to
dynamically import the file we want to use, as it's currently a limitation of `React.lazy`.

```ts
import loadable, { type DefaultComponent } from "@loadable/component"
import type { RouteObject } from "react-router-dom"

interface LasyRouteAttrs {
  path: string
  loadFn: () => Promise<DefaultComponent<unknown>>
}

const buildLazyRoute = ({ path, loadFn }: LazyRouteAttrs): RouteObject => ({
  path: `${path}/*`,
  element: React.createElement(loadable(loadFn)),
})
```

# Implementation

We divided the implementation into two parts: the development and the build.

In the development phase, we configured everything and offered the tool to our engineering team.
Some early adopters gave us feedback on some small parts to fix. Since the overall feeling was
positive, we decided to use it as the default for the entire team. We repeated the same process and
fixed some small issues that arose.

Vite uses different tools for development and building. esbuild is used for development, while
rollup is used for building. This carries some risks, as we cannot use the development application
with total certainty that the result will be the same as the built application. Therefore, we
thoroughly tested it using E2E tests and a lot of manual testing.

Once we felt confident enough, we did the swap. The application worked well, with only two bugs
regarding Intl and localizations. Overall, the release was a success!

# Vite's acceptance

The acceptance of Vite among our engineering team has been generally positive. Although there have
been a few detractors, the overall feeling toward Vite has been positive and most of our engineering
team prefers it over webpack.

There were a few drawbacks, however. Let me describe them.

## Initial loading time

Chunking our app helped us reduce the initial loading time significantly. However, this loading time
may worsen in situations of poor network connectivity.

We are actively working on improving our app so that the initial fetch time is reduced. Some
proposals that we are considering include using GraphQL to fetch our data, which would prevent us
from loading most of the store files we have, and also splitting the app into even more parts.

## E2E tests

We have an end-to-end suite of tests that use Cypress. Using them with Vite's `serve` mode is quite
painful, as the initial load time is too long and it happens for every test. This is not an
acceptable situation.

Luckily, Vite has a mechanism to build and serve files easily. With the power of Vite preview, we
can build and serve our application with no extra configuration. This, of course, prevents us from
making changes in the front end while running our E2E suite, but at the moment it is an acceptable
situation to deal with.

We are still looking for a suitable setup that allows us to combine the speed of E2E execution with
a better development experience.

# Results

Here you can find a table with the results compared with webpack’s one. As you can see, the total
time to load the application improved significantly, as well as the HMR times.

![Results](/webpack-to-vite/results.png)

# Conclusions

We are confident that switching to Vite has significantly improved the development experience of the
frontend application. The transition was smooth, and the tool has been well-received by our team.
Vite addresses the slow startup times, poor scaling, and out-of-memory crashes that we experienced
with webpack.

We are excited about the upcoming features for Vite, as well as the improvements in esbuild and its
[new react plugin](https://vitejs.dev/blog/announcing-vite4#new-react-plugin-using-swc-during-development).
We are currently testing [the new version](https://vitejs.dev/blog/announcing-vite4.html) of it and
are impressed by the ease of development it provides. Also, there’s a
[new plugin for React](https://github.com/vitejs/vite-plugin-react-swc) that uses SWC. A big kudos
to the maintainers and contributors of Vite for their great work, way to go!


From webpack to Vite


Welcome to my corner of the internet!

I'm thrilled to kick off this blog, and I've aptly titled this first post as an introduction to what
you can expect here.

As a software engineer, I spend my days immersed in the intricacies of code and data. While I love
the technical world, I've discovered a growing desire to explore a broader spectrum of topics. This
blog is my way of breaking free from the boundaries of my profession and sharing my thoughts,
experiences, and discoveries.

One thing you'll quickly notice about this blog is its lack of thematic posts. I don't want to
restrict myself to writing only about technology. Instead, I'll use multple subjects that have
captured my attention—whether it's a deep dive into the latest programming languages or a reflection
on a novel I've read recently.

I'm not a very scheduled person, and so I want this blog not to be. Therefore, I won't be posting on
a rigid timetable. Instead, I'll be sharing my thoughts when inspiration strikes, when a topic
really excites me, or when I feel a burning desire to share something. The goal here is quality over
quantity.

And with that intro, I salute you—for now. Thank you for joining me on this exciting journey of
exploration and self-expression. Goodbye!


On building my first Swift app

Through the uncertainty of career transitions

From webpack to Vite

hello world