Thoughts on React and Typescript

After making some initial effort to learn React and Typescript, I’ll write my thoughts here.

React

I’ve only been using React for about a week now, but instantly I’m a huge fan and I can see the benefits of it. It allows you to break down different parts of the page into individual components. And allows you to write rules with JSX syntax instead of having to write document.createElement over and over again.

This makes it easier to make changes, and easier to focus on individual aspects of the code. And it makes it easier to import components from npm. In addition the create-react-app also sets up webpack which makes it easier to include npm modules into the repository. And the template already includes placeholder for setting up a progressive web app.

So overall, I have a really good impression of React, I can see how it’s helpful. And I might even dare say, it’s the number one most required “framework” to use client-side. In terms of adjusting, I need to change my mind-set from traditional Javascript. Right now my workflow is making static html and css, splitting them off into modules in Javascript, grabbing the elements, adding event listeners, adding data in, and then at the very end adding render functions as needed.

With React a lot of the focus is on rendering. So I need to figure out how and when to fit data into the flow. But I think that will come as I get more familiar with the framework, and don’t have to think about it as much. Another point of improvement I need to make is including Bootstrap via npm, and then including it in the project in a way that makes sense. Which shouldn’t be too hard as there are probably blog posts and videos that I can reference.

TypeScript

TypeScript is one that I’ve having a harder time getting adjusted with. And fundamentally I have a problem with the premise that you define types and the compiler will check the types for stupid mistakes for you. I think I’ve used JavaScript long enough that my brain does a lot of that without thinking, and it’s generally simple enough to convert a string to a number, or a string to a date when you need to, as you generally need to do that anyways when getting a value from an input elements, doesn’t seem like it’s saving you a lot of work.

One aspect that probably soured my experience is rather than trying Typescript on its own, I went straight to trying to use TypeScript with React. And this is a really aggravating experience as it’s rarely my types I’m defining, I need to know what types React is defining behind the scenes. So the compiler yells at me for everything. Passing a attribute into a component, bad. Trying to declare a object as a member of the class, bad. And the syntax is less than intuitive.

import React from 'react';

interface AppMemory {
	app: React.Component,
	header: React.Component,
	gallery: React.Component,
	product: React.Component,
	checkout: React.Component
};

interface AppBridge {
	mem: AppMemory,
	register: (string, React.Component)=>void
};

const ReactBridge: AppBridge = {

	mem : {
		app : null,
		header : null,
		gallery : null,
		product : null,
		checkout : null
	},

	register : function(key: string, instance: React.Component) {

		console.log('Saving %s', key)
		console.log(this)
		//this.mem[key] = instance

	}
}

export default ReactBridge

Here I’m trying to throw in a quick hack, that will let me save instances from different components, and let me call functions on them if I need to. So I make an interface to store the memory, and each key is of type React.Component and that works.

And then the function, I try to define two arguments, the first that takes a string, and the second takes an instance of a React Component to save.

But the compiler doesn’t like this. I can use a React.Component in the attributes above, and it has no problems. But when I try to use it as an argument, I run into problems. This is probably a quick internet search away from an answer, but it goes to illustrate that while React’s syntax is new, it’s intuitive, it’s what you expect. In contrast, TypeScript’s syntax is frustrating because most of the time, I have no idea what it wants. And at least in terms of using TypeScript with react, editing every other line breaks something.

And all of this boils down to the benefits that TypeScript supposedly saves you headaches in production, by catching errors in development. But I still have problems with that, in that TypeScript generally boils down to a few basic types, strings, numbers, and dates. The thing is, generally the flow of Javascript is to get input from an input field, and throw it into a database. Or get a value from a database, and then render it on the screen. So generally data should be standardized by the JSON you throw to the backend, and get from the backend, and there shouldn’t be too many hops between them.

But the most annoying part I find about TypeScript is that, why doesn’t it provide more data types? JavaScript generally works fine because you’re working with a UI which is generally strings, dates, and a few numbers here and there. Strings and dates don’t need a lot of checking, it’s the numbers that Javascript plays fast and loose with. So if we’re taking Javascript from a loosely typed language to a compiled program that is going to yell at you for everything, why not add uint(8, 16, 32, 64, 128), int(8, 16, 32, 64, 128), float, double, decimal? So you can have more control over the numbers to be able to work with numbers directly in Javascript?

Something like:

uint32 a, b, c;
a = 10;
b = 4;
c = a + b;

Should compile down into:

const uint32 = new UInt32Array(3);
uint32[0] = 10;
uint32[1] = 4;
uint32[2] = uint32[0] + uint32[1];

