ECMAScript, or better known as Javascript, is one of the most influential programming languages ever created, carrying most the current web on its shoulders. This story mainly focuses on JS-specific topics or libraries using it.

Wiki Currying

date-fns site

date-fns-tz

day.js

js-joda

If you've ever used moment.js in one of your frontend-projects, you've probably noticed two things:

moment is a very easy-to-use JS-library for date-manipulations

all of a sudden, your app's size was dramatically larger

The main problem with moment.js is that it doesn't support efficient code-splitting via tree-shaking in ES6+. That leads to an increase of about 70 kB in size of your production app, as the lib is this large in its gzipped, smallest version - even if you're only using a handful of the features provided.

At this point, you may have asked yourself if the native JS-

 could do the job, but sadly the native implementation lacks everything beyond basic date manipulations, such as simple parsings to ISO-strings or numbers and vice versa.

The best alternative I've used so far in various projects is 

, which offers modern exports of manipulation-functions, therefore only adding to your size-budget what is really needed.

 style. You don't have to initialize an instance like in moment.js to use the library, every date-fns-function takes an input and returns an output. Using 

, you can very simply and efficiently build up your date-mutations and never worry about the state of your instance such as in moment.js.

 aspect of date-fns, the library offers all its function as a 

. If you're using functional JS-code, you'll feel right at home there.

What date-fns doesn't support out-of-the-box is handling the correct translations to and from timezoned-dates. moment.js provides moment-timezone as a seperate library. date-fns also has a seperate module for this task, called 

I hope I could show you why switching from moment.js to another library handling dates and times may be the right choice for your project. Taking our npm-depdencies' sizes into account may get lost during intense development cycles, yet a good amount of loading delays can simply be cut away when making mindful choices about what to really add to your project.

moment.js alternatives to improve your app's size and speed

Did you know that moment.js actually has huge implications on your app's size?

Why you shouldn't use moment.js in your frontend

(No) One Moment, Please

Javascript: stories by expressFlow

Javascript

Here's you'll find posts about Github, the modern toolchain for web with frontend and backend as well as other stuff around being a Full Stack developer.

Codespaces Overview

Codespaces About

VC Code

Github recently announced a new product they’ve been working on, and it’s quite amazing:

, a real IDE, but fully available in the browser which can be launched directly from your Github-repo.

The core technology behind Codespaces is 

, the very popular IDE build by Microsoft. But how can this even possible in the first place? Well, VS Code is built with web technologies and distributed as app on various platforms via the Electron-framework, which acts as bridge to OS-native function and wrapps your web app in its shell.

There’s no need to set up any dev environment locally on your computer, which can avoid some nasty hurdles when first loading the project.

Furthermore, dealing with secret config’s may also become easier, as everything is now manage directly via Github Secrets, therefore the headache of saving of local configs can be avoided. Yet you're working in a docker image, so the flexibility to configure the project is there.

Regarding the loading time of dependencies, that should be gone for good. According to the about-page of Github Codespaces, all your dependencies are directly available. Nice!

As of writing, you can only participate in the completely free beta by invite, which means 

. Every Codespace run in a Linux-container, which has to be considered. According to the documentation, VS Code extensions are supported, which sounds great!

As soon as I’m able for a first hands-on, I’ll write a new blog post about it. Several questions are still open, probably the most important one for me is if web-app-development is supported, i.e. building a React-app. I’m curious to see how this project will evolve and can’t wait for a first try!

Github Codespaces IDE, cloud native

Github's in-repo IDE, always available in the cloud

Github's in-repo IDE, cloud native

Github IDE

Snowpack 2.0 release

snowpack

create-react-app doc

Building a full-fledged frontend application is nowadays easier than ever, thanks to great frameworks like React or Angular, the mature state Javascript and Typescript have reached and the whole Node/NPM-ecosystem. One aspect of frontend development though that’s quite tedious yet results in massive performance gains (or losses, if done incorrectly or not at all) is the building step. It takes all your files as defined in a build-configuration and usally tries to minimize and transpile them to a older version of JS. If you’re using something like create-react-app, the whole setup for the buliding is hidden and already implemented. This also applies to the bundling during development, where you're files are processed before being available on your local dev server.

The most two common tools for building & bundling these days are Webpack and Parcel. Each offer a wide variety of small and large gears to adjust so that the output created matches your preferences and requirements. As great as these tools are, they come with one caveat: the process can take quite long to start up and during development, when the bundler serves your files from localhost. Why? Because large chunks of your app have to be rebuild every time you make a change, even if the change itself was just small.

