1. Well, I don't only like things to look good

2. I want things to be satisfying I guess

3. Why the f*ck

4. So how do I design?

5. ...

6. I try to walk to the edge of the ring of "done and accepted", then walk back from there until there's a balance of appeal & "my mom would hate that"

7. I sometimes definitely put in way too much effort to walk to places that no one has been to tho

8. they're places like the world's 17th highest mountain, no one cares if I climbed it, but I'd still have to literally scale a mountain

9. The fun things I do are definitely more spontaneous than planned out, now that I think about it

10. Wait, but then I plan out the sh*t I do after I decide I want to do the sh*t

11. This is sounding more and more like a study of chaos theory

12. When I design something, the result has a response

13. Now, is that chaos?

14. What's the "determined"?

15. Yooooooo

Design to me, feels like playing with the box you're supposed to think in. Hit it hard enough and you'll get a concussion, but maybe a satisfying final product as well at the end. As things go though, the questions of, "what tools to bash with", "which parts are the most vulnerable", and "why am I hitting a box", inevitably come up. One question after the next, and I often end up with things that I shouldn't have cared about enough to pursue, like convex hull algorithms just to create a picture grid next to some text written in the style of a forest fire. Thus, I guess all that just means I like design, for the chaos that it causes.

1. online classes

2. the inconsistencies of Android

3. corruption in school managements

4. some mental health bs

5. the limitations of web tech

1. This is already super talked about, with a lot of conversation. It's also kinda boring too xd

2. I didn't think I could do something unbiased, because I haven't used iOS for as long compared to Android.

3. This is kinda political, and uh, writing about something that you're depending on doesn't seem like too great of an idea xd

4. I've already written quite about this beforehand, so I was kinda burnt out by it at that point (ironic xdd)

5. okay yeah that's fresh, why tf not

1. running natively on the client's computer

2. maintained by large entities

3. have the simplicity of the web

The web is a miracle. It has very much succeeded in achieving the original vision of what it was supposed to be — "a place to be found for any information or reference which one felt was important, and a way of finding it afterwards" (Berners-Lee, 1998). Though, some may argue that it has actually superseded the said aim, with the web as we know it, vastly different from what it was (Grinaker, 2019). The web currently houses many non-content driven applications, from simple canvas-based games to whole WebAssembly based virtual machines (copy, 2020). All this sets precedence on the question of, should web and web technologies be used outside of content driven applications? The reason why this question divulges into something less than a simple "yes", is because of the inefficiencies and inadequacies, said technologies bring. "Good enough" of performance and user usability, has been the de facto justification for the convenient use of web technology, as well as better developer experiences being the nail in the coffin (Ghadyani, 2019). The problem arises when said technologies seep into places that have to make sacrifices just to use it. As a user, heavier web based applications are often slow, lack features, or just plainly run with quirks. For example, unexpected user interface behaviours, large memory footprints, etcetra (Koretić, 2020). This even applies to the application examples mentioned above, as they have to deal with the limited WebGL, as well as convoluted workarounds in WebAssembly (Emscripten, 2015). As a developer, you are also handicapped by the "best advantage" of the web — interoperability across devices. You are forced to support many different types and versions of browsers, which means things from legacy javascript APIs that cause mild inconvenience, to platform bugs that break rendering completely (Bureau, 2020). With all that said, a proposed solution exists, and will be explored below — a standardized platform independent wrapper for native platform APIs, with a toolchain resembling the web stack.

web

tech

will

always

be a

sac

-rifice

for

non-content

driven

appli

-cations

it's taking over the world anyways

the line between content-driven and application-driven

content-driven

1. should be feeding the user information

2. the traditional type of "program" made with web tech

3. typically not resource intensive, with majority of business logic living in the server

application-driven

1. should extract information from and exchange information with, the user

2. recent, and increasing amount built with web tech

3. can be resource intensive, running business logic/computation on the client device

where it can be found

• typical websites

