DEV Community: Hamilton Greene

Svelte is better than React

Hamilton Greene — Wed, 23 Mar 2022 03:07:00 +0000

Svelte vs React

Svelte is a new web framework that provides the ability to build web apps - similar in scope to React, Vue, and Angular. Though it's new, it's already become one of the most loved - ranking in the top 2 most satisfying and most loved web frameworks for the past 3 years (see State of JS and Stack Overflow's Developer Survey).

Adopting new technologies into your projects is risky - they may not be fully functional, you may not get the support you need, and they may not stick around for very long. This can leave your project in a worse state than it was before adoption.

In this post I'll share why I believe Svelte is better than React and the factors I took into account before deciding to adopt it into my own projects.

Simplicity

The first major win for Svelte over React is simplicity. Simplicity is important for many reasons but it all comes down to just being easier to understand.

Easier to onboard new developers
Easier to spot and fix mistakes
Easier to scale to a bigger code base
Easier to "move fast" and not break things
etc.

The simpler your code (and easier it is to understand), the faster you can write better code which means the faster you can complete projects.

Simplicity - Code Style

The first thing you'll notice when you look at Svelte code is that it just looks normal. It looks almost exactly like normal HTML with in-line code and styling. Normal JS, normal HTML, and just a few imports to pull in extra features.

This makes it easy to get started as long as you've seen some web code before - much easier than picking up some of the language-specific code required for React (JSX).

React example:

import React from 'react';

function App() {
   return (
      <h1>
         React example
      </h1>
   );
}

Svelte example:

<h1>Svelte example</h1>

Simplicity - State Handling

State Handling is where you really start to see the difference in complexities between Svelte and React.

React historically didn't have a primary way to deal with state, federating this job out to third parties to handle. This leaves you with an extremely saturated ecosystem of different state handling software to use with very little standardization.

Eventually React did decide that state handling is a core part of a web framework and so introduced the idea of Hooks. Hooks work well if you know how to use them, but they're a vastly different programming paradigm than most people ever see / use and they have so many gotchas that they tend to trip people up with high learning curves.

All in all, React leaves you with a lot of choices to make and each of those choices incurs its own learning costs which adds to the complexity.

Example of a React Hook - Each time you click the button, the count increases

import React, { useState } from 'react';

function Example() {
  // Declare a new state variable, which we'll call "count"
  const [count, setCount] = useState(0);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Clicked { count } times
      </button>
    </div>
  );
}

Example based on official React docs.

Svelte takes a more opinionated approach giving you a standardized way to deal with state right in the framework. It's easy to understand and looks and feels like normal Javascript.

Example of Svelte - Each time you click the button, the count increases

<script>
    let count = 0;
</script>

<button on:click={() => count = count + 1}>
    Clicked {count} times
</button>

Example based on official Svelte tutorial

As you work with more and more complex state management (like global, async updates, etc), Svelte's opinionated design continues to outpace React's in simplicity and dev velocity.

Speed

Simplicity leads to better, faster code but it's not the only factor. For many large organizations and smaller companies looking to grow, performance is a large consideration and can be make-it-break-it for their products.

Speed - Performance

If you're serving 1000s of users or more at a time, performant code can be a factor in keeping the user experience smooth, saving on your hosting bills, and in some cases keep your service from shutting down.

