Jos de Jong

When developing a new application, your code base starts small and simple. Over time, your code grows and becomes more complex. It can be hard to fight complexity and keep a code base maintainable in the long run. Here some principles that help me with that. Recon with the cost of maintaining code, not just the cost of development When buying a car, it’s quite easy to reckon with both the cost of the one-time purchase as well as ongoing costs like fuel, taxes, and maintenance.

I’ve moved this blog from octopress to hugo, since octopress isn’t maintained anymore. I’ve tried to keep the urls of all pages backward compatible. Thanks again octopress!

In this article, I share with you the journey and the struggles of turning a large, monolithic JavaScript mathematics library, mathjs, into a modular one embracing ES6 modules and functional programming. Because of the heavily intertwined nature of the functionality this was a huge and unique challenge. Why? Math.js is a popular JavaScript library that brings advanced mathematics to the web browser and server. The unique value of math.js lies in offering an integrated solution to work with different types of data like complex numbers and matrices, and offering a math-friendly syntax that allows expressing mathematics in a readable, intuitive way.

tl;dr The JavaScript community is doing a great job in creating an ecosystem of highly composable, configurable, and extensible components. Unfortunately, this has complicated usage of these components. It is time to focus on the user again. Deliver components with a good default configuration which matches the typical use cases, and ensure a gradual learning curve for more advanced usage of a component. Latest years I see a trend in software libraries and frameworks that make me really happy: libraries have become more and more composable.

tl;dr So far I’ve been hesitant to embrace static type checkers like TypeScript. It’s because I associated static type checking with the restrictions and interoperability issues that I know from Java and C++. However, it turns out that TypeScript is different: it uses a structural type system rather than a nominal one, which eliminates these downsides. It gives us a way to describe data types without sacrificing flexibility, interoperability, or scalability.

tl;dr Math.js v2 has been released a week ago. It has a completely reworked, modular architecture which allows creating custom builds. All functions have been rewritten into typed-functions. This takes away a lot of overhead for type checking and type conversions. These changes create a lot of flexibility in both extending and consuming the library. A week ago math.js v2 has been released, a big milestone! You can download it here.

tl;dr In order to ease full stack JavaScript development, we need to take away the hurdles keeping these worlds separated. We need unified, isomorphic solutions for common functionality like module loading, networking, background processes, logging, and others. Ever had to use statements like the following? if (typeof window !== 'undefined') { // browser } else { // node.js } It’s a simple check to see whether a script is being executed in in a browser, and if not, assume that it’s a node.

It may be the holy grail of programming: writing reusable code. Not getting stuck by inventing the wheel again and again, but moving forward and building on top of what has been done. Looking at what we do today, we still haven’t really figured this out. So you are writing a software library. You had a great idea for a simple, broadly applicable solution. You have cooked up a nice API and are happy with the result.

A while ago I read the blog post Ranging Near and Far by Scott Sauyet. On Echo JS, Scott titled a link to this blog “Choosing simple APIs over flexible ones”. This title suggests that you have to choose between either simple or flexible APIs, which is a false dilemma. This got me thinking: What makes a good API? Flexibility Scott discusses the API of the range function of Ramda compared to that of Underscore.

A few months ago I did an astonishing discovery, namely how strong your solutions are shaped by the programming language you use, the language that lives in your head. The interesting thing is that I already knew this. But despite that, I hadn’t expected this to be so incredibly influencing until I saw such a clear case of this in my own work. The right tool for the right job First a short explanation of my programming background.