Snowpacks aims to fix this lag by serving your files unbundeld during development. Every file in your project can be interpreted as function, where the input is the file’s content and the output a cached version of it.

B/c no bundling is done at all, the local dev server starts up immediately and only processes the files required at the given point in time. So even if your project grows very large, startup won’t be affacted much. If you want to setup Snowpack for yourself now, there’s a CLI-tool called “create-snowpack-app” to bootstrap your project for various targets such as a React-app.

And when you’re ready to deploy, Snowpack 2 still offers a build-command, which minifies and optimizes  your codebase for production. The library is used by some well-known companies such as Intel or the Internet Archive, according to the site’s documentation. So if you have some spare minutes, it’s worth trying out!

Snowpack is a modern build tool for frontend and alternative to webpack

Snowpack is similar to Webpack, yet uses quite a different approach

A new alternative to Webpack

Snowpack

Overview

Let me start this post like that: Github's Readme just got a whole lot more interesting! Well, that's a sentence you probably thought to never read, but as it turns out, the busy team at Github has widened the use of Readme-files in your repos.

To be more precise, you can now use a Readme.md to show in your account's overview page. Let's see how it can be done!

First, we need to set up a repo with your account's name as the repo's name, if not already done. Please make sure that you've entered the name correctly, even down to case sensitivity.

I'll use my personal account for demo purposes here, but you can create a profile Readme with every type of account.

Upon repo creation, Github already tells us that there's a fancy new feature to explore! Just check the mark to init with a Readme.md file, else you have to manually add it later. When everything is ready, create the repo.

The stock-Readme looks very blank for now, but as a first step that's fine. To verify everything works as intended, click on your account-name's link in the upper left corner.

And there it is, your brand new profile Readme! Of course, that's only the starting point, as some very creative people in the community have already created fancy additions to enhance your Readme in various ways. Check out the link below to explore!

Github Profile Readme

Github allows you to create Readme-file that is shown when viewing your GitHub account 

New Profile Readme for your Github account

NPX Intro

You've probably seen it here and there, but didn't really know what it does exactly and, to be honest, didn't really care - that's how I treated NPX after I first saw it. Yet little did I know what mighty and handy library NPX is and how it would change my workflow for the better, as it did for the whole team! So without further ado (to once again use my 18th-century-English, as keen as a mustard), let's take a look at it!

 the dependencies in your project - no more, no less. NPM can add other libs to your project, remove them and keep the overall dependency-state sane across various users of the project thanks to its lock-file.

But what you can't do with NPM is do much else with your external modules. Sure, there's the 

-key in package.json, but that helps you only add predefined routines or custom ones, such as build and deploy, which are callable via 

And just like most npm-users, you've already used certain special commands in your scripts, which are provided from installed dependencies. As an example, you can call the 

-tool by installing mocha and firebase-tools, respectively.

And when using such tools, npm always threw an error if the related library wasn't installed globally, ergo in a special place on your mechanical calculator, consumable by every npm-project.

But what if you don't want global depdencies? What if such tools should be used on a per-project basis? Introducing NPX.