Since we're comparing two frontend frameworks (Svelte and React), most of the performance here will be located in the user's browser and on the edge of your service (for transmitting web payloads and server-side rendering if you're doing that). But we'll still talk about it as it's a meaningful comparison and can be very important for the health and feel of your service.

In the performance test results shown above, we can see that overall Svelte at least paces with and often beats out React, Vue, and Angular across many different performance-related exercises. For your users, this will typically mean a snappier website and less time waiting on frontend operations.

Potentially a bigger factor - particularly in slower networks and off of wifi or at scale - will be the payload size these frameworks incur. This is important because this must be downloaded by the user's client in addition to anything else that lives on your website before they can actually see or interact with it. So for users on slow networks this can mean more time waiting for your site to load and for websites at scale this can mean a lot more egress cost for you.

Currently for the full packages:

React (with ReactDOM): 42.2kB (gzipped)
Svelte: 1.6kB

Now I want to call out that these sizes are both relatively small so on most modern sites they will often be dwarfed by the primary content you're serving. But at scale they can add up.

Google Homepage: 968kB transferred (23x React)
New York Times Homepage: 7.0MB (166x React)
HAMY Homepage: 456kB (10x React)

Speed - Dev Velocity

Now while a lot of developers and analysts really like to focus on the speed and performance of the code, I still think that the number one performance issue affecting most teams and projects is actually the speed at which developers can make changes and push reliable features - their dev velocity.

Due to the Simplicity wins from Svelte, I still think Svelte offers this both in terms of onboarding new developers and maintaining mature apps. But it's still new so we'll need more data points from real projects to know for sure.

Caveats

As I mentioned at the beginning of this post, there are a lot of risks when adopting a new technology. So it's important we weigh those against the benefits before fully commiting to it.

Adoption + Community

The first big caveat is that Svelte has a very low adoption rate right now with just 20% of surveyed web developers saying they've used it before (see: 2021 State of JS).

React - 80%
Angular - 54%
Vue - 51%
Svelte - 20%

What this means is that there's not as much community involvement as you might get in other framework ecosystems. This will lead to:

Less code libraries available specifically for your framework
Less Q&A on Stack Overflow and examples on GitHub
Less support from some of your favorite technologies

This makes sense as many developers prioritize communities with large followings but unfortunately Svelte just isn't there yet.

On the bright side, Svelte continually places in the top spots for Satisfaction, beating out every major web framework in the past 2 years (including React). So while there may not be as much adoption yet, it's definitely not hindering the experience much.

Stability

Svelte is still relatively new in terms of maturity. There has not been a huge team supporting and backing the project which means less code pushed, less design discussions, and less overall strategy directing the project (especially when compared against React or Angular which has Facebook and Google backing them).

So far this lack of support doesn't seem to have hurt the project much as it's extremely well-crafted and beating some giants at their own game - performance and dev velocity. But it is something to look out for in case the project takes a sharp turn and makes breaking changes or dies altogether.

On the bright side, Svelte is being adopted in major organizations and sveltekit (svelte's version of React's NextJS) has been sponsored by Vercel which has a history of supporting web-friendly projects.

A few well-known orgs using Svelte (pulled from the Svelte homepage):

IBM
Square
The New York Times

Svelte is Better than React

I am a backend engineer for the most part and when I venture into the frontend (mostly by necessity) I like things to be fast and simple. Svelte provides that simplicity without sacrificing any of the modern, performant features of other major web frameworks.

So for me, Svelte is the right choice. All the benefits, none of the complexity.

I'm so bullish on this decision that I decided to migrate my SaaS boilerplate CloudSeed from React (NextJS) to Svelte (Sveltekit). Its goal is to make it fast and easy for any developer to spin up a fully-featured Software-as-a-Service application in minutes - complete with Authentication, Data Models + Migrations, and Checkouts / Subscriptions. As such simplicity and performance are top of mind so that any developer can use it for any kind of SaaS business.

Anecdotally the migration from React to Svelte took just a few days and the frontend codebase was vastly simplified and improved in the process. I've still got the React code checked in so if you want to compare the differences or get your hands on a ready-to-sell SaaS project, head over to CloudSeed.

This post originally appeared on my website HAMY.LABS.

16 sites I used for inspiration in my latest portfolio redesign

Hamilton Greene — Thu, 12 Nov 2020 14:07:36 +0000

Overview

I recently redesigned my websites to make them more efficient, sustainable, and accessible than ever before. Redesigning a website (in my case 3) takes a lot of work so I wanted to make sure that the design I came up with would serve me today and into the future.

To do that, I gathered inspiration from sites around the web that I liked and compiled a Pinterest board to help me organize my thoughts. Here I'll share those sites along with why I wanted to use it as inspiration for my own sites.

Inspiration

Medium

medium.com

Medium has always had a beautiful reading and publishing experience. Their new design puts a spin on their traditional sleak and minimal styles, making more elements 'pop' with greater contrast between their neighbors.

I wanted my sites to be accessible first and I thought Medium did a good job of bridging accessibility with aesthetics which is why I added them to this list.

The New York Times

nytimes.com

Similar to Medium, I'm an avid reader of The New York Times. They have a very to-the-point manner of writing and I think that mentality is also displayed in their web design. It's simple with good accessibility and shows you as much as it can without feeling over-cluttered.

I like to write so this idea of keeping it minimal while still showing people as much as you could appealed to me - if it can work for the New York Times' readership, it could likely work for me.

Herokidstudio

herokidstudio.es

Herokidstudio has a beautiful site as one might expect from a design studio. But what really caught my eye about this site (and something I've been meaning to implement in my new site) is the clean minimal design with a focus on a creative coding element. I'm a Creative Technologist and when I saw this page I immediately felt a connection with it - like "that's what my landing page needs to look like.", and it kind of does (sans creative technology)

I really liked this landing page because it's straight to the point with it's messaging, giving the user the most important info first but then it has this element that draws your attention and urges you to linger - I think that's part of building a memorable experience and getting return visitors. Plus, for me, it could double as an advertisement for my skills and maybe even lead to some collabs down the line.

K2

https://www.k2.pl/en

Another digital agency with a beautiful site. I love the simplicity and bold messaging. It's just what you need to know and nothing more.

I really liked the post lists available on the site too, I thought it was clean while allowing enough list elements to not feel sparse.

itsnickki

https://itsnickki.com/

I liked this site because of its clean design but I saved it because of its project list. I liked how simple it was, how easy it was to understand what each was, and how it didn't feel overcrowded.

It's something that I didn't quite get right in this redesign but I'll keep tweaking it.

Allen Tan

https://www.tanmade.com/

Similar to Herokidstudio, this site features an eye-catching, mouse-drawing example of creative coding. Moreover, I think it does a great job of pushing the important stuff front and center and moving everything else to the fringes.

The work section of this site also made the inspo board due to its excellent image-heavy project portfolio.

Devon Stank

https://www.devonstank.com/squarespace-pricing-tables

This inspo may seem a little odd as it's more about the method than the actual example. Here the author is demoing their product directly in their writing as opposed to writing about it. I think there's room for more showing and less telling so I included that here as a reminder.

Angela Nguyen M

https://angelanm.com/

This site is bold and up front in its messaging and in pushing you to look at projects. I build a lot of projects - it's a big passion of mine - so putting them front and center has always been on my mind. This site does this extremely well and even adds in a bit of creative coding for flair.

Steph Parrot

https://www.stephparrott.com/plantd/

One thing I really love about this site is its flow - it feels like I could just keep scrolling. In particular, when you reach the end of the page there's a section that recommends featured projects to keep reading into. I think it's brilliant and could definitely get a few more projects in front of people.

Another thing I like about the site is the landing page and its inclusion of links directly in the primary text. To me it makes it feel a lot less formal and more human.

Brittany Chiang

https://brittanychiang.com/

There are a lot of things I like about this site but for me the coolest part - and what landed it on the list - was the live GitHub data being displayed in a widget at the very bottom. I like building projects on real data - I find it super satisfying - so this was a reminder that maybe I should do that too.

Qode Interactive

https://qodeinteractive.com/catalog/

There are two things I really like about this site. The first is the minimal and bold text lists for their projects. The second is the full page dropdown menu as it gives you more screen real estate to add calls to action like subscribing to your newsletter and learning more about you, all while being cool enough not to feel like you're being advertised to.

wearebackstage

https://wearebackstage.com/#

Similarly, this site has a nifty full-page expanding menu.

We make.

https://wemake.be/en/cases/

I really, really like the way they made the asymmetric projects lists look great. I don't really know why it looks great because it certainly doesn't align but it does. I should probably take some pointers from them on my own projects lists.

Another thing I liked about this site was its simple, bold approach to messaging and the color-blocked calls to action at the end of the page. (see https://wemake.be/en/)

Tobias Ahlin

https://tobiasahlin.com/

This is an all-around cool site but I think the standout feature is the color-blocked, interactive link grids. They're beautiful and they're so fun to play with you'll probably end up clicking one.

Another thing I like is the huge call to action available at the end of each page.

Patrick David

https://bepatrickdavid.com/

It's an all-around beautiful site

Wokine

http://wokine.com/

This site gets me from 'Hello.'. I really want to incorporate more of these bold, animated elements in my sites.

Wrapping up

So those were all the sites I used as inspiration in my latest site redesign. If you liked any of them, let me know and maybe even drop the creator a compliment.

Hopefully this list gave you some good inspiration to use in your own redesign. I know looking back at these got me inspired to make my site even better.

Peace, love, code.

-HAMY.OUT

Scaling my sites by 12x by moving to Tailwind

Hamilton Greene — Wed, 28 Oct 2020 00:55:44 +0000

Overview

This month I redesigned my sites to be more efficient, more sustainable, and more accessible than ever in an effort I've dubbed iamhamy 3.0. A core component of this redesign was moving from Semantic UI to tailwindcss for my site-styling needs. Through this redesign I calculate that I've raised the total number of visitors I can serve per month from ~500k to around 4.4 million - an ~12x increase in scalability.

(Yes, I realize those numbers don't match up. Keep calm and read on.)

In this post I'll touch on the redesign, my experience with Tailwind, how I host my sites, and how I got these numbers.

iamhamy

Before we go onto the scalability numbers, it's first useful to understand how I serve my sites and how I'm defining scalability. I've written about this before in How I scale my sites to 500k users per month for free and most of my hosting paradigm remains the same so here I'll just go over the basics.

I use Netlify to host my sites. They provide a clean, easy-to-use hosting platform that just works. I love that.

Through them, I currently host 3 iamhamy sites, each auto pushed from their code repo. An important thing to note is that I host my static files on Google Cloud Storage.

Scalability

I run all my sites on the Netlify free tier. In this tier, I get 100GB of bandwidth for free. The 100GB limit is how I measure the scalability of my sites.

This includes all assets served from Netlify to the end user - my HTML, my CSS, my JS, etc. This is why I called out that my static files (like images and videos) are served through Google Cloud Storage as they do not contribute to this 100GB total.

Thus my measure of scalability is how many people I can serve without having to make a change to my sites / hosting plans. With this context, we can now move into how Tailwind affected this measure of scalability and how scalable my sites are today.

Tailwind

I talk a lot more about my recent redesign in iamhamy 3.0 but for our purposes we can note that the core values I designed with were efficiency, sustainability, and accessibility. When I say efficiency here, a major component of that is its ability to scale payload-wise.

In my analysis of my site's scalability with Semantic UI, I found that the average payload of my webpages served from Netlify was 107.8 Kb and users navigated to ~1.74 pages / session on the high end. Put those together, and my sites could serve ~533,000 people / month.

Enter Tailwind - stage left.

Whereas Semantic UI had a served footprint of 101kb, Tailwind comes in at just 7.6 Kb! This tiny footprint is one of the major reasons why I ended up choosing it.

In total, my pages now come out to ~12.9 Kb of data served from Netlify. We can calculate the total_visitor_capacity with a pretty simple function:

def total_visitor_capacity(
    pages_per_visit,
    payload_per_page,
    payload_per_plan
):
    '''
    This function assumes that payload_per_page and payload_per_plan
    are in the same units
    '''
    return payload_per_plan / (payload_per_page * pages_per_visit)

We can then run this analysis with inputs:

pages_per_visit: float = 1.74
payload_per_page_kb: float = 12.9
kb_per_gb: int = 1000000
gb_per_plan: int = 100
kb_per_plan = kb_per_gb * gb_per_plan

We then find that with a ~12.9 Kb payload and 1.74 visits / page, iamhamy 3.0 can scale to ~4,455,136 users / month - an 8x improvement over the previous Semantic UI site!

For my previous analysis, I actually looked at a relatively small page - Connect - so for a more accurate scalability comparison we should use the payload of that same page (now built with Tailwind) which comes out to about 8.8 Kb / page load. Running those numbers, we get a (contrived) scalability measure of ~6,530,825 users / month - a 12x increase over Semantic UI!

(This is why the people-served and scalability multiplier number in the Overview don't agree.)

Debrief

So that's how moving to Tailwind from Semantic UI allowed me to increase the scalability of my sites by 12x and to serve 4.4 milllion users / month for free. Will I ever need this scale? One can hope but I served less than 4,000 / month in Q3 so likely not soon.

A more important question is did I have fun with a close followup being would I do it again - and the answer to both of those is a yes so like / subscribe / share to keep this fun chugging!

Thank you for your time.

-HAMY.OUT

My 2020 H1 in review

Hamilton Greene — Wed, 08 Jul 2020 13:59:48 +0000

In the first half of 2020, I participated in my first art exhibitions, created music videos, served my sites to 28,930 visitors, made art for good, achieved a 50% savings rate, embarked on socially distant explorations, and set ambitious goals for the rest of 2020.

My name is Hamilton and this is my 2020 H1 in review: https://blog.iamhamy.xyz/posts/2020-h1-review/

My 2019 programming language hierarchy

Hamilton Greene — Thu, 28 Nov 2019 21:18:28 +0000

Earlier today I was considering which language I should use for an upcoming project and realized that 1) I had a good amount of experiences / context to argue for each side and 2) that I'd had similar internal arguments in the past for many other projects so I thought this might make good content for a post. In this post I'll try to delineate my current internal hierarchy for languages, why I have them in this order, and any other relevant info that comes to mind. I have a feeling this will be extremely controversial (how do you compare two languages?) but by doing this, I hope to 1) know what I think by getting these thoughts outside of my brain and on DOM, 2) get some feedback on where my thoughts disagree with those of others, and 3) archive this so I can revisit it in future years.