Which seems like it would actually be a huge benefit in terms of being able to offer easy to read syntax for working with Javascript that is annoying to write. Because TypeScript is attempting to be a superset of Javascript, it means you have to append all of these extra gimmicks with semicolons after everything.

let age:number = 5

In this case, this is kind of an extremely simplified example as age is already inferred as a number. But you have both let which declares a variable, and number which specifies the type of variable. Why not just declare the number instead of let?

Number age = 5

In other words if you’re trying to take all of the ambiguity out of JavaScript and tell people not to use the “:any” type, because it DeFeAtS tHE PoInT Of TyPEScRipT, then why even have it in there? Just give me the option to make TypeSc ript to a completely hard typed language and stop spitting on my cup cake and calling it icing. Which brings me to the next part of my rant, that a lot of what TypeScript does can already be done in Javascript.

Like Enums. If you need to declare an Enum, you can declare a constant, and then add in key values to that constant, and then turn off the setter. Which is basically what TypeScript does internally anyways. If you need to sanitize some input you can sanitize input, or throw an error.

And my main complaint about TypeScript is that while TypeScript attempts to be a super set of Javascript, it doesn’t seem to be for JavaScript programmers. It seems to be for all of the other programmers who lost their jobs because the web programming took over the world, and now they complain that JavaScript doesn’t have tupples and enums instead of actually learning Javascript. Or it’s for front end coders who are too stupid to not know they shouldn’t be adding two strings together expecting the output to be an int.

So in summary, most of the benefits that TypeScript offers can be implemented or emulated to some degree in Javascript directly. The syntax is intuitive and adds in a ton of stupid fucking colons, and brackets every where. And if it’s going to yell at you for using playing fast and loose with vanilla Javascript, then it shouldn’t even give you the option.

And my last side rant about TypeScript is where you would use it. Because you can write JavaScript to be explict if you know what you’re doing. And React is the first priority for a client side library, so you pretty much need to use it with React if you’re going to use it on the client. And on the sever, if you really want to use a strongly typed language, you can use something like Golang. So in addition to not understanding what the benefits of TypeScript are, I don’t understand why you would want to use it in the first place. If you use React on the client side and Golang on the server side. Really seems like it’s for a bunch of chimps who sit in front of a keyboard, letting VS Code autocomplete everything for you.

I’ll keep making an attempt to try and learn it, but i keep having to try to hold my lunch down as I do.

https://github.com/typescript-cheatsheets/react

Searching for a Job

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.

Priorities

Thin and Light

I’ve been using my Android tablet a lot. And it really shows how amazing ARM cpu’s are. My tablet battery lasts all day, the performance is more than adequate for everyday use. Really hoping that there is a Linux equivalent of the Apple M1 Macbook sometime soon. Right now the Pinebook pro comes close, but it’s lacking USB (as far as I know) and I would love to have the same 16:10 2560×1600 screen resolution.

PiBoy Advance

For DashGL, I think I want to focus my attention on a hypothetical device somewhere around a GBA, or PSP in terms of form factor. Directional pad, shoulder buttons, four face buttons, start / select / home. The only issue is how much attention is given to the analog stick. Screen resolution is probably somewhere around 480p. Basically, something like the Odroid-Go Advance.

In terms of software i should probably focus on either SDL2 or Godot. In terms of reverse engineering I think I want to focus mostly on DS and PSP.

NDS

– Legend of Zelda (Hour Glass / Spirit Tracks)
– Okami
– Final Fantasy (Echos of Time)
– Phantasy Star Zero
– Animal Crossing

PSP

– Phantasy Start Portable 2 Infinity
– Rockman Dash 2
– Power Stone
– Metal Gear Solid
– Tenchu Stealth

Getting Organized for 2021

Kind of surprisingly I’ll actually be making a post not about hardware. Right now there are a few things for hardware that I want to mess around with. I want to dual-boot windows and elementaryOS on my Thinkpad x240. I bought a Raspberry Pi 4 8GB that I’m not doing anything with. And I want to move more of my VPS’s to host from home to, but that is not the point of this post.

The point of this post is to get organized for 2021. And we’re already into February, which shows how much time flies. But all of the more reason to get organized. So this year, I’m going to list-up the things I want to focus on.

1. Making a Shump – I tried making a shump in college, and it was a painful experience trying to find anyone to work with on it. Now I have a better idea of the process and a better idea of how to commission art to get it done. So I think I can draft out the game, draft out the design, break up the design into individual elements. Create a draft and simple placeholders for all of the elements, either using existing assets, or my own art as a placeholder. And the commissions the assets that will replace the placeholder.

