DEV Community: Paul Stumpe

JavaScript to Swift

Paul Stumpe — Sun, 09 Feb 2020 20:38:06 +0000

Coming from JS to Swift the first thing you'll discover is that const is now let, and let is now var.
Javascript example

const one = 1;

Swift example

let one = 1;

And so here are the errors if we try to reassign them.
Javascript

const one = 1; one = 2;

Javascript error

Uncaught TypeError: Assignment to constant variable.

Swift example

let one = 1; one = 2;

Swift error

error: cannot assign to value: 'one' is a 'let' constant one = 2;

Unlike Javascript, Swift it a typed language. It will infer the type of the value you assign the first time to the best of its ability. But, if you attempt to later assign a new type to that same variable you're going to have problems. Because of its stricter typing rules, and a wider range of types compared to javascript, you have to consider what type of number you're intending to save, for instance. If you need the number to have decimals later, but are currently saving it as a whole number when you first declare your variable, you'll want to let Swift know that it really might be a decimal down the line. As such, you can actually distinguish what type this variable should be holding when you declare it. To do so you'll add a colon after the variable name and write the type directly after the colon before the equals operator or the value.
Good:

let one: Double = 1; one = 1.1

Bad:

let one = 1; one = 1.1

The second example will error, as we didn't inform Swift in anyway that we needed a number that had decimal places so it defaulted to the type of integer. In JavaScript of course, this wasn't something we had to consider.

When using operators on different types in javascript, there is a lot of best tries at coercion. This isn't true in Swift. Here, we need to explicitly convert the type when writing the operation, like so:

let sentence = "The size is " let size = 94 let fullSentence = sentence + String(size)

If you leave out the string declaration on the third, line you'll receive an error. Of course in javascript, the number would have simply been coerced.
Fortunately, Swift provides something extremely similar to template literals, that should be immediately comfortable when mixing string values with other values and variables. you'll use it by typing ().

let friends = 5 let enemies = 2 let friendsSentence = "I have \(friends) apples." let friendsVsEnemies = "I have \(friends - enemies) more friends than enemies."

FriendsVsEnemies here would have a value of "I have 3 more friends than enemies."

I'll be going into more things of note between javascript and swift on my next blog, but one thing to remember if/when you're looking into Swift is that when people reference Dictionaries, they're the Swift equivalent of our objects. They also declare arrays and dictionaries both using [].

var friends = ["bob", "larry", "kyle", "lisa"]

this is an array.
And here is a dictionary version

var friend=["name": "Paul", "hobby":"coding"]

and accessing their values is just a simple bracket notation. friends[0] would give you "bob". To add to an array you can you its append method. calling a method will also be very familiar to JavaScript coders. It would simply be friends.append("Alex") I hope you enjoyed learning about Swift from a JS perspective!

react hook rules and stuff

Paul Stumpe — Mon, 03 Feb 2020 14:58:19 +0000

There's only two rules for React Hooks. First Rule, you don't talk about React Hooks. The second rule of React Hooks? You DO NOT talk about React Hooks.

The third rule of React Hooks:
Always call hook at the top level. Of course you can access their returns elsewhere. But you need to create them at the top of the function. It's important hooks are always created in the same order every time the function is called, as React does not store them by name, but by declaration order. If the order of the hook creation is dynamic, your hooks will break.

The fourth rule of React Hooks:
Never call hooks from vanilla JS functions. You can call them in react function components, or you can call Hooks from custom Hooks.

The fifth rule of hooks: always pass a second argument to useEffect. UseEffect is ready hooks version of component did mount. It will run once upon the component mounting, just like component did mount. Assuming you remember to pass a second argument of an empty array. Leaving out that second argument will leave component did mount rerendering on a loop infinitely though. Beware. You can also include values you want to watch in the array. If you do, useEffect will watch those values and run again on any value change.

The sixth rule of hooks: if useEffect has a return value, that will be your componentdidunmount. So return a function in use effect and you can achieve your dreams of component did unmount in your functional react component.

The seventh rule of react hooks: prefer reacts useCallback function over anonymous functions for use with useEffect and other hook related elements. UseCallback provides built in stability and compatibility with react hooks. It can protect your hooks from unnoticed side effects and other dangers.