• social media apps

• typora

• spacex dragon

case studies: facebook products

• they are the creators of the most popular web based framework — "react"

  • aims to solve the problem of reactivity of user interface components

  • enables said components to react to changes in data with ease while being "performant"

• they are the "f" in "faang"

  • have massive development teams for every platform they create

  • should be able to showcase both the pros and cons across spectrum

facebook

• how they use

  • web is react

  • mobile is react native

• why i choose

  • facebook's flagship app, should have the most work put in it

  • is very content-focused, and thus performs good enough

  • some unexpected ui, eg. expandable drawers that cause big ui shifts

  • doesn't deal with large lists or datasets

  • doesn't contain features that require specific hardware

  • (unsafe) has performance budget for animations, making the experience a lot nicer

instagram

• how they use

  • web version built with react

  • mobile version used to be native, but after bought by fb, now uses react native

• why i choose

  • web version has historically lagged behind mobile app counterpart even though they can share a lot of code

  • mobile version contains bugs and weird problems that come with either replacing native components, or having to run business logic on main thread

  • doesn't always conform to user interface expectations, eg. buttons not giving feedback, sliding drawers not being able to be controlled using gestures, etc

  • can get sluggish while doing simple tasks, eg. switching between tabs, editing profile, exiting and reentering app

  • does the content-focused part very well, the "app" part not really, as when content has been loaded and is being shown, it generally performs well

  • (unsafe) animations in app are stripped back (eg. tab switching) but still present in many places (eg. bottom sheets)

messenger

• how they use

  • web version built with react

  • desktop version built with react native

  • mobile version experimented with react native but switched away in 2017, a rewrite in 2020 stripped away many cross-platform code as well (→)

• why i choose

  • can get very slow on web and on desktop, especially with long conversations, but not on mobile

  • has most features but also a history of being bloated

  • competitors cannot reach its level of features and speed of implementing them (reactions, msg replies, minigames, planners, secret conversations), but they also perform a lot better

  • many many unexpected ui, eg. weird logo menu on messenger desktop, intrusive time popovers on web, confusing message kebab menu, image overlay that cannot be dismissed by clicking on it

  • (unsafe) animations are barebones on web and desktop to make them feel more responsive, but results in them being more unnatural to use

point of views

there are actually two users of web tech, the "user" and the developer

user

pros

• potential better feature parity

  • can reuse code across platforms

cons

• slow (runtime & startup)

  • because of abstraction layer

• lacking/unpolished features

  • because dev needs to deal with limitations of environment (eg. processing, graphics)

• unexpected user interface behaviour

  • dev's needs to reimplement many things themselves, as that is by design of the web

  • thus, best practices like accessibility labels, user feedback, and layout structuring, may suffer

• ram chowing

  • related to speed, because the runtime for web tech needs to be complicated for web tech to perform well

developer

pros

• cheaper to develop for

  • less developers needed to develop for multiple platforms, 1 team for all platforms vs 1 team for 1 platform

  • there are more web developers in the world, as it is accessible with a low skill floor

cons

• you have to write platform code anyways

  • every platform does things differently, and libraries that abstract them out may not be up to par or available at all

• legacy code for not-so-legacy platforms

  • because web tech has to support as much as they can, old API's that were designed without current time language creature comforts may have syntax that sucks, or documentation that sucks

• archi/platform/version/environment bugs

  • a dev will only need to target bugs that appear in their current environment version, which makes everything more deterministic

  • similar to bundling a fixed version of electron, but you would only need to declare the version you're using instead of packaging it together, leveraging the environment's binaries

proposal

make the environment a web browser, instead of having a web browser on top of the environment

more precisely: a standardized platform independent wrapper for native platform API's, wrapped in a web technology-esque toolchain

benefits