For writing the actual Shump, I’m thinking either SDL or Godot. Though even something like Game Maker Studio might be an option for a (hopefully) simple 2D game.

2. Megaman Legends Assets – For Megaman Legends 2, I finally got my hands on the function to decompress textures. Which means that in addition to the models and animations, I can now add textures to the models. The issue is still going to be matching which textures, to which models get loaded into the game, but I can make debug tools or try to make that process either. Or the likely option is that I could bitch-out and make another save-state viewer.

But I also still need to grab the meshes for the Megaman playable character and start looking into some of the stage models. It’s a ton of fun, and I love reverse engineering games, it’s just time consuming. So we’ll see how much I’m able to focus on digging into the files this year.

3. Dash Model Format – This is actually a big one. And I really want to spend time getting Godot support, revisiting Blender imports and start on exports. And then maybe get into something like Metasequioa. There’s more documentation to be done, and I should start posting videos, or maybe make some reddit posts about it, so I can either start gaining some traction, or gain some more criticism. Focusing more on the JSON format for Javascript and Python, combined with a utility to convert to and from Binary for C and C++ programs might be a better way to go about managing the format from here on out.

4. GTK Model Viewer – The last thing on this list is the GTK model viewer. I think writing a simple model viewer using the GTK GL Area would be good practice, and a fun project to work on. I think I can start by making some sketches on what I want the layout to be, followed by an HTML mock up. I think the focus on this would be to make a Noesis-like application in Linux. Which is why I would like to name this program Gnosis (the GNU – Noesis). I long term goal would be to try and make some animation editing tools, but that would be really getting ahead of myself thinking about that too soon. For now, if I can get the layout, get a grid and get a simple model loaded, then I will be really happy.

Linux Utilities: Ventoy

This is one of the hardest Linux utilities, one of the most important, and one of the easiest to forget. With Linux it seems like even when you find a distribution you like (Debian in my case), it generally doesn’t stop a lot of people from wanting to try other distributions. And for those of us who go distro-hopping, it generally means re-flashing the same USB over and over again with different images using dd, or it means burning a lot of DVD’s. The DVD’s are actually kind of nice to have around, and I’d actually be interested in creating some cover art, and buying some disk labels to decorate my shelf with. The problem with DVD’s is generally they become obsolete pretty quickly.

But there is one magical tool that takes the trouble out of all of this. And that is Ventoy. Ventoy is a simple yet amazing tool. You write it to a USB, and then all you have to do from there is drag and drop ISO files onto the disk. When you boot from the USB, you will then be greeted with a select list of which image you want to boot to. Which means you can slap it on a 32 or 64GB USB and just having a rolling list of all of the images you want to boot to. Pretty useful. The reason I didn’t make a note of it before was because I wrote it to a USB once before thinking that was the end of my issues. Then when I installed Linux, I accidentally wrote over the Ventoy USB trying to install a separate home partition and there went all of my ISO’s.

It’s a useful tool, and I keep forgetting the name. So here it is in blog-form so I can find locate and install the utility again. Next time I use it, I’ll try not to do anything stupid.

Linux Utilities : Deskreen

Occasionally pretty great Linux utilities will get posted to r/Linux. And I think “that looks cool”, and I make a mental note of it. Then a few weeks later when I actually go to to try and use it, I can’t find the post, or remember enough keywords to search for it. Yes, I know there is a save post feature on reddit, but more often than not i forget about it, and don’t really use it.

So I figured that I should make a category on my blog for interesting Linux Utilities. That way I can go back and find them later, and maybe bring attention to some attention to some cool looking projects (as-if there is anyone reading this blog).

The first utility we’ll be highlighting is Deskcreen. And the concept behind deskreen is super cool. Basically it takes any computer with a web browser and turns it into a second monitor. And the reason I think this is amazing as it makes it easy to add on more monitors.

For example at home I have a thinkpad x240. And when I want to attach a second display to it, i have to grab a mini-dp to hdmi converter to put it on my desk and then connect all of the wires to make it work. If this utility works how I think it does, I could basically grab an Android tablet, put it on a browser, put it in full screen mode, and then be able to put it on my desk or be able to pull it out anywhere and have a second screen without the need for connecting wires all of the time.

That sounds extremely appealing to me. So recently I just got a mobile monitor to connect to, so I’m still messing around with that. But if I need more screen real-estate I have the option of trying a tablet as another display. Nice.

Rambling about Javascript Frameworks