Not every language that exists is listed here cause I don't actually consider every language known to man to build my projects in. Hopefully that needs no further explanation. Also I'll probably be wrong about a lot of things I declare in this post, that's part of the reason (#2) that I'm posting this in the first place.

Onwards.

top languages

These are the languages that I have front of mind to tackle a project with.

python

Until recently (really when I joined Instagram where they use Python a fair amount), I had kind of written Python off as a programming language. Before IG, I had really only used Python in side projects in high school (omg so long ago!) and for academic projects (you know, those half-baked, built-for-a-5-minute-demo code blobs) so I'm assuming that lack of ecosystem exposure is really what stunted this relationship for so long.

Anyway, Python is now my go-to language for pretty much any project where performance is not paramount. It's simple (almost beautifully simple without sacrificing code ergonomics), #justworks pretty much everywhere, and has a huge, active community of people making it better and creating projects for almost any goal. This means that I can get up-and-running very fast and the internals are so good that I could reasonably create a robust system for almost any scale.

The only downside I've seen is really just performance and that only seems to matter when you need to do things extremely fast and / or at really high load (when small performance losses really start to add up). For most of my projects this is a fine trade off.

In fact, the only time I've really run into an issue is for complex / media-intensive projects. For instance some of my #webz outputs (example below) take several hours to complete where in a faster language it may be a magnitude smaller (though I'd bet much of that is just due to my own code inefficency, lul).