The eight rule of hooks: check the included react hooks before creating your own. This rule really applies to many items in coding. I’ll never forget the first time I was coding in reactjs. I built my own version of component did mount. Immodestly I had seen how running something once upon the loading of the component but not on every refresh could be invaluable and immediately started designing a function to accomplish it. When I finished the project I was taking with two friends. One had experience and the other was asking questions about using react for the first time. My friend told him to use componentdidmount which I had never heard of before. I explained, that no, I had simply built a function to run once on render and he should do the same. My experienced friend said yes! He should use component did mount. I asked what are you talking about. And he asked, wait. You didn’t use component did mount. After a long conversation he realized I had gone through the trouble of building an entire function that react supplies for free. We had a good laugh and I learned something. Don’t build a custom functionality before checking if it already exists. This goes just as much for hooks.

The ninth rule of hooks: use hooks. Hooks are fantastic. They’re most coders dream and fulfill the promises of dry development you will right far less code using react hooks than you would with class react components while achieveing the same results. Not only will you write less code though. But as you realize the power of hooks you’ll be able to write simpler code to accomplish previously complex or infuriating challenges. Particularly fantastic is their ability to enable two seperate react components to communicate. Betweeen reacts built in reducer hooks and the way passing hooks around is so much easier than the previous callbacks you can accomplish so much more than before.

What Happens when you click your mouse

Paul Stumpe — Mon, 27 Jan 2020 20:12:47 +0000

If You're coming from a coding background, a mouse click is something you might take for granted. To successfully code an application, we don't need to understand how a mouse click or keypress works, or we might assume we do know at a high level. But when you dive into computer architecture complexity spirals just as quickly as it does when learning code. Today, I want to simplify while giving a still accurate account of what happens when someone clicks their mouse because as long as we're writing thousands of lines of code that depend on user interaction, it would probably nice to know how we're even allowed to interact with those events in the first place.

So, what does happen when a user clicks their mouse? It might go to the event loop or to a handler, but for that to happen first the OS would have to be aware. I mean, how does your computer even know the mouse was clicked in the first place?

Well, how might a computer listen for something like a mouse click. The mouse, upon being clicked, could be wired to change a bit somewhere or file. And if we did that, we could have the computer (the processor) check that file every so often. If it's been flipped from a 0 to a 1, we'd know that the mouse was clicked. But how often would we want to check that file? In a game, we might want to know about clicks every microsecond, and checking a file that often is certainly going to waste energy and processing power. If we check it less often, to be more efficient, we risk a sluggish user interface, not noticing clicks until noticeably late. This is a system that was used in the past and used for other things still. It's called Polling.

Of course, its problems in our use case are apparent from what I listed above. So, we need something better. Well, in the case of polling, the mouse changes something and the processor reacts, but the processor doesn't react until it checks that bit on its schedule. The processor is the prime mover. What would a system where the mouse is the primary mover look like? I suppose the mouse could send a signal directly to the processor. And indeed, that is how our modern systems work.

It's called an interrupt. The mouse or hardware device will send a signal directly to the processor when an event occurs. The Processor must then handle the signal, immediately. This means the processor will pause in whatever function it is running, saving where it is at in the code, and handle the click right then. Afterward, it goes back to the state it saved and continues as if nothing had happened.

Because every hardware event is completely pausing the processor, it's important to handle them as quickly as possible. So, part of the operation then is to do only the minimum amount to document the click, before continuing with the workload. Essiantly, the processor saves the info about the click event and passes it to the Operating Systems scheduler. The OS scheduler will then decide what else needs to be done about it, based on priority and complexity.

Spiral Traversal

Paul Stumpe — Mon, 20 Jan 2020 04:26:12 +0000

Imagine you have a matrix, and you want to return it entry by entry, but instead of by column, or by row, you want to return its elements as if you were iterating through them as a spiral. You would start at 0,0 and then work your way around the entirety of its outer edges, and then one step in. As a coding dilemma, this is an intriguing question. It's really only asking for you to iterate, and yet converting the geometric framing of this question into code can become quickly confusing. This is one of those problems that remind me how important it can be in code to follow the same principles I do in writing. Sometimes, the best first step isn't thinking through everything, it's to just start writing. Get something on paper, or in this case screen, and work from there.

First, we know we're going to be iterating over every element in this matrix during our function, so we might as well start with that.

let result = [];
for (let j = 0; j < matrix[0].length; j++){
        result.push(matrix[0][j]);
      }

