From Engineer to Developer: Building FEAScript for Browser-Based FEM

Nikos Chamakos — Mon, 20 Oct 2025 11:49:52 +0000

This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight

1. JavaScript is bad, right?

Engineers hate installing software. As a chemical engineer myself, I’ve learned to focus on the practical side of things—how to provide solutions and overcome obstacles. Sure, issues like dependencies, version incompatibilities, or retrieving licenses for proprietary software can be seen as obstacles we should use our skills to overcome. But that’s not usually the main problem. What we really need is to reach our target with as few distractions as possible.

In many cases in my work, I’ve faced challenges such as this:

I wanted to develop a web application for a customer that would solve a system of equations using Finite Element Method, or FEM, (the method I know best). But I wanted to deliver it dependency-free. I didn’t want to tell the customer, “Hey, here’s the web app, but you’ll need to install this and that.” These people don’t have time for that. I wanted it to be easy for them—and I wanted it to be free (or as low-cost as possible).

So, what was the solution? Have you heard the phrase, “If you want peace, prepare for war”? That’s exactly what I did. To avoid dependencies and incompatibilities, I dove deep into programming to build my own library.

Of course, I’m not a freshman in software development—I’ve been coding throughout my PhD (I’ve always had an inclination toward programming). But I mostly worked in “engineering languages” like C++ and Fortran. Creating software in these languages is super fast—I know—but it didn’t solve my problem. For this, I needed something notorious, something engineers love to hate: JavaScript!

JavaScript can solve the dependency problem since it runs in the browser, right? But wait a minute—building a Finite Element solver in JavaScript? That’s crazy, right? It’s slow, right? It’s a disaster, right? Right? 😨

2. I choose JavaScript

So, two years ago, I started programming. Initially, I was translating some old Fortran routines I had developed during my PhD into JavaScript. It wasn’t easy (#$!@# 0-based indexing)! But I managed to create a proof of concept—a 2D heat conduction simulation. Still, there was much work to do.

Another thing: JavaScript is a heavily object-oriented language, while Fortran (90, which I was using) is primarily functional. I’m still trying to shake off that functional mindset I inherited from Fortran.

So I have chosen JavaScript, but not because it's easy. The road is tough, but I have to go on.

3. FEAScript

The project has improved a lot since its beginning in 2023—and I’ve improved along with it. I’ve dived into the strange but brilliant world of JavaScript. I’ve taken courses, I’ve read (and read, and read…), and I’m still learning. The journey is just beginning.

So what can FEAScript offer up to now?

Using its API, you can run simulations for heat conduction, front propagation, or even solve a general-form partial differential equation. And you can do all of this directly in your browser (for web apps), in a Node.js environment, or on interactive JavaScript notebooks such as Scribber.

You can generate meshes using an in-house mesher (currently for simple cases), or import more advanced meshes created in Gmsh.

For solving linear systems, FEAScript supports LU decomposition (adapted from math.js) and an in-house Frontal solver. For nonlinear systems, you can use the Newton-Raphson method.

(Many more features are also included. Check the resources if you want to dive deeper - Hint: FEAScript is not as slow as a C++ developer might think, thanks to V8 🙏).

And what does it need? It just needs your help!

4. Hacktoberfest

When I tagged my repository for Hacktoberfest, I honestly didn’t believe anyone would want to contribute. Not because I doubted the value of my project, but because Finite Elements is a niche topic. But luckily, reality proved me wrong!

I’d describe these contributors as “navigator explorers”—and that’s impressive. They want to contribute even though they might not know much about Finite Elements, or how difficult it can be to understand the whole codebase that’s (hmm) still not ideally written. 🙂

I’ve had the honor of receiving contributions from such brave people, and that’s the beauty of open-source: they don’t have to fully understand the entire code. They can build a small piece—something necessary for the rest of the project, yet independent of it.

That’s beautiful to my eyes. Thank you ❤️

Recourses

Wow, thanks for reading this far! So, what’s next?

Want to learn more about the project?
👉 Visit the website

Want to contribute?
💻 Check out the repository

Want to support the project?
❤️ Donate via GitHub sponsors or Liberapay

JavaScript for Scientific Computations: Oxymoron or a Real Possibility?

Nikos Chamakos — Sun, 10 Aug 2025 05:38:18 +0000

Originally posted on the FEAScript Blog.

A Heretical Statement

Scientific computing has long been the domain of performance-heavy languages like C++ and Fortran. More recently, Python has gained traction, particularly in statistical analysis and machine learning. Yet, when it comes to computationally demanding tasks like finite element analysis (FEA), C++ and Fortran remain the standard.

But what if JavaScript—a language originally designed for web development—could challenge this norm? At first glance, the idea sounds almost heretical. Can JavaScript truly handle scientific computing? Let's break it down from the ground up.

Speed

In order to evaluate JavaScript's speed compared to C++ (which is widely accepted as a very fast language for scientific computations), we can reference the work of Franziska Hinkelmann (Engineering Manager at Google) ¹. According to her measurements, JavaScript is almost as fast as C++ for tasks like prime number calculation. This performance can be obtained by utilizing the TurboFan optimization feature of Google's V8 JavaScript engine. Similar comparisons by Momtchil Momtchev ² show that JavaScript, optimized by TurboFan, can achieve performance close to C++ for tasks like matrix operations.

Libraries

We cannot deny that JavaScript lacks the extensive scientific ecosystem of C++ or Fortran. However, several libraries have emerged in recent years that bring serious numerical capabilities to the JavaScript world:

math.js: A comprehensive math library supporting a wide range of mathematical operations, including matrix calculations and symbolic math.
ndarray and scijs ecosystem: A collection of libraries focused on multidimensional arrays and scientific computing.
numbers.js: A library for basic numerical methods, such as root finding and integration.
Scribbler: A notebook tool with several preloaded scientific libraries.
FEAScript: The finite element simulation library that we are developing, with a focus on simplicity and zero-install usage.

WebAssembly (Wasm) Considerations

While WebAssembly (Wasm) offers tremendous potential for accelerating browser-based numerical computation, it comes with caveats. As of today, no major FEA library has been successfully compiled to WebAssembly with full functionality. Compiling complex software like CalculiX is theoretically possible but brings numerous challenges: handling extensive C/C++ dependencies, dealing with file I/O in a sandboxed environment, and working around limitations in threading and hardware acceleration.

On the other hand, pure JavaScript libraries offer a simpler, native solution for scientific computations that run entirely in the browser without compilation. Of course, a potential enhancement down the line might be integrating WebAssembly selectively for the more performance-critical parts. But that’s for the future.

Conclusions

So, is JavaScript for scientific computing an oxymoron? Maybe not. While it may never dethrone C++ or Fortran in heavy-duty HPC environments, JavaScript is evolving. Thanks to modern engines like V8 and a growing ecosystem of numerical libraries, it's now possible to perform non-trivial scientific computations with reasonable performance.

The future might not belong to JavaScript alone, but it certainly has a place at the scientific computing table!

References

F. Hinkelmann. "Speed up Your Node.js App with Native Addons." https://www.fhinkel.rocks/posts/Speed-up-Your-Node-js-App-with-Native-Addons, 2017. ↩
M. Momtchev. "In 2021, is there still a huge performance difference between JavaScript and C++ for CPU-bound?" https://mmomtchev.medium.com/in-2021-is-there-still-a-huge-performance-difference-between-javascript-and-c-for-cpu-bound-8ff798d999d6, 2021. ↩

DEV Community: Nikos Chamakos