A #webz output

Some things I was pleasantly surprised to find well-supported in the language when I dove back in a few months ago (they may have been there all along and I just didn't find them /shrug):

unit testing
mocks
async
typing

python pros

simple
fast enough for almost everything
great, huge, and active community
a package for almost anything you're trying to do
just works
just works everywhere

python cons

not great for super intensive jobs (thinking live video stuff, big / complex image manipulations, etc.)
at high scale you may also feel burden of relative slowness (like startup times on lambdas that get hit a ton)

python conclusion

For almost every project, I first see if Python makes sense. It just works and can get up-and-running super quick. That makes it my top choice.

cSharp

Before my first gig out of college (at APT), I had never written a line of C#. My idea of it was that it was a monolithic, legacy language that only old, crufty enterprises used in the same realm as COBOL, Visual Basic, and PHP (lol).

To some extent, I feel like that hunch wasn't totally off - I don't see that many startups / people writing their stuff in C#, but that doesn't mean that they don't exist (they do). However after really diving in (mostly writing in it for ~2 years), I've found it to be a really well designed, fast, and safe language that, again, just works and is getting constant updates from Microsoft (and after open sourcing, I'd assume many others as well). I often announce my like for C# with "C# is basically a better version of Java". #fightme

On top of C#'s speed and ergonomics (big fan of Linq - it's functional-ish syntax - as well as its normal syntax), C# has been widely used in the industry for quite some time so, similar to Python, has a devoted community with many packages and docs for much of your needs. Also it's the primary citizen of Unity which I've been eyeing for a while for future, more complex (think 3d!) iterations of audio visualizers, like moon-eye:

Some downsides of C# is that I feel like there is some friction in just getting started (there are a good amount of dependencies you need to DL), I'm not 100% confident in the cross-platform experience (though anecdotally I run Linux and C# has worked fine and they're def working on it), and I feel like the build process and common libs like web frameworks etc. just aren't as simple to use as Python (though if you compare to many other languages, they're still far simpler imo).

c# pros

pretty darn fast
big community
been around for awhile so lots of docs and battle-tested libs
works everywhere, mostly
a well-designed language

c# cons

slower than Python to get up-and-running
I still don't feel that cross-platform is a first-class citizen in the ecosystem, even if the standard language is 100% cross-platform rn
I don't think that C# is a first-class citizen in many cloud platforms (for instance Google Cloud doesn't currently support C# for its version of lambda, though AWS does)

c# conclusion

If Python just isn't fast enough, I'll see if I can use C#. C# doesn't seem to have quite as many libraries for #everything like Python, but is much faster, works cross-platform for the most part, and feels v nice to write in.

Rust

I'll be honest, I'm more of a Rust fan-boy than an actual Rust developer but it's still one of the top (3rd) languages I usually think about when considering what language to build a project in. The main reason for not yet taking the plunge is it's kinda hard.

Don't get me wrong, I think that it's an extremely well-designed language and it seems like the internet agrees. But I've read the book (great book btw!) and tried a few times to get simple programs working as expected but each time was like "ugh, f this I could've written this 5 different ways in Python, stood up a website to interact / show off / ingest it, and written a launch post by now" and then stopped and written it in Python.

I think what gets me is the necessity to think about how your program is handling memory, both from the ownership aspect and size / location aspect. Of course you've had to do this in other languages like C and C++ for instance, but that's one of the reasons both of those are near the bottom of my hierarchy. It's important because that's what all these languages are really doing behind the scenes - altering data - but I just don't think it's necessary for me to really need to think about this - Python and C# seem to agree.

But I think it's something that is good to know and that's one of the reasons why, despite this feature (not a flaw), that Rust is still in my top 3. I just need to find a problem that could benefit from its speed enough to warrant me taking the leap (and / or just take a month and make it happen).

Okay so that was a lot of barf all about why Rust is bad so why's it good? Well it's supposed to be super duper fast, it's a language that is said to be most "correct" in that if you can get it to compile then that thing will likely run 5ever unless there's like catastrophic interference (though this adds to the learning curve cause you've gotta fight the compiler to make it pass), it's got like every modern feature and is actually pretty ergonomic / pretty to write in minus maybe all the memory Boxing / Unboxing #magic, plus it's cool and new.

Like I bet if I rewrote #webz in Rust, it would be ~10x faster than the Python implementation (though also think it would take me 10+x longer to write than the Python one).

A #webz output

Rust pros

v fast
has all ze modern features
v type safe / strong emphasis on correctness
a pretty language, minus all the memory things
extremely active community

Rust cons

memory (Ahhh!)
high learning curve due to focus on "correctness"
new-ish and community isn't quite as big as others so less things written / documented

Rust conclusion

Rust is a language that's basically on my "wish list". I've never written anything substantial in it but it just seems super cool and if I can ever get over my fear of memory management maybe I'll be more than a #fanboi. #swoon

middle languages

These are languages that I'll use if it's really the right tool for the job (like if a framework / lib / assignment / project / domain requirement is that I write in it) but that I don't default to if I don't have to.

javascript

Oh Javascript. Honestly Javascript has come a long way since I first started using it (or more accurately, I've probably come a long way since misusing it in blobs of nested JQuery callback hell), but it's not my favorite language. Like if I'm writing a server thing I'm almost definitely gonna choose !Javascript. But if it's something that I want visitable by a browser then probably Javascript (though wasm may change that (and entice me to use Rust!!1)).

Javascript is cool cause it's a first-class citizen (really primary) of web and web is accessible like everywhere and thus it's a great and flexible tool. It's pretty simple and when you add that to its inherent domain reach, you get a very large and active community of devs creating lots of packages and docs for you to use. Like any large and active community there's gonna be some good stuff and some maybe-not-so-good stuff (like I always try to prefer Mozilla Developer Network over W3schools but if W3schools is the only one that has it then fine) but this is almost totally a plus.

Javascript just isn't suuupppeeerr fast though browsers have done a great job making optimizations to make it run v fast. It also isn't that cross-platform. Like I'd say Javascript runs on the web, but wouldn't really say it runs on Windows, Mac, or Linux though you could certainly get it to.

One thing that Javascript is super good at (partially due to the maturity of the web as a platform, the maturity of this particular usecase, and its near-total-coupling with HTML / CSS (though you could argue some frameworks like React get it away from this)) is UI creation, design, and interaction. So while I might not use Javascript to do my heavy application lifting, I probably would consider it for creating a frontend for that application lifting (even over system-native UI frameworks / libs, mostly due to low cross-platform capability #buildonceruneverywhere).

javascript pros

primary web citizen (for now) so it basically runs everywhere
huge, active community so lots of docs and libs
simple
v easy to get up-and-running (open in browser)
really great UI ecosystem

javascript cons

not really cross platform but kinda
not suuuppppeeeerr fast

javascript conclusion

I use Javascript for web things. If it's not a web thing (like gets hit directly by a browser) or have a UI, then JS probably isn't involved cause it's not super fast, isn't as easy as Python, and not really cross platform.

go

Some people love Go. I am not one of those people. But I think I understand why.

Go is pretty fast, like 2/3 the speed of C in my mental model. It's pretty simple with simple syntax and setup. It works everywhere (I think). It has a strong community.

But I think it's ugly and it feels so simple that it's almost tedious.

That's really my only complaint with the language, but that's enough to get it down to #5.

go pros

fast
simple
good standard library
good community

go cons

I think it's ugly in that it's too simple
I also don't like the whole organization structure they force you into, though maybe that's changed since last I touched it (and I know there are workarounds but I am #lazy)

go conclusion

I'll use Go if I'm contributing to a project in Go or someone wants to build in Go or I need to build in Go, but I'm not really ever thrilled to write in Go.

java

Java is there. It's been there. It'll continue to be there.

It works well, has a huge, mature community, and is continually being updated. But I think C# is a better version of it. So I'll just use C#.

java pros

fast
works everywhere (I think)
big, active community

java cons

I think C# is better
seems kinda old and outdated, idk

java conclusion

Java will do what you need it to do but I prefer C#.

bottom languages

These are languages that I'm going to go out of my way to avoid.

c / c++

People will probably rage at me for slapping these bad boys together. But those people are likely already raging at me for other things I've said so what's a little more #rage?

These languages are fast and feel like they've been around forever. They kinda feel like the ancient ones that are all powerful but have huge downsides. You know like Zeus and all his random courtships that somehow end in tragedy.

Of course some people love them but I think those are the people that are willing to take the time to really get to know them through many hours of tracking down memory leaks. I'm not one of those people (right now) as I've spoken to in my section on Rust. So for the time being, I'm trying to give these languages some space.

Also I wrote a few C++ programs for a graphics class in college and I didn't really understand the math nor the language so think I may still be scarred from that experience.

c / c++ pros

mature codebase and community, so lots of docs and lots of libs
v fast - I'd almost say that they're the gold standard for performance in the programming industry but I don't really know anything about that
I hear they're getting more modern! but also that some internal structures are making them hard to modernize but idrk

c / c++ cons

ew, memory
They don't seem very fun
Rust is shinier

PHP

I've only written in PHP once in college and I've only dabbled in Hack (Facebook's PHP fork) at work a bit so I don't have much real experience to back up these opinions with. Of course, I don't have a lot of real experience to back up many of the preceding opinions so I'm not going to let that stop me now. Onwards.

The internet doesn't seem to look fondly on PHP. But also a ton of people use PHP. Mixing that in with my own experiences, I'd say that PHP works. Though it might have some serious downsides. But it'll probably work for you if you want to use it.

But you don't just have to work, you also have to be better than Python for me to want to use you all the time. I currently don't think it's achieved that thus I mostly won't use it.

PHP pros

A lot of people use it, so probably lots of docs / libs
Can be pretty fast (I think)

PHP cons

not better than Python imo
internet seems to have some bad feelings towards it, but I didn't really do my research so idk

Swift

I don't really like Apple things. Swift is an Apple thing. But it's also one of the Apple things I like most, so this whole paragraph is really nil in the grand scheme of judging Swift.

I don't usually like Apple things cause they often make it very closed-system. My only evidence is that I have a Pixel and I can't do those funny reactions that iMessage users love so much and everybody complains when I turn a group green. QQ

But all that baggage, again, isn't really Swift's fault. Everyone I know that uses Swift for iOS development (and even some server-side!) says they like the language. But it seems (from like 5 mins of reading) that it's not super easy for Android. Maybe more of Apple's closed-system things, idk.

Anywho mostly I don't use Swift cause I've never had a good enough reason to try it out. Again, if it's not better than Python for my use case then probably not gonna use it. I don't do much mobile dev so that's probably a big factor in this scenario but there you have it.

I'm skipping pros and cons cause I don't really know that much about Swift.

Swift conclusion

I don't do much mobile dev and I haven't heard much about Swift being a lot better than Python for non mobile so I haven't tried it and likely will continue not to.

Assembly

Too low-level. V verbose. Kinda confusing. I choose Python.

fin

Thanks for listening to my long-winded programming language rant! That's all I've got for you (for now). If you would like to discuss a point I've made in this post / provide feedback / give suggestions / just rage you can contact me via methods listed in my contact page or just comment below. If you want to read more rants from me, consider subscribing.

Always building / ranting / posting

-HAMY.OUT

Updates to my vanillaJS audio visualizer: consistency across processor speeds, smooth DOM animations, and real-time adaptation

Hamilton Greene — Sat, 16 Nov 2019 17:01:24 +0000

This month I'm focusing on touching up / improving my current projects. As part of that effort, I've gone back and given moon-eye a facelift.

algorithm change

The major change in this release is a modification to how the audio processing engine works. I used to use a standard average of a fourier transform of the input audio over the last n cycles to create a baseline of recent audio then see if the newest input was higher or lower and pump that into the visualizer to increase or decrease pupil size.

old alg

I was using a set count of averages (and there was one average per cycle), this meant that different processor speeds would have different history lengths and thus would have vastly different experiences.

To offset the variability of history lengths, I bumped the pupil change multiplier so that when it hits it really hits and when it misses it really misses so that the visualizer was always energetic. This was okay, but due to the differences in sizes that was pumped into the DOM, the pupil animation would tear (the "teleporting" effect) all the time which I don't think looked very good.

The alg was very dependent on the kind of song for performance. Because we're working on averages, we risk having a song that's very consistent constantly hitting and missing the increase condition causing an energetic visualizer even though, from human perception, nothing's really happening. Moreover, if we were to pick an arbitrary threshold to prevent this visual "noise" (which I did), some songs would benefit from this whereas some songs may get "swallowed" by it as they're just naturally less variable when it comes to audio components leading to a dead visualizer.

Here's an example of the old visualizer:

new alg

To fix this, I first changed the history check from being based on element length to being based on time. This means that faster processors will have a more granular history (as they'll usually have gone through more cycles in y time) but slower processors will still be able to utilize moon-eye as it was intended. Of course, this introduces additional risk of memory overflows as the size of the history datastructure is now unbounded by memory size, but these values are so small that it usually won't matter.

The second thing I did was to modify the multipliers that control how much the pupil increases / decreases at any one time. This results in a smoother experience overall, though has the side effect of creating a less energetic visualizer. I like the smoothness, so think it's a fair tradeoff.

The last thing I did was to add in a mechanism for adaptive thresholding. Basically I wanted to defend against the visualizer performing poorly on both high and low variable songs. To do this, I implemented a threshold ladder that the visualizer can switch to every x seconds based on the hit rate over the current history window. This means it can adapt to both high and low variable conditions over time, so even for a mix which might contain large diversities in the songs / sounds it employs, the visualizer can still adapt to perform reasonably well.

Here's the new visualizer at play:

give it a spin

moon-eye is live on my site (with a new landing page, too!), so head over and give it a spin.

Lmk if you have feedback / suggestions via my contact page.

Always building,

-HAMY.OUT

Post-mortem: My 2019 Job Search

Hamilton Greene — Mon, 17 Jun 2019 16:45:41 +0000

Last week, I finished my 2+ month full-time job search. It wasn't easy. But it also wasn't particularly hard. It did however take lots of time, lots of effort, and lots of thought. Here I want to walk through my process for both posterity and the optimistic thought that it might help you, reader, in a future search of your own.

My name is Hamilton and I make money as a software engineer. This is my story.

Right-clicking on the chart and opening in a new tab might make it a bit easier to read

listing your goals

My search consisted of ~2 months of active search and perhaps a month or so of passive / irregular thought / actions before that. This is a lot of time to spend on one thing and is roughly consistent with data I got from my peers about their own searches.

Knowing this (and looking back now I can confirm) I thought it was a good idea to list out the things I cared about / wanted to focus on in the next step of my career. These can then be used to compare opportunities against what you actually want / value as well as compare against the opportunities at your current company to vet whether incurring the moving cost is even worthwhile. I found that having these goals readily available helped to focus my search as well as remind myself why I was going through this effort (very useful during the frequent weeknight study sessions).

Your own goals will likely be different, but here are mine for posterity.

Experience with larger scale: Coming out of college, I was interested in how enterprise systems worked together to create a cohesive whole. Up til then, I'd only worked on relatively small codebases for classes and side projects and understanding how hundreds (and in many cases thousands!) of services much larger than anything I'd written could work together to produce something useful was beyond me. Having been in the industry for a little while I can now say that I'm starting to get it and along the way have only increased my interest in large scale systems / architectures. But one question that has continued to elude me is how these systems remain resilient under extremely high load - like millions of users simultaneously performing a sleuth of actions against your platform. This is something that's hard to experience in my own side projects (unfortunately Mine for Good is still mostly mined by me /tear) and thus something I felt I needed to find out in the wild.
Jumping into a new platform / organization, seeing how it ticks: Any time you start something new, there's always a learning curve. It's during this time that you might not be having the largest impact / output but also where you're undergoing an extreme amount of learning. I'd noticed that my learning had started to plateau and so I wanted to make a significant change in my day-to-day to re-initiate that process and continue on that path.
Lead bigger projects w more responsibilities: Over time I've come to realize that I like to build things and that I learn things best when I'm experiencing them hands-on. I've gotten pretty comfortable working on small parts of apps and services and want to continue growing by building bigger and bigger things wrt scope, impact, and, in some cases, pure size. Each of these aspects brings with it different challenges and I see these as fundamental hurdles to advance both in my career as a software engineer and personally as someone who likes to build.

finding opportunities

So I had some goals that I wanted to pursue in the next step of my career but you'll notice that most of them are really around problems areas and don't really prescribe any qualities about an org that would be able to furnish them. This was good in that there were a ton of places that could give me these opportunities. This was bad in that there were a ton of places that could give me these opportunities.

So I kinda just started looking everywhere using some basic filtering to weed out deal-breakers. Those deal breakers for me were 1) if I couldn't stay in NY and 2) if they were known for having a bad culture / bad tech. Tbh this didn't get rid of that many cos but it was a start.

One benefit of casting such a wide net was that I could hedge my bets against opportunities and leverage all the prep work I was doing across them to effectively increase the value of the average worst case scenario and simultaneously increase the average best case scenario. A win-win at the cost of marginal additional load for each additional opportunity I decided to pursue (as most everyone interviews in approximately the same way).

I went about this opportunity search in a few ways:

my brain - keeping a list of companies I thought were cool and that I might want to work for. This was good cause these companies had some sort of implicit attraction for me but there were also a lot of misses as a lot of the cos I liked didn't have large engineering organizations in NY. Which still baffles me but that's the way it is. That being said, I do think it's getting better so probably won't always be this way.
my peeps - It's always good to ask your friends what companies they like and who they've heard are good to work for.
the internet - I expanded my search through places like LinkedIn, BuiltInNyc, and Reddit to see where other people were saying were cool places to work
being open - many sites are recruiter-focused so I set myself to "looking" on LinkedIn and StackOverflow just in case people were looking for candidates with my skills. They were and I actually got a good amount of leads from there.

prepping

Tbh, if we were doing this post chronologically, this section would've come before finding opportunities but we're not. I think prepping should start before finding opportunities (or at least before reaching out) because 1) prep work can take a lot of time, especially when you have to do it on top of other responsibilities / priorities and 2) many cos will have a pretty quick turnaround which means starting your search before your preparation can lead to being caught off guard.

I've already written a post on my preparation process so I won't rehash it here. It's got all the deets though so go read my SWE interview guide if you're curious.

My guesstimates are that I spent ~53 days and ~1.5 hours each of those days studying. There were definitely some days where I didn't study at all but others I was studying 6+. So, in total, I'd say I spent about 79.5 hours just studying for interviews.

interviewing

The interview process itself takes a lot of time and energy. There are generally 3 kinds of interviews 1) online phone / code challenges, 2) on-sites, 3) take-home tests. Take-home tests are kinda just homework so we'll focus on 1) and 2) going forward. In addition to the actual interviews, there's a good amount of planning that goes into the scheduling and matching process, tons of emails and phone chats.

Here's the breakdown from my process by type:

And roughly the amount of hours spent on those, in aggregate:

So I spent around 15.5 hours on chats, 15 hours in interviews, 40 hours in onsite interviews, and about 3 on takehomes. In total, this means I spent ~73.5 hours in interviews or in the process of scheduling interviews.

Most processes will have you first go through 1) in order to screen candidates and then if you pass that section go to 2) which usually consists of 3-5 interviews on various subjects - data structures and algorithms, system architecture, and behavioral. Each interview runs ~1 hour and you're going to use that entire time either problem solving or talking. So it's very active and there's really not that much time to zone out. As such, I think it's important to know that these days aren't going to be easy and to do whatever prep works for you beforehand so that you put yourself in the best place to do well.