• having it built in an env lets it be fixed versions instead of a rolling spec, implementing semver for specificity targets

  • runtime can be built & cached on install similar to android's ART

  • with defined versions, it sets expectations for users as well, and makes it clear when something they want to use require an update

  • something similar is done for C++, VCRedist

  • the larger size footprint can be swallowed by an operating system but not necessarily a browser that has to be downloaded

  • handle versioning differences:

    • if a person has an older patch version, display warning icon

    • if a person has an older minor version, display warning dialog

    • if a person has a older major version, refuse to run

• web tech-esque toolchain enables easy migration & adoption

  • will compile down to machine code

    • better performance, solves biggest compromise of current solutions

  • using something like AssemblyScript & HTML that resembles react native's JSX & CSS

    • will ease adoption

    • will bring over the web's already solid design

    • ease porting over of existing ecosystem, especially dependencies written in typescript

related technologies

react native

• cons:

  • uses web technology directly

    • known for slow start-up times, & especially slow with big lists, large datasets

• pros:

  • is a "wrapper" for native versions of APIs

  • easy adoption, familiar

    • react is popular, with many codebases already in it, and interop between web code & react native code better than any other solution (not perfect at all though)

qt + qml

• cons:

  • uses tech stack foreign to web devs, more common among OS/app devs which might not be familiar with front end

• pros:

  • is a "wrapper" for native versions of APIs

  • compiles down to machine code using C++

glossary

eg. word

eg. definition

runtime

the software you write is the driver, and the runtime is the steering wheel. it helps facilitate the features of an application

abstraction

they're like middlemen that hide working details of one or multiple functions

environment

it is the car that contains the driver and the steering wheel. like a room with tools provided which the software take advantage of, similar to the concept of an "escape room".

user interface

the visual part of a contraption, like a button to start an engine

feature parity

like how similar of a skillset does a group of employees have, in software it would be how similarly would the features be

platform

if the environment is the car, the platform is the road it's running on; a hardware system that contains an operating system

library

a collection of software robots and tools

legacy

old software that is left for compatibility, but won't be removed in the foreseeable future

API

"Application Programming Interface" — like the dashboard of a car or bus that enables the driver to interact with a contraption, either their own or someone else's

syntax

like grammar for a language

deterministic

the result of a task is predictable and able to be determined consistently

fixed version

like a version of an object which once owned, will not be repaired or changed by the manufacturer, eg. a shelf, some food, commodities

binary

a type of file that contains a large list of instructions for the computer

wrapper

another type of middleman that attempts to be an adapter for the driver and the car, like hand throttles for the handicapped

native

software that is designed to run on a certain platform, eg. a driver that is trained to drive on concrete, driving a car on concrete

toolchain

a collection of tools that enables the driver to drive, eg. your mom, that made your arms and legs

rolling release

the opposite of fixed versioning, like a house, which landlords will repair when broken instead of giving tenants a whole new house

semantic versioning

a specification of version labelling that requires version numbers with the format of "MAJOR.MINOR.PATCH"

cache

information that is temporarily stored, typically after being processed. like writing down a grocery list as you remember them throughout the week, instead of trying to compute what you need when you reach the store

operating system

a part of the "platform". OS is the pavement, while hardware is the earth.

patch version

version for backwards compatible fixes, will not confuse the driver. eg. a fixing a crooked start button in a car dashboard

minor version

version for added functionality in a backwards compatible manner, will not confuse the driver. eg. adding a new button but not changing the layout of the other buttons

major version

version for incompatible API changes, will confuse the driver unless its taught/rewritten to understand what is going on. eg. making the steering wheel square

migration

like a driver changing cars, relearning how things work, transferring the driver's knowledge from one car to another, etc

compile

an action for creating an executable program from code written in human readable format, like the transformation of a mother and fathers' DNA into the driver

machine code

the raw instructions that tell a computer what to do, like the raw fuel going into the engine

porting

the action of adapting software from one environment to another, like you teaching the driver a new car

dependency

a piece of software that another piece of software depends on, like a Proton car that uses a Mitsubishi engine

