Next year, I plan on returning to the United States. I’ve given notice at my current job, that I plan on quitting and moving back. Which means I’m looking at dev jobs. And a huge trend I’m noticing is that everywhere requires React and Typescript. And I have really mixed feelings about working with these.

In terms of TypeScript, my first impression was “oh, so like int and float in Javascript?”. But looking at it, it seems a lot more basic than that. Basically it provides a few simple Javascript types like String and Number. And defines variables to be a specific Javascript type. And then it checks that these types aren’t getting mixed in the compiler, and then produces some very basic looking Javascript syntax. As a programmer I find it pretty confusing as with Javascript, if you want to force a specific type, it’s pretty easy to write a few checks for instanceOf or use === to do some quick sanity checks, and raise an error when needed. On the surface level TypeScript seems to solve a problem that anyone with a semi-working brain and a year of Javascript experience should be able to solve.

On the employeer side of things. I think it’s kind of different. If you have a team, I can see how TypeScript could be used as a basic sanity check on a codebase to make sure that stupid mistakes that occurs between team members. And it probably also serves as a level-distinction. It’s pretty hard to gauge how talented a Javascript programmer is, but if someone can program TypeScript, then they probably know at least some fundamentals. Also with WebPack becoming required to build any project, there’s probably no reason not to throw TypeScript in there as well. And lastly, for any scrubs using an IDE, TypeScript probably helps by underlining problems directly in the editor, and showing pop-ups of function arguments and documentation when needed. I switched from Notepad++ to Vim several years ago, so this last one is kinda “meh”.

With React I’m also kind of hesitant, as with my approach, I really don’t think react is needed. I’m not sure if that’s a boastful or otherwise stupid statement to make. But in my case when I approach UI, what I do is sketch it out on paper. And then I make an HTML mock up. And then I go through and create each state of the application, and then define where and when I want different classes to show or hide content. And then from there all i need to do is write small snippets of Javascript to manage the state of the application. In this way most of the application is static contents. And while that might have been a problem a few years ago, these days there doesn’t seem to be much down side to this approach. There are a few instances where I might need to render a list. But I can create the full list with document.createElement, and then replace a single DOM element with replaceChild. Which is from what I can gather what React does under the hood anyways.

My biggest issue with React is how it would massively force me to change how i structure my application. Because I only render a small amount of content, I have a pretty set way of managing all of the DOM references in my application. And specifically when creating lists or dynamic content, it’s a lot easier to use document.createElement to create a dom reference that you immediately have access to and can assign event listeners directly in the scope that you want. In the case of React, I see a lot of “onclick=doSomething()” in people’s code, which looks like something I would have written in my first year of Javascript. I looks ugly, and when I’m not being given the reference to the DOM object, it really messes with the way I want to structure my application.

So these are the issues I have with TypeScript and React. I think there is kind of a silver lining with this. And that is that writing applications like this with web pack might force me to write the client as a static client and then use Nginx as a reverse proxy to separate out the server-side API. In which case I should probably be using Golang or something like that. Previously I did a fullstack engineering challenge where one of the requirements was to use a library such as TypeScript or React, which I completely ignored. I might go back and use that same challenge or approach as a learning experience for using TypeScript and React in a sample project, just to be able to say I’ve done it.

So this was mostly a rant about technologies I’m reluctant to put the investment into, but need to in terms of finding a job. For web libraries that I’m interested on my own right now. Number one is definitely Jekyll. It looks like it can be used by Github and Gitlab to generate pages. So if I can use that to manage some basic pages for documentation or tutorials, it would be great to host most, if not all of my sites as static pages hosted on Github or Gitlab and not have to rent private servers. Private Servers are cheap, but it’s just easier to avoid not having to manage what I don’t need to manage. Assembly script is another. I’m not sure when or where I would need or use that. But it seems like it could be fun. Potentially it could be used for something like packing and unpacking dml model files to and from threejs. Or maybe I could use it to unpack Megaman Legends models. Not sure when or how I’d use it, but either way it seems interesting.

And last is Gatsby / Next.js. And yes, I know this is more React. But it seems like React done right. Next.js seems to have support for multiple languages. But I really like the approach of Gatsby, which is to do everything on the client side and only grab what’s needed via ajax. So there is definitely some fun to be had. I should probably get TypeScript and React out of the way first.

Edit: I was also thinking of Jeykll when I wrote this. I really like the idea of being able to create a static site on Github and then hosting the pages without having to rent a VPS. I think Gitlab has the option of Gatsby (among others) and Github seems to support Jeykll. If there’s an option that works on both, it definitely seems like that would be a worth-wise investment for being able to write documentation, or simply hosting easy blog-sites.