if our matrix is composed of nested arrays, perhaps like this :
[
[0,1,2],
[3,4,5],
[6,7,8]
]
then this line of code would get us
[0,1,2]
Well, this is good! Not only have we managed to iterate, which is something we know we have to do, we've also managed to write an iteration that grabs exactly the first three elements we wanted to.
Of course, this isn't the full solution. We need the next line, but simply repeating what we've written on the next internal array won't work. That would give us :0,1,2,3,4,5. But we need the 5 and the 8 next, so this is, of course, no good. We're doing something so similar to what we did above though, we're just moving 'down' instead of 'right.' We can actually use some code incredibly similar to the code above, but instead of iterating over the nested array, we'll iterate over the outer array and keep our second index, the internal index, constant. like so

for (let i = 0; i < matrix.length; i++) {
        result.push(matrix[i][matrix[0].length - 1]);
      }

Well, this is great. Almost. combining our two sets of code so far would give us 0,1,2,2,5,8. We're running down instead of right, just like we intended, but we're catching the 2 a second time on our way down.
I can think of two ways of preventing this. We could catch the 2 again, but add an if statement to check if we've ever used this set of coordinates before. Of course, then we'd have to store every set of coordinates we've ever used, and iterate over that on every element, taking what could be a linear time complexity operation and increasing it to quadratic. That doesn't seem great, plus that solution seems to be missing the crux of our problem. Obviously, we don't want the computer to even START to check an element it's already grabbed before. So why don't we just increase our starting point. instead of i = 0, we can just use i = 1. This does solve the problem but feels a bit like we're hard coding. as we move along, that 1, will have to be 2 if we start in on a deeper layer. the next layer it would iterate to 3. since a single constant wouldn't really do, let's use a variable instead. I'm going to name mine 'space', to represent the spacing in as we go along. Please feel free to use a better name for yours.

Now the next two directions are really similar to the last two and can be pretty easily written by just doing them in reverse, and of course including our space variable. But once we've covered the outer permitter you'll see we have another 'spacing' problem. When we apply the upwards iteration we end up grabbing 0 all over again! This is still a spacing problem, and that space variable being set at one does seem like it could help us here, so on this last line, let's add that into our stopping condition on our loop. instead of stopping at 0, we'll stop it at 1.

Well, if this was called circle traversal we would be done. But unfortunately, we need to move into our next spiral. I think we can instinctually tell that writing any more for loops from scratch to cover this movement would be a hardcoded solution. We've encapsulated the core iterating behavior we want already, we just need to move it into a container, and use a for loop to encapsulate the movement inwards on each iteration. Like below. I hope this has been an interesting and helpful read on one approach to solving coding problems. Don't be afraid to write code! every wrong step is just one step closer to the right step. :)

```const spiralTraversal = (matrix) => {
// TODO: Your code here!
let space = 0;
const result = [];
//fewest lines of code to solve this?
let goal = matrix.length * matrix[0].length;

while(result.length < matrix.length * matrix[0].length){
if (result.length < goal){
for (let j = space; j < matrix[0].length - space; j++){
result.push(matrix[space][j]);
}
}
if (result.length < goal){
for (let i = space + 1; i < matrix.length - space; i++) {
result.push(matrix[i][matrix[0].length - 1 - space]);
}
}
if (result.length < goal) {
for (let j = matrix[0].length - 2 - space; j >= space; j--) {
result.push(matrix[matrix.length - 1 - space][j]);
}
}
if (result.length < goal) {
for (let i = matrix.length - 2 - space; i >= 1 + space; i--) {
result.push(matrix[i][space]);
}
}
space++;
}
return result;
};```

Solving Robot Paths

Paul Stumpe — Sun, 15 Dec 2019 01:54:15 +0000

The question is how do we make a robot travel across a square board of n dimensions from the top left corner to the bottom right corner without ever traveling across the same tile again? But that's just the starting point.

The real challenge is counting how many unique paths the robot can take that are valid solutions. Today, we'll write a function that can solve this for any board size.
Lets start off with some helper functions. The first will make a matrix that represents our board. Then, we'll attach a couple of methods to that board.

const makeBoard = (n) => {
  const board = {};

  for (let rowIndex = 0; rowIndex < n; rowIndex++) {
    board[rowIndex] = {};
    for (let colIndex = 0; colIndex < n; colIndex++) {
      board[rowIndex][colIndex] = false;
    }
  }

First, I like to think about the most basic processes. When we traverse the board we could move up down left or right. But, at the same time, there are places that are clearly invalid, such as -1 column, or a column greater than the length of the board. We also can't travel to any place we've been for. That means we need to mark when we move to an area.

But be careful we need to unmark them when we're done or we'd have to make many clones of our matrix object which would greatly increase the space complexity. Numbers that are too high for the board size would make us reach our memory limit quickly due to the complexity of our solution.

The solution we'll be attempting here will be a brute force solution, that takes advantage of a computers biggest strength, raw computing power.


  board.togglePiece = (rowIndex, colIndex) => {
    board[rowIndex][colIndex] = !board[rowIndex][colIndex];
  };

  board.hasBeenVisited = (rowIndex, colIndex) => {
    return !!board[rowIndex][colIndex];
  };

  return board;
};