list

a visual representation of a list of items. eg. your contacts list, your insta feed, etc

dataset

a collection of data, like food for drivers

codebase

a collection of source code, like a team of drivers

interoperability

the ability of a piece of software to share or exchange a set of formats; the ability of a driver to to talk to or ask from another driver.

front end

the layer of software that bridges the human to the contraption, eg. dashboard of a car

business logic

logic that deals with data, such as managing databases, or instantiating user interfaces; the brain of the driver

instantiate

create a new instance of a predefined software object, like the driver fully remembering a plan to overtake his enemy's car, and then executing the plan

1. It's hard to understand what you want, but it'll help out the result a lot once you do

2. It's okay to pivot when a piece of work is pulling itself to that direction

3. Don't over-extend too much when making preparations, especially in projects with tight deadlines

4. Consider THREE.js instead (another 3D library for the web)

final String[] tasks = this.work()[2]().tasks;

Chapter[] chapters = new ChapterFactory(tasks).createMany(5);

tasks;

1. write a designer personal statement

2. find a topic that i'm interested in

3. write an intro

4. write the rest

5. write this

chapters[0] == "crisis";

Who am I? Why do I design? The act of writing a design statement didn't seem too difficult on the surface, I know myself the best after all. Everything started to click in place though, as the situation sunk in. The truth is, this wasn't the first time I struggled with self introductions. I went through that process when I needed to create an "About" page for my "Intro to Creative Media" class, then realizing that was the hardest part of writing a site. The fact that the next task on the list would be to write something I liked, told me things were going to be a hell of a doozy.

chapters[1] == "crisis, continued";

I sat down and started to think, why do I actually design? (I literally just sat down and thought, which is why I don't really have many fancy materials to show here xd) Here's my thought process, recalled:

1. Well, I don't only like things to look good

2. I want things to be satisfying I guess

3. Why the f*ck

4. So how do I design?

5. ...

6. I try to walk to the edge of the ring of "done and accepted", then walk back from there until there's a balance of appeal & "my mom would hate that"

7. I sometimes definitely put in way too much effort to walk to places that no one has been to tho

8. they're places like the world's 17th highest mountain, no one cares if i climbed it, but i'd still have to literally scale a mountain

9. The fun things I do are definitely more spontaneous than planned out, now that I think about it

10. Wait, but then I plan out the sh*t I do after I decide I want to do the sh*t

11. This is sounding more and more like a study of chaos theory

12. When I design something, the result has a response

13. Now, is that chaos?

14. What's the determined?

15. Yooooooo

And after that train(wreck) of thought, I came up with a quick draft, summarizing some of the thoughts:

Design to me, feels like playing with the box you're supposed to think in. Hit it hard enough and you'll get a concussion, but maybe a satisfying final product as well at the end. As things go though, the questions of, "what tools to bash with", "which parts are the most vulnerable", and "why am I hitting a box", inevitably come up. One question after the next, and I often end up with things that I shouldn't have cared about enough to pursue, like convex hull algorithms just to create a picture grid next to some text written in the style of a forest fire. Thus, I guess all that just means I like design, for the chaos that it causes.

(Find the final version here)

With that out of the way, I could focus on the next task, which was —

chapters[2] == "crisis, when will it end";

Find a topic that I'm interested in.

Well sh*t. I don't have anything to talk about regarding what I like to do. What am I going to do? Drop an audiobook because I like music production? (F*ck that's actually a good f*cking idea) What I did have though, was an ol-reliable strategy of writing about things that has caused me pain. I mean, it's genius, with failure you remember more details of the situation, and for longer. So, I present to you, my list of pain:

1. online classes

2. the inconsistencies of Android

3. corruption in school managements

4. some metal health bs

5. the limitations of web tech

Oh and also, I present to you my list of why pain is invalid:

1. This is already super talked about, with a lot of conversation. It's also kinda boring too xd