For me, good prep is just sticking to my normal routine.

a good night's sleep
a shower
a meditation session
a large coffee and substantial breakfast
some sort of physical activity at night to work off the stress

But YMMV

That being said, even with good prep and staying healthy, it's still possible to burn out.

My rule of thumb was

only 1 onsite / day (w/ no other interviews)
only 2-3 online phone / code challenges / day (w/ no other interviews)
limiting these packed days to 3 times / week

There were definitely times where it wasn't possible to stick to these rules but I found it helped to keep my schedule manageable and to prevent burn out from one interview to the next.

deciding

After doing this process for several weeks, I finally started getting some offers. This posed the dilemma of how I choose between them. A good problem to have to be sure, but not a particularly easy one.

Of course I'd made my goals at the beginning of this process and I was able to use that to distance a few from the pack but at some point there were still options that checked all the boxes. From there, I felt I had to go deeper to better differentiate. I did this in a few ways:

prioritizing my original goals
looking at other metrics I cared about - culture, people, tech, career prospects, TC
reflecting on how I felt - while feeling shouldn't be how you make all of your decisions, I find it a fallacy to completely neglect it as well

Last Friday, I came to a decision and thus concluded my 2019 job search.

Woo, yeah! I'm done, finally! AHHHHHHH! I can read other books, do other things, stop dreaming in DS&A...