const robotPaths = (n, board = makeBoard(n), rowIndex = 0, colIndex = 0) => {

  let counter = 0;

  if (rowIndex < 0 || rowIndex >= n || colIndex < 0 || colIndex >= n || board.hasBeenVisited(rowIndex, colIndex)){
    return 0;
  }
  if (rowIndex === n-1 && colIndex === n-1){
    // debugger;
    return 1;
  }
  board.togglePiece(rowIndex, colIndex);

  counter += robotPaths(n, board, rowIndex + 1, colIndex);
  counter += robotPaths(n, board, rowIndex, colIndex + 1);
  counter += robotPaths(n, board, rowIndex - 1, colIndex);
  counter += robotPaths(n, board, rowIndex, colIndex - 1);
  board.togglePiece(rowIndex, colIndex);

  return counter; 

}



const num = robotPaths(6);
console.log(num)

const makeBoard = (n) => {
  const board = {};

  for (let rowIndex = 0; rowIndex < n; rowIndex++) {
    board[rowIndex] = {};
    for (let colIndex = 0; colIndex < n; colIndex++) {
      board[rowIndex][colIndex] = false;
    }
  }

  board.togglePiece = (rowIndex, colIndex) => {
    board[rowIndex][colIndex] = !board[rowIndex][colIndex];
  };

  board.hasBeenVisited = (rowIndex, colIndex) => {
    return !!board[rowIndex][colIndex];
  };

  return board;
};

const robotPaths = (n, board = makeBoard(n), rowIndex = 0, colIndex = 0) => {

  let counter = 0;

  if (rowIndex < 0 || rowIndex >= n || colIndex < 0 || colIndex >= n || board.hasBeenVisited(rowIndex, colIndex)){
    return 0;
  }
  if (rowIndex === n-1 && colIndex === n-1){
    // debugger;
    return 1;
  }
  board.togglePiece(rowIndex, colIndex);

  counter += robotPaths(n, board, rowIndex + 1, colIndex);
  counter += robotPaths(n, board, rowIndex, colIndex + 1);
  counter += robotPaths(n, board, rowIndex - 1, colIndex);
  counter += robotPaths(n, board, rowIndex, colIndex - 1);
  board.togglePiece(rowIndex, colIndex);

  return counter; 

}



const num = robotPaths(6);
console.log(num)

With this solution, we are essiantly checking all possible paths. When a path eventually leads to a solution we return 1, and if it doesn't we return 0. this way without knowing what the eventual solution will be we still have achieved a number we can simply add. Then we take all of the current adds and add those back recursively.

K.I.S.S.

Paul Stumpe — Tue, 10 Dec 2019 15:48:01 +0000

Today I'm going to be talking through my evaluation of a problem, exploration of a solution, and the route to finding it.
The problem was finding the longest palindrome in a string.

As an aside, a palindrome is a series of letters, or characters, that can be flipped at their center point and remain exactly the same. "mom" flipped is "mom", so it's a palindrome. "dog" flipped is "god" which is its own weirdness, but isn't a palindrome. "poop" is also a palindrome.

Okay, so I know I need to find words that are identical going left as they are going right. Breaking that down, I really just need to see if the character to the left is the same as the character to the right. Which is as simple as using "===". But what about selecting those characters. Well, if I can start in the middle of a word, then I'd just need to move left at the same pace I move right. I can do that with a for loop, just using my iterator as plus for one side and a minus for the other.

Great. So what about saving the result, so I can compare it to any other palindrome I find? Well, I can just declare a variable. This could take the form an array. If we did that, we'd be able to hold all of the potential palindromes we found. Of course, we only need the longest one. So we could just save the longest one as a string. And, if we find a longer one later, we can simply use .length to compare them, and overwrite our variable with the longer one if necessary.
Using a string is pretty effective too, because as we do each check, iterating out, we can simply add both letters to each side of our current string and save it, assuming both chars are equal.