2. I didn't think I could do something unbiased, because I haven't used iOS for as long compared to Android.

3. This is kinda political, and uh, writing about something that you're depending on doesn't seem like too great of an idea xd

4. I've already written quite about this before hand, so I was kinda burnt out by it at that point (ironic xdd)

5. okay yeah that's fresh, why tf not

A little backstory on why that topic came up in the first place. I had been working on a program called "Auto Intro" The idea came from a parody video I made some time ago that gained some traction, about a program that could create "intros" basically only using one button and zero braincells. At the time, I didn't know how to code, which meant the program would stay fiction, until development of it became practical. That time came after I finished my first full fat website, in which I used a library called "lottie", that enabled After Effects animations to be exported into code and displayed on Web, Android, iOS, etc. Before that, I had only poked around with lottie for Android, which was hell to get working properly (because I didn't know much about the Android dev workflow at the time), but I managed to get the web version working pretty easily, and even built a mini animation library around it (have I mentioned how cool that website is). The eureka moment came when I pieced together the fact that I was fluent in TypeScript (a superset of JavaScript), and the fact that the files that lottie used were JSON files (literally standing for JavaScript Object Notation). A match made in heaven? A match made in hell?

By the time I started on this assignment, I'd been developing this program on and off for months now, and had to do a bunch of R&D to get around limitations of the browser. Speed and especially memory usage ended up being way worse for the simple rendering that it had to do, as well as things like needing to introduce otherwise unneeded encoding processes because the hacky solution used to turn canvas frames into video. At the core it was a surprisingly simple program — only really consisting of a UI, a de/compiler for lottie files, an editor for lottie files, and a template generator — but it ballooned in complexity due to the lacking client environment, as well as the lacking developer environment (I had to do extra R&D to develop a solution for working code linting).

All that basically bubbled into my want for a middle ground, something that would solve the client-side problems, as well as my stupid developer ones. That idea of a golden unicorn solution came to be, something with these criteria:

1. running natively on the clients computer

2. maintained by large entities

3. have the simplicity of the web

chapters[3] == "manual intro";

Writing it all down into words was pretty challenging. Initially, the audience for what I wrote was still unclear. I thought I was writing to a "me". This prompted me to put in words, what I thought was going to catch my attention. Unfortunately though, this made it unclear to everyone else what I was talking; a context-less approach.

<!-- insert intro v0.1 here -->

Thus, this v0 was short lived, as I knew I had to pivot.

I started out my refactor with a plan.

<!-- insert plan here -->

I wrote down everything I wanted to talk about — case studies, POV's, related technologies, proposals, a 35 word glossary, and more. It detailed basically everything I had a problem with, and how they could all be solved. It was a magical 1833 word document. Then with the content out of the way I went ahead and rewrote most of the parts, sticking with the same style of writing, depending on additional metaphors to explain my intentions. After 10 iterations, I had a "good enough" intro that I was well satisfied with. It still featured the optimizations to be as clear as possible, reflecting what the passage would say, but at a clarity level I thought was pretty squeaky.

Unfortunately,

I had a big problem.

It was boring.

Around the 8th iteration of v2, I noticed how the dependence of metaphors, meant that most of the essay would be filled with things unrelated to the topic anyways. This caused the experienced people to be bored by all the unnecessary fluff, and the general folk to be confused with the jargon. Then adding insult to injury, the metaphors would end up messy and uncorrelated at the end, as it was hard to convey information entertainingly, educationally, and consistently, in 2 sentences or less.

It was then which I had an idea, why not just make the whole f*cking essay a story? In my tests, I tried to make it as exotic as possible, using wild and epic language to transform the boring topic of the essay into a disney-esque villain arc. It was weird to write at first, as I don't read much of fiction, or much in general, but I sort of got the hang of it as I went. If you're reading this, it already proves the second refactor worked wonders in improving the experience for both sides of the audience. I mean, why else would you be reading another big fat essay if you didn't enjoy the first one?