things I did well and things I didn't

well

I gave myself plenty of time to study and take interviews: Originally I had planned for the search to take only one month but it ended up taking two. I had a large vacation planned at the start of that second month so this actually put me in a position where taking the second month off completely was the optimal choice for me. As a side effect, this allowed me to really focus on my interviews in that second half which is also when most of my time-intensive on-sites were. This allowed me to be more prepared and to space out these interviews at a cadence that worked for me. I was in a good position to do this due to good life habits and some careful planning in the preceding months but I really do think this helped and would consider something similar in the future.
I put increased emphasis on preparing through mock interviews: During my last search I mostly just studied the technical side. However looking back after my second job search, I've come to realize that the technical side is really only half the battle. Where a lot of people struggle (me included) is in the realm of clearly communicating and executing on a technical problem in a time-boxed environment under high (depending on your own personal social anxiety) pressure. Going through mocks helped me get used to this process in lower pressure environments which really helped during the real thing. I list some of the resources I used to help me with this in my SWE interview guide.
I cast a wide net: While this incurred additional overhead through scheduling and executing interviews, I think it helped in many ways. 1) it meant that I could leverage my prep work across many different opportunities and thus see a greater array of options, increasing the likelihood I got something that really fit. 2) it meant that even if I failed a few I knew I had other opportunities coming up which helped keep me out of a slump when things went bad - as they did and inevitably will.