(although I couldn't find a scientific valid source for the exact meaning, which is odd!), and its job is not to manage dependencies, but to look into the currently available project (based on your current path) and allow you to execute said tools locally.

You can call any tool in your project via 

 and execute it locally, without having to install anything globally. This means that

, all your depencies get installed, same for every user of the project - this means after installing, you're instantly ready to go!

safety for your dependencies - a globally installed tool might be too old or too new to work in the current project, using a local module solves this problem, as the tool's version always represents the currently correct one to use

If NPX doesn't find the the tool installed locally, it automatically installs it (transparently for you) in a seperate global directory at the latest version and caches it there. This works as a fallback.

NPX comes bundled by default with the current NPM-install, so you can use it right from the get-go.

And that's about it for a brief introduction to NPX vs NPM. By using NPX, you can avoid errors and the hassle of handling global dependencies. You just install your external modules once and can safely use any tools provided - and every member of your team as well.

There's much more to learn and be amazed of regarding NPX, so if you're curious, just check out the link below. Thanks for the read!

NPX - differences from NPM and how it boosts your workflow

See how NPX works in tandem with NPM as a separate library to boost your workflow

See what NPX does and why it's different than NPM

NPX - Farewell global dependencies

Node.js Wiki

Node.js site

VS Code Terminal

MDN Javascript

Localhost definition

Server with express.js

Online playground

Hi there, my name is Tom and I’ll walk you through the very basics of Node.js and NPM, including explanations on how to develop for the web in general. Just a note upfront: if you’re familiar with basic web development and NPM, you can skip this article and 

learn more about the very useful NPX here

If you’re reading this, you have probably already downloaded 

 and started with tipping your toe into the waters of 

. Yet the first steps might already seem scary: “I just want to write a little program in Javascript, why do I need all the other stuff?”. That’s understandable, but really not a big deal at all.

Let’s start at the beginning: You can simply create a Javascript-file everywhere on your computer, indicated by the ‘.js’-suffix. This file can be filled with code any way you want, but then there’s one thing missing: how do you actually run your program? That’s where Node.js comes into play.

, explicitly for Javascript. As the description implies, Node can run your Javascript code in a specific environment Node itself provides. The process is always the same: you first start Node.js, and when Node is spun up (which means it has finished starting) you can provide it your Javascript code.

There are two ways your Javascript can be provided to Node as input:

Directly to the running Node-process, line by line, no files included

By telling Node which Javascript-file to load, without any line-by-line input

After you’ve successfully installed Node.js (which is just downloading + running the installer, descriptions are on Node’s website), you can start-up Node.js from everywhere in either your Terminal (macOS/Linux) or PowerShell (Windows). The command looks like this:

Yeah, that’s all! You’ve just successfully launched Node! Did you notice how fast this happened? One of the reasons Node.js is so popular is precisely because of its blazingly fast bootup (among other things).

Now that Node is up and running, we can define our Javascript-app line by line. Each input is processed and stored in memory. Here a little example:

Now that’s all fine and dandy, but writing larger apps requires us first draft them in files before feeding to Node. Next chapter, please!

For this example you need a text editor. Basically you can use every program that can manipulate text (such as TextEdit on macOS or Editor on Windows). I recommend the open source 

, but you can choose whatever fits your ergonomics best.

To provide a file as input, we’ll just have to create one. Just create a plain text-file with the suffix ‘js’ in its name. We’ll name our file 

. Now open your command prompt of choice (the one used in our first example). Make sure you open it from the directory where the file is saved, that’s important.

If you’re using VS Code, you can use its built-in command prompt,  just right-click in your Explorer-view and call “Open in Code” (on Windows) or drag-and-drop the directory containing the file on the VS Code-Icon in your Dock (macOS). Then you can open its terminal 

When the terminal is ready, just type in the following command:

Node started directly, with no user input available

Node ran your whole file from top to bottom until it reach its end

Node itself terminated, as the file’s end also marked the end of its process

And for a basic introduction to Node.js, that’s it! Once you’ve downloaded Node and first experienced the usage of the command prompt for launching your very own Javascript app, either line-by-line or from a file, you’re officially a Javascript dev! Welcome to the club!

I will now walk you through the core concept of 

. After the next chapter, we’ll quickly look at the connection between Node.js, NPM and the web development. If you want to learn more about Node.js, you can check out our stories about Javascript, toolchains and everything coding-related 

. I’ve also linked some useful resources at the end of this article for even more stuff to learn.

As you’ve seen, it’s not that hard to manage your own code. The app can be stored in a file, changes you apply just stay. But what if you would want to use someone else’s code, say a cryptographic or image-manipulation library? You somehow have to put that code next to your own, make it usable for your application and keep everything manageable.

A naive approach would be to just download external code directly from the source, e.g. Github, and copy the library, file by file, into your own project. But that leads to a few problems:

How do you best update this external code? Copying by hand is not the best solution.

How do you keep track of all the code that’s external?

What if this external code itself relies on libraries, which aren’t installed in your project?

All these challenges are tackled by NPM, a 

. A package manager’s job basically is to give you a robust solution on how to add, keep track of as well as remove external code, also known as 

. Here are some examples of NPM in action:

Naturally, this manager needs a few special files itself to keep track of all the dependencies in your project. That’s why applications using NPM have at least two files:

. You can call the following command to quickly create a new NPM package:

Note: as we’ve seen in the first part of this article, NPM is not needed to use Node.js or Javascript. Its focus is managing your dependencies - no more, no less. Through NPM you can download code that’s published at npmjs.com. All these external modules are stored in your project in a special directory called 

. You’ll practically never have to alter this directory, as it’s fully managed by NPM.

The package.json gives you insight into your currently used dependencies in the project. package-lock.json is a special file that stores some metadata about mutations regarding your package.json-file or the node_modules-directory and can be ignored for now.

I think I’ll wrap up my description of the very core concept of NPM, what it does and what files/directories it automatically generates. Further information is linked at the article’s end.

Nice, you now know the fundamentals of Node.js and NPM. But why on earth is all this stuff even necessary to learn if you just want to start creating your own modern website?

As we’ve just seen, NPM allows us to download code from a vast collection of libraries (the largest in existence, to be precise). For web development, you will need a server that can host (that is, provide) your web app. There are plenty of services available where you can upload your website-project and use an existing infrastructure, including servers, to make the website available on the web.

And for local development, a server is also required to load your local files and make them available only to you, on your device, during development. Thanks to Node.js, you can just do that: making your website available locally via a so-called 

. Node.js has the tools built in required to launch a local server, but through NPM, you application can be enriched with battle-tested components that can help you create very large services in a short amount of time.

Of course that’s just the beginning: NPM hosts so much code for building modern web apps (known as 

, “progressive web app”) as well as complex servers. But for a first introduction, I think that explanation should be fine.

I hope I could help you get a grip with Node.js and NPM. First steps are always the hardest, but biting through the first days of development and (a lot of) learning will be rewarded with your skills expanding into the development of modern web applications, enabling you to be built whatever you want to.

Node.js and NPM - what they are and how they work

If you're just starting your journey as a Web and JS-dev, read this

WebAssembly example with React and SwiftWasm

To get started you need the following tools available:

 (and optionally wasmer or another WebAssembly runtime)

your favorite IDE (I use Visual Studio Code)

Pretty simple, pretty straight forward we use create-react-app to bootstrap a React app.

I use two options here as you might noticed: 

The . instead of "my-app-name" - this creates the React app in the current folder

--template cra-template-pwa-typescript - this template bootstraps all settings for a TypeScript based Progressive Web App with React

and open http://localhost:3000 you should see the lovely

As SwiftWasm is as the time of writing (December 2020) not part of the official Swift repository you have to download the latest release (with December 2020 - 5.3.1) from their website and install it by hand. But it's quite simple:

Set the path to be able to start the toolchain from your command line:

To check if everything works fine just type

Ok let's do a pretty basic example to see if everything works as expected.

Compile this (rather basic) swift code to WebAssembly bytecode

Great! We have our first WebAssembly generated from Swift-Code 🚀

The easiest way to run WebAssembly bytecode is wasmer: 

BUT: Before you download the runtime ride away - there is a "bigger" package available that might fight your needs better: 

 (which uses wasmer internally as runtime afaik).

So let's install carton - a "watcher, bundler and test-runner for SwiftWasm-apps"

As carton installs wasmer as a dependency we can run our previously generated WebAssembly bytecode right away:

Exposing a function from Swift Web Assembly to JavaScript

Ok as we are all set let's write some code that actually works between WebAssembly and our React Web App.

Start off with the Swift code we want to expose to the React app.

A pretty straight forward swift function taking two arguments and returning a result of type Int.

The @_cdecl("add") is an attribute that exposes the function for the host environment - in our example the WebAssembly. Cool!

 This compiles the Swift file to a add.wasm WebAssembly. That's it for the Swift side. Simple!

Let's create a new component in our plain vanilla React app which actually handles the loading of the WebAssembly:

The complete source code of the React component can be found in the 

At first we instantiate a new WASI and WasmFs instances.

This is rather straight forward from the 

Something special is the loading of the WebAssembly itself in the async function loadWasm():

To instantiate the WebAssembly-Binary the 

 requires an ArrayBuffer. Nothing special but we needed to figure that out as it was not straight forward.

After finishing the instantiation of the WebAssembly in the React async function we are ready to access the exposed function with 

The TypeScript code can then access the addFn and call it like a TypeScript-function().

Let's call it in React and click the Add-button

Liked the story? Stay up to date and follow us on 

WebAssembly example with SwiftWasm and React

Let's write a simple web app with react and use a web assembly with SwiftWasm

WebAssembly unleashes the best performance for web apps

Toolchains & Utilities: stories by expressFlow

Toolchain & Utilities

CRA CLI

React

React Blog

Hi there, Tom here. As I was sitting and thinking about what nice little learning tip I could tell you next about, I started to revel about that one time my crew and I fell into a trap of the "Icnoyotl"-tribe of the Amazon River's Upper Delta back in the 1920s. There we were, only having one day of food and zero hope left. Our only chance of survial was to convince the tribe's elder that I'm a god called "MEGABYTE", controlling the earth and the sky with my sheer power of will.

But sure you're here to read about how to best import an SVG-file in your CRA-project, so let's talk about it! This little trick can save you a great amount of time, as CRA's webpack config allows us to import SVGs like in the following example:

, which can either be used directly or renamed, as I have done here. If desired, you can directly set width and/or height via their props:

This will keep the SVG-view contained to the defined boundaries. And because it's just a React-component, you can also provide all standard React-props, such as 

All Blog Stories