Now, depending on how you've been thinking about this along with me, you may have used your solution for an even or an odd palindrome. What I've said so far applies to both, but there is an important distinction between them. When we check for an even length palindrome, we want to start by comparing the first two characters and moving out. But with an odd palindrome, the center character will always equal itself. Just think about the example of "Wow". There's no need to check on the "o" here, so we can give it a buy really. As such, we really have two distinct starting points, for every run of our loop. And different logic follows from those starting points. It might be easiest for us to simply write two seperate loops, one for odd palindromes and one for even. And to keep code legible, it would behoove us to simply make each their own "helper" function.

//even palindrome checker
const evenPalindrome = function(string, startPoint) {
  let palindrome = '';
  //in case to the left isn't even a palindrome
  if(string[startPoint] !== string[startPoint + 1]){
    return palindrome;
  } else {
      palindrome = string[startPoint] + string[startPoint + 1];
  }
  for(let i = 1; i < string.length; i++){
    const right = string[startPoint + i + 1];
    const left = string[startPoint - i];
    if (right === left && right !== undefined && left !== undefined){
        palindrome = right + palindrome + left;
    } else {
      break;
    }
  }

  return palindrome;
};

//odd palindrome checker
const oddPalindrome = function(string, startPoint){
  let palindrome = '';
  palindrome += string[startPoint];

  for(let i = 1; i < string.length; i++){
    const right = string[startPoint + i];
    const left = string[startPoint - i];
    //if the left and right are equal and not undefined
    if (right === left && right !== undefined && left !== undefined){
        palindrome = right + palindrome + left;
    } else {
      break;
    }
  }
  return palindrome;
};

Now that we've done that, we still have the problem of starting points. We simply don't know where in the string the center of the longest palindrome will be. But computers are really fast. For our purposes, we can afford to try every single starting point. If we do, there's no way we will miss our palindrome. So, in our main function we can simply loop over the string we're given, and for each potential starting point, aka each index of the string, we can run both of our helper functions. if their returns are ever larger then the palindrome we have stored right now, we'll simply replace it.



var longestPalindrome = function(string) {
  //i string
  //o string
  //c white space is valid
  //e empty string should return empty string
  let longestPal = '';

  for(let i = 0; i < string.length; i++){
    let oddPal = oddPalindrome(string, i);
    let evenPal = evenPalindrome(string, i);
    if (oddPal.length > longestPal.length){
      longestPal = oddPal;
    } else if (evenPal.length > longestPal.length){
      longestPal = evenPal;
    }

  }
  return longestPal;
};
//should loop over string, taking each character index as a possible center point of a palindrome
//At each center point, have to check three styles of palindrome
//odd style
//even style, left as center mate
//even style, right as center mate

With this, we've reasoned out how to solve what may have appeared a daunting problem at first. If I had to give one piece of advice to anyone struggling with learning code, it would be K.I.S.S. Keep it simple stupid.
By starting with the simplest parts of the problem, and solving out from those, you'll be able to solve anything. But before you can start solving, you have to stop being overwhelmed by the problem as a whole. My solution to this problem ended up being overly complex and inefficient, but it was a solution. And its starting point was really as simple as the problem of find a palindrome can be. Lets compare one letter, to the other, and see if they match. The truth is, there's no magic to solving problems in programming. I believe the best and worst problem solvers can all reach the same solution. The best thing you can do though, to reach it faster, is to ground yourself. Find the smallest part you can conceive of solving, and build out. Take one problem on at a time, whether than worrying about solving the whole thing at once. If you have ideas for later parts, great, accomadate them. But don't let your fear of running into road blocks on later parts of the problem get in your way from starting a solution.

Just like with blogs, and really writing anywhere, the hardest part of coding is often times the very first words you write. So take what you can wrap your brain around, and start writing. You'll start finding solutions much faster than you expected. And remember Keep It Simple, Stupid.

Solution:

//even palindrome checker
const evenPalindrome = function(string, startPoint) {
  let palindrome = '';
  //in case to the left isn't even a palindrome
  if(string[startPoint] !== string[startPoint + 1]){
    return palindrome;
  } else {
      palindrome = string[startPoint] + string[startPoint + 1];
  }
  for(let i = 1; i < string.length; i++){
    const right = string[startPoint + i + 1];
    const left = string[startPoint - i];
    if (right === left && right !== undefined && left !== undefined){
        palindrome = right + palindrome + left;
    } else {
      break;
    }
  }

  return palindrome;
};