didn't

My timelines were overly optimistic: I had this idea in my head that I'd be able to do the entire job search in 1 month. I didn't. Partly this is because of procrastinating on preparation and partly this is because of my vacation in the middle, however if I'd tried to go through this whole process while also working I think it would've been even longer so it kinda evens out. I think next time I'll be more conservative with my timelines and try not to schedule so many non-interview things during the process.
My resume really sucked at the beginning: When I first started applying, I had this idea that only content mattered and so made my own brutalist resume to send out. I got no good responses to this. I sent it out to some friends to review and they all said that the theme looked terrible and also that the content sucked. So I went back to the drawing board and rehashed it several times til I came out the other side with a more standard theme and some good content which finally started getting bites. The learning here is that you should really just get feedback as much as you can, particularly on your resume. This probably could've sped up my search by 1-2 weeks if I'd just done this at the beginning.

fin

Well that's it, the end of my search and my funemployment (which I'm kind of glad to be done with). It was an interesting process and I learned a lot but I'm excited to (hopefully) not go through it for another few years.

In the end, you can't know if you've made the absolute best decision. But that's life. What you can do coming out of the process is know that you made the best decision for you with the knowledge at hand. That's enough. It must be, because no one can do better.

In total, I spent about 153 hours in my interview process. I did some things that certainly bloated it a bit like casting a wide net and taking that vacation right in the middle, but I think it's still pretty average in the industry. For reference, I spent ~157 hours on my first job search which younger me calculated as approximately equivalent to the number of hours you'd be in lecture taking a full 12 hour course-load over a semester (at 156 hours). I think I'm smarter than younger me, but he probably got those numbers ~right.

