Originally posted on dev.to: From Engineer to Developer: Building FEAScript for Browser-Based FEM
This is a submission for the 2025 Hacktoberfest Writing Challenge: Maintainer Spotlight
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? 😨
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.
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!
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 ❤️
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
The eikonal equation is a nonlinear first-order partial differential equation (PDE) that describes how wavefronts propagate through a medium. Its origins go back to the 19th century, when Sir William Rowan Hamilton developed a new framework for geometrical optics. Hamilton introduced the concept of a Point Characteristic Function1 which represents the optical path length of a ray between two points on chosen surfaces. These functions are direct precursors to what would later be termed as eikonal by Ernst Heinrich Bruns (1895). Today, the eikonal equation is recognized as a fundamental tool for analyzing wave propagation in diverse cases, from optics and acoustics to seismology and materials science.
The standard form of the eikonal equation is2:
\[|\nabla u(\mathbf{x})| = f(\mathbf{x}), \quad \mathbf{x} \in \Omega \subset \mathbb{R}^n\]where \(u(\mathbf{x})\) is the travel time or distance from a source, and \(f(\mathbf{x})\) represents the slowness field, i.e., the reciprocal of the local wave speed. The eikonal equation’s nonlinearity, originating from the absolute value of the gradient, makes it intrinsically challenging to solve analytically. A more significant challenge, however, arises from the potential for solutions to exhibit non-differentiability at certain points3. At these specific points, the classical definition of a derivative breaks down, rendering traditional analytical methods insufficient. It is crucial to recognize that these singularities are not merely numerical artifacts or errors introduced by computational approximations; rather, they are intrinsic features of the wave propagation phenomena that the eikonal equation is designed to describe. Consequently, standard numerical methods that are typically designed for smooth solutions would either fail to converge or produce incorrect and unphysical results in the presence of such inherent non-differentiability.
Among the different methods for solving the eikonal equation (e.g. Fast Marching Method, Fast Sweeping Method), in FEAScript we focus on the Vanishing Viscosity Method4. This method modifies the PDE as:
\[|\nabla u(\mathbf{x})| = f(\mathbf{x}) + \varepsilon \Delta u(\mathbf{x}), \quad \varepsilon > 0\]where the small parameter \(\varepsilon\) enforces smoothness. As \(\varepsilon \to 0\), the solution converges to the true viscosity solution of the eikonal equation. This approach blends naturally with finite element and Galerkin formulations, making it ideal for integration into FEAScript.
As a demonstration, consider the solidification front propagation example. Here, the eikonal equation governs the motion of a solidification interface during processes such as metal cooling. The interface propagates with a speed determined by the material properties (described by the slowness field \(f(\mathbf{x})\)). By solving the eikonal equation numerically with vanishing viscosity in FEAScript, we can visualize how the interface evolves over time. For improved browser performance, you can also try the web worker implementation which performs the calculations in a separate thread.
This example highlights how a seemingly abstract PDE translates directly into a materials science application, showing FEAScript’s versatility for modeling complex physical processes in JavaScript.
The eikonal equation provides a unifying framework for understanding wavefront propagation across physics and engineering: from geometrical optics (Hamilton’s original motivation), to seismology, acoustics, and solidification dynamics.
Eikonal’s nonlinear nature and its inherent presence of singularities make, however, closed-form analytical solutions rare and numerical treatment challenging. Through the Vanishing Viscosity Method implemented in FEAScript, we gain a robust way to approximate viscosity solutions of the eikonal equation in a JavaScript environment. This demonstrates how modern numerical methods can be embedded directly in accessible, browser-based platforms, lowering the barrier to experimenting with PDEs that once required specialized scientific computing software.
J. Rubinstein, G. Wolansky. “Eikonal functions: Old and new.” A Celebration of Mathematical Modeling: The Joseph B. Keller Anniversary Volume, Springer Netherlands, Dordrecht, 2004. ↩
J. A. Sethian. “A fast marching level set method for monotonically advancing fronts.” Proceedings of the National Academy of Sciences, 93.4 (1996): 1591-1595. ↩
J. Miao. “Viscosity solutions of the eikonal equations.” The University of Chicago, 2020. ↩
Y. Yang, W. Hao, Y.-T. Zhang. “A continuous finite element method with homotopy vanishing viscosity for solving the static eikonal equation.” Communications in Computational Physics, 31.5 (2022): 1402-1433. ↩
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.
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) 1. 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 2 show that JavaScript, optimized by TurboFan, can achieve performance close to C++ for tasks like matrix operations.
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:
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.
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!
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. ↩
The finite element method is a discretization technique that can utilize a computational mesh to approximate the solution of a partial differential equation. Basic concepts of the finite element method are described below.
Consider a typical formulation of a boundary value problem (BVP):
\[\begin{eqnarray} Lu &= f \quad \text{in} \quad D, \\ Bu &= g \quad \text{on} \quad \partial D. \end{eqnarray} \tag{1}\]The solution \(u\) is a function of the position vector \(\bar{x}\) at the domain \(D\), which is a subregion of a one-, two-, or three-dimensional Euclidean space. The position vector \(\bar{x}\) is defined as: \( \bar{x} = \sum_{i=1}^{n} x_i e_i \), where \(e_i\) are the unit vectors and \(n\) is the dimension of the Euclidean space. \(L\) is the differential operator and \(B\) is a boundary operator defined at the boundary \(\partial D\). The solution \(u\) can be approximated using a linear combination of basis functions \(\phi^1, \phi^2, \phi^3, \dots, \phi^N\) such that: \( u(x) = \sum_{j=1}^{N} u_j \phi^j(x) \), where the number of basis functions equals the number of nodes of the computational mesh.
The Galerkin method seeks a solution that zeroes out every one of the following weighted residuals:
\[\begin{aligned} R_i &= \int_{D} (Lu - f) \phi^i \, dS \\ &= \int_{D} \phi^i \left( L\left( \sum_{j=1}^N u_j \phi^j \right) \right) \, dS - \int_{D} f \phi^i \, dS \\ &\quad \text{for} \quad i = 1, 2, \dots, N. \end{aligned} \tag{2}\]These integrals depend solely on the nodal values \(u_j\), which are the unknowns to be determined. The number of residuals is equal to the number of basis functions, which in turn is equal to the number of nodes, \(N\), in the computational mesh. Setting the Galerkin residuals to zero leads to a system of \(N\) algebraic equations with \(N\) unknowns, which can be solved to obtain the approximate solution.
In general, there are three common types of boundary conditions that can be imposed in boundary value problems: Dirichlet, Neumann, and Robin boundary conditions. The boundary conditions that specify the value of \(u\) on a portion of \(\partial D\) are called Dirichlet boundary conditions, and they are imposed directly in the discretization equations. In particular, the Dirichlet boundary conditions replace the Galerkin residuals at the computational nodes that lie on the portion of the boundary where the solution value is prescribed.
Consider, for example, a boundary node \(n\) at position \(t_n\), where the solution is defined by the boundary condition \(u = F(t)\), with \(F(t)\) being a known function of the position \(t\) on \(\partial D\). In this case, the \(n\)-th residual is replaced by: \(R_n = u_n - F(t_n)\).
The boundary conditions that define the value of the derivative of \(u\) on a portion of \(\partial D\) are called Neumann (or natural) boundary conditions. These are imposed indirectly in the discretization equations. Consider that the highest rank of differentiation of the operator \(L\) is \( \frac{d^m}{dx^m} \). The corresponding integral at the residuals will be:
\[I_m = \int_{D} \phi^i \frac{d^m u}{dx^m} \, dx. \tag{3}\]By applying integration by parts, we get:
\[I_m = \oint_{\partial D} \phi^i \frac{d^{m-1} u}{dx^{m-1}} \, dt - \int_{D} \frac{d\phi^i}{dx} \frac{d^{m-1} u}{dx^{m-1}} \, dx, \tag{4}\]where \(t\) is the independent variable at the boundary \(\partial D\). A boundary condition of \(m-1\) rank is imposed at the line integral. Thus, in the case where the Neumann boundary condition is \( \frac{d^{m-1}u}{dx^{m-1}} = g(t) \) on \(\partial D\), where \(g(t)\) is a known function, then:
\[I_m = \oint_{\partial D} \phi^i g(t) \, dt - \int_{D} \frac{d\phi^i}{dx} \frac{d^{m-1} u}{dx^{m-1}} \, dx. \tag{5}\]If the Neumann boundary condition has a rank \(k < (m-1)\), then we continue to apply integration by parts until the \(k\)-th rank derivative appears on the line integral.
Finally, Robin boundary conditions, also known as mixed boundary conditions, specify a linear combination of the function \(u\) and its derivative on a portion of \(\partial D\). These are imposed in a similar fashion to the Neumann boundary conditions.
The basis functions are defined on reference elements: on the unit interval \(0 \le \xi \le 1\) in 1D, and on the unit square \(0 \le \xi \le 1\), \(0 \le \eta \le 1\) in 2D. However, the basis functions also need to be mapped to the initial domain \(D\) of the BVP since the solution \(u\) is approximated by basis functions defined on \(D\). The change from the \(\bar{\xi}\) system to the \(\bar{x}\) system is performed through isoparametric mapping, where \(\bar{\xi} = (\xi, \eta)\) and \(\bar{x} = (x, y)\). In this process, the reference element is mapped to every element of the computational mesh on \(D\). The same basis functions are used for the mapping:
\[\bar{x} = \sum_{i=1}^{n_k} \bar{x_i} \phi_i(\xi), \tag{6}\]where \(\bar{x}\) is the position vector of the mesh element, \(\bar{x_i}\) is the position vector of the \(i\)-th node in local numbering of the mesh element, \(\bar{\xi}\) is the position vector of the reference element, and \(n_k\) is the number of nodes in the reference element. Keep in mind that \(\phi_i\) corresponds to the local basis function, where \(i\) is the local number of the node in the reference element (as opposed to the global definition of the basis function \(\phi^i\), where \(i\) corresponds to the global node number in this case).
From the above mapping, we can define the reverse mapping from \(\bar{x}\) to \(\bar{\xi}\). The reverse mapping is calculated by solving the isoparametric mapping relation (Eq. (6)) for \(\bar{\xi}\) as a function of \(\bar{x}\): \(\bar{\xi} = \bar{\xi}(\bar{x})\). The basis functions are then expressed in the coordinate system of \(D\) (the \(\bar{x}\) system) as \(\phi_i(\bar{\xi}(\bar{x}))\), where \(i = 1, 2, \dots, n_k\).
In the case where \(D\) is a two-dimensional domain, the Jacobian of the mapping is the matrix:
\[\bar{\bar{J}} = \begin{vmatrix} x_{\xi} & y_{\xi} \\ x_{\eta} & y_{\eta} \end{vmatrix}, \tag{7}\]where \( x_{\xi} = \frac{\partial x}{\partial \xi}\), \( y_{\xi} = \frac{\partial y}{\partial \xi}\), \( x_{\eta} = \frac{\partial x}{\partial \eta}\), \( y_{\eta} = \frac{\partial y}{\partial \eta}\). The relation between the \(\bar{x}\)- and \(\bar{\xi}\)-partial derivatives of the basis function can also be calculated as:
\[\bar{\bar{J}} \begin{vmatrix} \frac{\partial \phi_i}{\partial x} \\ \frac{\partial \phi_i}{\partial y} \end{vmatrix} = \begin{vmatrix} \frac{\partial \phi_i}{\partial \xi} \\ \frac{\partial \phi_i}{\partial \eta} \end{vmatrix}. \tag{8}\]By solving the above equation, we can calculate the partial derivatives of the basis function with respect to \(x\) and \(y\):
\[\begin{eqnarray} \frac{\partial \phi_i}{\partial x} &=& \frac{1}{\text{det}\bar{\bar{J}}} \left( y_{\eta} \frac{\partial \phi_i}{\partial \xi} - y_{\xi} \frac{\partial \phi_i}{\partial \eta} \right), \\ \frac{\partial \phi_i}{\partial y} &=& \frac{1}{\text{det}\bar{\bar{J}}} \left( x_{\xi} \frac{\partial \phi_i}{\partial \eta} - x_{\eta} \frac{\partial \phi_i}{\partial \xi} \right). \end{eqnarray} \tag{9}\]where \(\text{det}\bar{\bar{J}}\) is the determinant of the Jacobian: \( \text{det}\bar{\bar{J}} = x_{\xi} y_{\eta} - x_{\eta} y_{\xi}\). In the case where \(D\) is a one-dimensional domain, Eq. (6) is reduced to: \( x = \sum_{i=1}^{n_k} x_i \phi_i(\xi) \). The Jacobian of the mapping in this case is: \( J = \frac{dx}{d\xi} = x_{\xi} \), and the partial derivative of the basis function is: \( \frac{d\phi_i}{dx} = \frac{d\phi_i}{d\xi} \Big/ x_{\xi} \).
A typical representative of the integrals in the Galerkin residuals is the following:
\[I_{ij} = \int_{D} \phi^i L \phi^j \, d\bar{x}. \tag{10}\]The computational mesh covering \(D\) consists of \(NE\) finite elements \(E_k\) \((k = 1, 2, \dots, NE)\). Thus, the integral \(I_{ij}\) is the sum of the partial integrals:
\[\begin{aligned} I_{ij} &= \sum_{k=1}^{NE} I_{ij}^k, \\ I_{ij}^k &\equiv \int_{E_k} \phi^i L \phi^j \, d\bar{x}. \end{aligned} \tag{11}\]Each of the integrals \(I_{ij}^k\) is calculated through the isoparametric mapping by transforming the coordinate system as follows:
\[I_{ij}^k = \int_{E_0} \phi_i(\bar{\xi}) L_{\bar{\xi}} \phi_j(\bar{\xi}) \, \text{det}(\bar{\bar{J}}) \, d\bar{\xi}, \tag{12}\]where \(E_0\) is the reference element, and \(L_{\bar{\xi}}\) is the differential operator expressed in the \(\bar{\xi}\)-coordinate system. The integrals of the discretization equations are then calculated numerically on the reference element. Specifically, these calculations are performed using the Gauss quadrature method:
\[\int_{E_0} f(\bar{\xi}) \, d\bar{\xi} = \sum_{k=1}^{NGP} w_k f(\bar{\xi}_{gk}), \tag{13}\]where \(w_k\) are the Gauss weights, \(\bar{\xi}_{gk}\) are the Gauss points inside the reference element where the integrand is evaluated, and \(NGP\) is the number of Gauss points.