– Typescript
– React
– Anglular
– Framework 7

I’ve been looking into switching jobs recently. And while most of my freetime is spent analyzing file formats, my day job is working on web applications. In general my philosophy for web is that I want as little “magic” as possible between me and the code that I’m writing. The easiest example of this is jQuery. Back in the 2000’s there were still a lot of differences with browsers, and jQuery was the hottest library that managed the differences between the browsers, and did it with short and generally intuitive syntax. The problem was that when ever you searched, “how do i do x in Javascript?”, you would get 20 pages of results about jQuery and you had to filter through those to try and find any mention of how to implement what you wanted in vanilla Javascript.

And my issue with jQuery was that while it was a simple and effective way to write code, I didn’t want to have something that was interpreting Javascript for me. Sure it might be easier to write $(‘#elem’).removeClass(‘active’), than it is to write something like:

var elem = document.getElementById('elem');
var class_text = elem.getAttribute('class');
var classes = class_text.split(" ");
var index = classes.indexOf("active");
classes.splice(index, 1);
elem.setAttribute('class', classes.join(" "));

LBRY Videos

Tempted to start producing some videos for LBRY. Content that I have on my head:

– concept for open source handheld
– linux show for kids
– Gameboy Pocket Mod
– Gameboy Color Mod
– Gameboy Advance Mod
– DSiLL Mod
– PSP Mod
– PsVita Mod
– Playstation TV
– Wii Softmod
– WiiU Softmod
– Raspberry Pi NAS
– NextCloud on Raspberry Pi
– Nexus 5
– Nexus 5X
– Galaxy Note 3
– Galaxy S5
– Xperia Z3 Compact
– Pixel 1 / 2 / 3
– Pixel 2xl / 3xl
– Pinebook Pro
– NexDock
– Samsung Dex
– Ubuntu Touch
– Pinephone
– Fairphone
– Mobile Monitor
– Portable Projector
– Chrome Cast
– Cheap Windows Tablet as Linux

DMF 2.0 Specification

Really tempted to start drafting out the specification for DMF version 2.0. One thing I’m tempted to think about is the name. Maybe the “libre model format”? Not sure, maybe I’ll ask around and see what sticks.

Offset 0x00 0x02 0x04 0x06 0x08 0x0a 0x0c 0x0e
0x0000 DASH File Length magor minor header_ofs
– – – – Head Data – – – –
0x0020 META Block Length Count Offset
0x0030 TEX Block Length Count Offset
0x0040 MAT Block Length Count Offset
0x0050 VERT Block Length Count Offset
0x0060 FACE Block Length Count Offset
0x0070 BONE Block Length Count Offset
0x0080 ANIM Block Length Count Offset
– – – – Meta Data – – – –
– – – – Tex Data – – – –
0x0000 texture name line
0x0010 TexId isURL wrapS wrapT minFilter magFilter flipY format
0x0020 centerX centerY length offset
– – – – Mat Data – – – –
0x0000 material name line
0x0010 MatId TexId mat type visible Use Blend Blend EQ Blend Src Blend Dst
0x0020 shadow mat side Use Alpha v-colors alphaTest opacity
0x0030 Diffuse R Diffuse G Diffuse B Diffuse A
0x0040 Emmissive R Emmissive G Emmissive B Emmissive A
0x0050 Specular R Specular G Specular B Specular Coef
– – – – Vert Data – – – –
0x0000 VertexId Position X Position Y Position Z
0x0010 BoneId 1 BoneId 2 BoneId 3 BoneId 4 Weight 1 Weight 2 Weight 3 Weight 4
– – – – Face Data – – – –
0x0000 VertexId A VertexId B VertexId C MatId A Norm X
0x0010 A Norm Y A Norm Z B Norm X B Norm Y B Norm Z C Norm X C Norm Y C Norm Z
0x0020 A Map U A Map V B Map U B Map V
0x0030 C Map U C Map V A Clr R A Clr G A Clr B A Clr A
0x0040 B Clr R B Clr G B Clr B B Clr A C Clr R C Clr G C Clr B C Clr A
– – – – Bone Data – – – –
0x0000 Bone Name
0x0000 BoneId ParentId
0x0000 Local Matrix 00 Local Matrix 01 Local Matrix 02 Local Matrix 03
0x0000 Local Matrix 10 Local Matrix 11 Local Matrix 12 Local Matrix 13
0x0000 Local Matrix 20 Local Matrix 21 Local Matrix 22 Local Matrix 23
0x0000 Local Matrix 30 Local Matrix 31 Local Matrix 32 Local Matrix 33