If you've got any questions / comments, you can add them here or ping me on LinkedIn or use another way to get in touch. If you just want to see what I'm up to, you can read about it now or subscribe to get periodic email blasts containing just that. If not, that's cool too and thanks for reading!

-HAMY.OUT

GitLab CI integration with Zeit Now

Hamilton Greene — Wed, 20 Mar 2019 04:52:30 +0000

For the past month or so, I've been working on a side project called Will I get cancer? that, well, gives you info on your odds of getting cancer. When deciding what tools to use, I wanted to try out Serverless cause although I've built sites on my own servers before, it was a lot of work and I wanted to see if I could do it faster and cheaper cuse #optimization.

For this task, I chose the Zeit Now platform because it had a pretty good free tier and was in some of the NextJS docs and proved to be simple to use. I started manually deploying my project to Now and then aliasing it to my url but that soon became annoying so I decided to implement CI/CD to help automate my pipeline.

I switched over to using GitLab as my primary repo platform a few months ago and had already built out deploy pipelines leveraging GitLab CI so it was a natural choice for me to 1) build on a platform that worked and 2) that I had strong domain knowledge of.

So that's where I'm coming from and here I'll detail how to hook up your GitLab repo so that it deploys your project to Now and then aliases it to your custom domain.

GitLab CI and the Now CLI

Now before we can get into exactly how we do the integration, we need to go over a few pre-reqs about the individual tools we'll be using so we know what's going on in the final integration.

GitLab CI

GitLab CI is a process built into the GitLab ecosystem that kicks off customizable build / deploy processes.

Basically GitLab CI kicks off on commit, looks for a top-level file in the repo called .gitlab-ci.yml, and, if found, parses it to decide what it should do. This is where the CI customization comes in. If that file is found and in a proper format, GitLab will spin up a container image of your choice (from among some approved containers) and provide an interface to an in-container shell from which you can run arbitrary commands.

Through this simple functionality, you can actually get a ton of stuff done. Take for instance commands you might run from your shell locally that are now automatable via GitLab:

npm install
git build
docker run my-test-container
now // this is the one we really care about for this tutorial

You can read more about this in GitLab's official CI/CD docs.

The Now cli

what is now cli
how to use it
how to set up with your custom domain

The now cli provides an ergonomic wrapper around the now apis. For our purposes, we really only need to do two things 1) deploy our project to the now servers and 2) alias our domain to the most recent now deploy.

Running locally, we can do this with two now commands:

cd myProjectDirectory
now # this does the deploy
now alias mysupercoolsite.tld # this aliases your custom domain to the last deploy

Read more about how to set up a custom domain with now.

GitLab CI integration with Now

Now that we know a little bit about the individual tools we'll be using, we can go on to the integration.

To do so, I'm going to just plop my existing GitLab CI script from Will I get cancer? as-is and talk through what each of these things do.

# in GitLab repo .gitlab-ci.yml

# 1
image: node

# 2
stages:
  - deploy

# 3
build_and_deploy:
  stage: deploy
  script:
    - cd web # navigate to source directory
    - npm install
    - npm install -g --unsafe-perm now
    - now --token=$NOW_TOKEN
    - now alias willigetcancer.xyz --token=$NOW_TOKEN
  only:
    - master

code pulled from SIRHAMY/will-i-get-cancer, 2019.03.10

image: node

At the beginning of every GitLab CI file, we must tell it what base container image we want it to run using. It pulls from Docker Hub so if the image you want to use in your pipeline exists there, you shouldn't have a problem. Here I'm saying I want to use the official node image because I'm using npm for package management and want it all pre-installed/configured.

stages

This is likely exactly what you've intuited. Here you say the stages taht your pipeline entails and the ordering in which you'd like them run. Later on when we get down to specific steps, you'll notice that we mark which stage the given step should run in and it'll run during that.

steps

Here I've created a step called build_and_deploy and configured it inside my deploy step. What it does is navigates to the folder in which my source files are located, install all dependencies, install the now executable, run now using a token I created in now and configured as a variable in GitLab CI, then aliased my new deploy with my custom domain.

At the bottom, I configure the deploy step to only happen when the master branch was updated to keep random feature branches from leaking out to prod.

Fin

That's it! This post got a little wordy but hopefully it helps you build your own integration with Now / GitLab. Happy to answer any questions if you've got them!

If you want more content like this, I write about stuff I'm building pretty regularly on HAMY.LABS and you can get updates via email by subscribing.