//odd palindrome checker
const oddPalindrome = function(string, startPoint){
  let palindrome = '';
  palindrome += string[startPoint];

  for(let i = 1; i < string.length; i++){
    const right = string[startPoint + i];
    const left = string[startPoint - i];
    //if the left and right are equal and not undefined
    if (right === left && right !== undefined && left !== undefined){
        palindrome = right + palindrome + left;
    } else {
      break;
    }
  }
  return palindrome;
};


var longestPalindrome = function(string) {
  // Your code here
  //i string
  //o string
  //c white space is valid
  //e empty string should return empty string
  let longestPal = '';

  for(let i = 0; i < string.length; i++){
    let oddPal = oddPalindrome(string, i);
    let evenPal = evenPalindrome(string, i);
    if (oddPal.length > longestPal.length){
      longestPal = oddPal;
    } else if (evenPal.length > longestPal.length){
      longestPal = evenPal;
    }

  }
  return longestPal;
};
//should loop over string, taking each character index as a possible center point of a palindrome
//At each center point, have to check three styles of palindrome
//odd style
//even style, left as center mate
//even style, right as center mate

Javascript Isn't Just The Language of the Web

Paul Stumpe — Mon, 02 Dec 2019 19:25:42 +0000

While the core concepts of Javascript haven’t changed much since its inception, the places we can use the oft hated language have rose beyond anyones expectations. Against the hopes of the legions who call it a toy box for front end developers, Javascript is taking over the world, just like it took over the world wide web before. Forget the sugar es6 introduced, forget the burgeoning library of front-end frameworks, javascript is ready for so much more than a desktop browser.
Javascript is an (air quotes) “object-oriented” language, but containing first class functions, leaving a wide open door for function programming styles as well. The problems with javascript are bemoaned on the internet with such frequency you could set your watch to it, so today I’m going to be talking about one of its accomplishments. That accomplishment is simple: It is the number one programming language in the world. Occupying a throne not unlike English when comes to the spoken word, javascript has slowly proliferated everywhere we look from web design to web apps, to desktop apps and native phone apps. The calamitous rampage of JS to take over the world, dragging old-school programmers with it, kicking and screaming “strongly typed” seems to be constant and almost inevitable. And, while the internet bemoaned its chosen warrior, JS, JS quietly crept its way out of our web browsers and into desktops and phones. As I attend coding lessons, I learn the stranger and stranger places that javascript is heading, from game design to augmented reality. And it strikes me that for all the hate and persecution javascript receives, it never stops, and it shows no sign of slowing.

today===javascript //true

Right now, you can learn javascript and never build a single frontend with it. You could learn the language inside and out while building a video game in Phaser, Crafty, PhysicsJs or one of fifteen other libraries or frameworks, or using webGL, or even native Javascript for a turn based game. Even Unity, one of the prime engines for triple A video game titles, ranging from Ori and the BlindForest to The Stanley Parable, can be written in Javascript. And Javascript itself, can be written in a variety of strict and unstrap supersets.
In a world filled with lamenting coders who necessitate strongly typed variables, a hero brought the first light into the darkness of web development. And then another hero, and another hero after that, until their was an awkward mess of superscripts and other stands in that could be compiled down to native javascript. Typescript a script superset of javascript with the clean and clear purpose of making it a better language. Whether it achieves that without ending up overly verbose is up for debate. Elm a strictly functional language, ridding you of those pesky object oriented thought patterns that we all know you are too cool for, Dart a classical Object Oriented language, purescript, coffeescript which started it all, clojurescript, scala, and reason too. The ways to write javascript have a grown just as steadily as the language, but the existence of all these compile ready languages is simply a reminder that javascript has come for us. Run from it, hide from it, it does not matter. Javascript is here. And here. And here as well
A shortlist of where and what you can build with Javascript:
Android, Iphone, VR, AR, Alexa Apps, 2D games, 3D games, AI, Servers, Package Manager, Automation, Desktop Applications, TV applications, Kinect apps, Frameworks, VSCode extensions, Browser Extensions, Xbox, Playstation.

tomorrow === javascript // true

It is my view, that today, if you can think it, you can build it in this language. For all the overdone and overwrought packages and libraries and tools the javascript community has produced, it’s also assured that any problem you need to solve has been solved in at least several half steps for you already. When we dream, it is time to dream not in sheep, not in hopes, not in slow falling Tetris blocks, but in code. And the code of today is javascript. What will you build with it?
(No affiliation or sponsorship from software development languages Javascript, ecmascript, Mozilla or any other entities. The views and words expressed here belong purely to the writer)