⏱ Estimated reading time: 10 minutes

Table of Contents

Bun: new and fast, but is it production-ready?

By Olivier Guillerm, Node Developer @ ekino

About Bun

Bun is an ecosystem implemented with Zig on top of JavaScriptCore, Apple’s JavaScript runtime. It natively understands both ECMAScript and CommonJS modules including in the same file but also TypeScript, Rust, C, Kotlin and many more languages through direct integration or bindings. Bun chose to be as compatible as possible with existing Node frameworks and its API surface to simplify adoption.

The selling argument is that Bun is fast in terms of raw speed, I/O and requests per second. Benchmarks indicate that on trivial cases Bun is must more performant than its rivals. While reading and writing files, results are not as clear-cut, yet Bun still takes the lead with Deno. As for QR Code generation, Bun loses its lead but uses less RAM. This points at real-world performance being on-par with Node.

Bun is not a runtime

The difference between a runtime and ecosystem is that the latter will do more than running code. Ecosystems solve the problem of too much tooling and integration. Bun’s package manager and test library are much more efficient and offer a better Developer eXperience. Bun works with Windows, Linux and macOS and even ships with a build command that can produce single-file executables!

With that, it’s a No-Go for production: the lack of support for HTTP/2, the missing Node APIs and the risk for performance regressions signals a lack of stability. This is further amplified by the number of GitHub issues, the small community and an unknown business model. Even though Bun is not sustainable today, it created momentum in Node and Deno to implement some requested features such as compatibility improvements between ECMAScript and CommonJS modules.

Questions and Answers

What is the footprint of the runtime itself?

It is smaller than that of Node and Deno in terms of size and performance impact.

Are common debug features supported?

Yes. This ecosystem is developer-friendly.

Work less, live better

By Pierre-Alexandre Dupuy, Frontend Lead Engineer @ ekino

French people and their pension

The French logic to work states that working more and for longer leads to a better financial situation. This has not always been true:

  • 1936: France adopted the 40h work week, work unions and paid leave;
  • 1998: the idea behind the 35h work week was to spread work over more people in a fight against unemployment.

Working harder increases the risk of burnout and psychological breakdown! IT is fantastic as there is always more work to do in an easily reachable format. The computer invites the worker to commit leisure time for essentially free: people are not incentivized for delivering more and have the right to disconnect. When the work day or week are over, we must disconnect and become ourselves again. French citizens must work 172 quarters as of 2024 to earn a pension. This gives plenty of career time for doing valuable stuff.

When it comes to pensions, IT is privileged. It is well paid and not risky compared to most unskilled or manual labor. IT workers reaching pension age outlive the average person.

80%: less is more

Working 80% is not about compressing a work week into four days, which is essentially the same as working full time and freeing the worker for one day per week. Lyon’s civil servants, the LDLC group, Welcome to the Jungle and RATP are prime examples of the four-day work week. This has had a great effect on morale and productivity since it gives more time to rest, the ability to plan medical or administrative appointments and other luxuries that people cannot afford to do during the week because their work hours align.

80% means lowering the number of hours committed during the work week and the salary at the end of the month. IT workers live comfortably and can afford to reclaim some of their time. This may not even have an impact on the number of quarters one must work, though it does have an impact on the pension. 80% is 50 more days of vacation per year, though!

Getting it

Some situations call for lowering our work week:

  • Being a parent: take your parental leave, witness your children grow, plus your salary loss can be partially compensated by French public institutions;
  • A relative had an incident, you wish to create a company, medical leave: life means more than work. There are many reasons to request you work week to be shortened. However, some employers may not hear them…
  • Resignation: An employer that treats their workers poorly or as disposable should not be surprised to see them leave.

Younger generations don’t share the same priorities: they favor flexibility, recognition and work-life balance. Money is of course a strong motivator but goodies, an annual retreat and foosball rank lower versus peace of mind.

Living better is defining oneself by your passion, your personality or anything other than work. Try introducing yourself: when does your profession comes in the list of things you say? If you fall ill on holidays, this is not a coincidence: it usually means your body understands it is not in “work mode” and that it is not being listened the rest of the time. Don’t have time to go to the gym, the doctor, the psychologist or buy groceries? It is usually not a matter of time but priority: we have plenty of time to take care of ourselves and our loved ones if we wish to.

Pick up new skills, read, get out, stop using tech! And don’t forget to take care of yourself, your place, your loved ones, your children, and so on.

Questions and Answers

When can I ask for a parental leave?

Depending on how many children were born at the same time, parental leave can be requested until later and more times. This webpage explains it in detail.

The Art of precision in estimates

By Olga Yasnopolskaya, Frontend Developer @ ekino

Shortcomings of estimates

The annual Standish Group Chaos Report finds that 30% of all project do not reach production and 50% go outside budget and most of it is due to how the project is planned. Waterfall is inflexible and led by lengthy and exhaustive specifications, leading to the infamous tunnel effect where the customer sees the result of the project after a long period without being able to influence any of its developments. Agile succeeds three times more frequently.

Let’s focus on how Agile sprints are planned and specifically on estimates:

  • Estimates are not reliable: experienced and “calibrated” teams are more precise, going from 30% of deviation to 15 to 20% near the end of a project;
  • Estimates are not promises: like automobiles on a highway, software teams need pit stops to fix stuff and are not always aware of spikes and blockers;
  • Estimates made by someone never apply to someone else: context and experience matter and can never fully be shared and this is even more true when two people are in different teams!
  • Estimates are short-lived: we live in a fast-paced world where everything changes all the time. The project, its codebase, people, needs, context. An estimate made today may not be valid anymore in a week.

Making better estimates

There are techniques that deliver consistently better estimates. It’s usual to estimate using person-days as this method gives immediately usable results even though they probably will not be reliable. This lack of reliability causes time, quality or scope pressure and leads to budget overruns.

The Fibonacci sequence —1, 2, 3, 5, 8, 13 and so on— is a different way to look at the issue. By attributing points to every task, it becomes easier to track how difficult they are and when they should be split when possible. Some product owners tend to convert points to time estimates which leads back to the issues with time estimates! These points represent complexity, not time.

An alternative to points are t-shirt sizes —S, M, L, XL, XXL. They unambiguously communicate the complexity of a task, but they can still be converted to time: there is no perfect system because budgeting is expected for a project. The level of abstraction brought by t-shirt sizes can help avoid the issue, though.

The Agile Manifesto recommends responding to change over following a plan, which would be the premise of the #NoEstimate movement. And while following a plan seems left aside, the Manifesto states that it bears value: without any plan or budget visibility, the project may deviate into over-engineering. Time-boxing is not a bad thing!

True time-boxing is actually hard: each project is divided into tasks which are in turn divided into blocks. A block must be completed in time after which another block starts and then another one and so on until a final retrospective. There are flexible modes to time-boxing nevertheless the purpose is to get things done.

Estimates originate from one’s ego, which makes it difficult to create anchoring points for comparison. In case of doubt, estimate more and include non-code time (tests, accessibility, more) into the estimate. Always give a range and listen to other estimates, especially if they come from senior members of the team!

Questions and Answers

When are estimates necessary?

They are necessary whenever budget is limited, which is basically every time. Developers are expensive, therefore the ROI of every feature must be part of the prioritization process.