DEV Community: Jonathan Higger

Programming a Cake

Jonathan Higger — Sun, 29 May 2022 04:15:12 +0000

As a beginner in the coding world, one of the hardest things to wrap your brain around is coding paradigms. When I first learned to code, I remember thinking "Oh Ruby is an OOP language so when I write ruby it's OOP" or "JS is an imperative language".

Welp, it turns out that in most languages you can code with completely different paradigms. In fact Javascript has no shortage of functional code, object oriented code, imperative code, and declarative code. That means that as a beginner, understanding what these different paradigms mean can be REALLY confusing. Hopefully this cake analogy helps a bit.

Imperative Cake

Imperative is like giving a set of instructions. To bake a cake imperatively, we have to break things down into very explicit steps.

get flour
get sugar
get whipped_cream
get cherries
get candle
get pan

mix = flour + sugar

put flour and sugar in pan

set oven to 400

wait for 5 minutes

put pan in oven

wait for 20 minutes

put on gloves

take out pan

add whipped cream to pan

add cherries to pan

add candle to pan

light candles

Procedural Cake

Procedural is a type of imperative programming, but specifically you are now allowed to use procedures. A procedure is just a way of saying "Do these steps but call it something else"
Lets make a procedure called "Bake". It will allow us to dump in a pan, and a time, but will contain some of the minor details.

procedure Bake(thing_to_bake, time, temperature){
    set oven to temperature
    wait for 5 minutes
    put thing_to_bake in oven
    wait time
    take out thing_to_bake 
}

Now we can simplify our imperative code

get flour
get sugar
get whipped_cream
get cherries
get candle
get pan

mix = flour + sugar

put flour and sugar in pan

bake(pan, 20, 400)

add whipped cream to pan

add cherries to pan

add candle to pan

light candles

We're about to talk about the opposite of imperative code, but before we do, just know: ALL CODE IS TECHNICALLY IMPERATIVE, but just like we wrote a procedure that represents imperative code, we can make abstractions that allow us to not think about the steps, but instead think about what the steps create. That brings us to...

Declarative Cake

This one might look really stupidly simple, but that's kind of the point. A declarative system abstracts away the steps needed to make something, and allows you to represent the entire system as a transformation of the data that goes into it

<Cake
   toppings: [cherries, whipped_cream, chocolate_icing]
   candle_count: 1
/>

And that's it, that's our declarative cake. One thing that confused me at first about declarative programming is how it tied in with "Functional vs OOP". A declarative system can be built with functions, objects, or even boxes in excel. Here are some other ways of representing a declarative cake.
An OOP declarative cake

new Cake({
   toppings: [cherries, whipped_cream, chocolate_icing],
   candle_count: 1
})

A Functional declarative cake

createCake({
   toppings: [cherries, whipped_cream, chocolate_icing],
   candle_count: 1
})

The reason why, as Web Developers, we tend to like declarative systems, is because it can greatly simplify the way we look at things. Under the hood, in order to make a cake you have to follow all the steps. Sometimes you don't care about how a cake is made, you just care if it's there.

For example, maybe you're the accountant for a bakery. Your job isn't to make cakes, it's only to count cakes and figure out how much the bakery has made. Your job isn't to concern yourself with how the cakes are made, you just want to make sure that the company is profitable. So instead of thinking about Cakes as all the steps to make a cake, just call it a cake and count em up!

As a web developer, declarative code is used in both the frontend and the backend.
On the backend we formulate abstractions like "Controllers", "Models", and "Views". We often don't know or care about how those things are interacting with each other, but we can change the shape of them to turn our backend into a system that processes signals in the way we want.

On the frontend, we use libraries like React, Angular, Ember, Elm, or Vue, so that way instead of writing document.querySelector for everything, our code looks more like the html that it eventually creates.

Functional Cake

So now hopefully you're starting to see the difference between imperative and declarative. Now we're going to talk about A Functional Cake. In functional programming, we make use of FUNCTIONS (Shocking). Note: Here we about to talk about functions in their intellectual purest sense, but many languages (like javascript, ruby, python for example) actually use functions more like procedures. For most languages, a function is NOT actually a function in the classical sense. WHY?
Technically, a pure function takes in data, and returns a transformed version of that data.

For example, think of algebra. Y = X + 5. We are saying here that if you plug in a 2, Y is 2 + 5 or 7. The "return" part of what I said before is basically that in PURE functinal programming, the function ALWAYS will equal some mathematical calculation of what you put in.

So in the case of our functional cake everything is just a function of our data. So here our data is our ingredients, and our toppings.

Our mixture is a direct function of what we're mixing
Our plain cake is a function of our mixture being baked
and our final cake is a function of adding the toppings to our plane cake

mixture = mix([flour, water, sugar, eggs])
plain_cake = bake(mixture)
final_cake = top(plain_cake, icing, cherries, candle)

You can simplify this all into one big function

function getBakedCake(ingredients, toppings){
   top(
      bake(ingredients),
      toppings
   )
}

Bonus Material Clean functional programming

If you think it looks weird wrapping a bunch of functions in this way you're not alone. As programmers our brains like to read from top to bottom as "Do this thing" then "do this other thing" then "do this other thing". But with functional programming it becomes a bit difficult to track the order because things have to keep nesting deeper to the right.

const prossessedByFiveFunctions = function5(
    function4(
        function3(
            function2(
                function1(
                    thing
                )
                function2SecondParam
            )
            function3SecondParam
        )
        function4SecondParam
    ),
    function5SecondParam    
)

This sure f**king sucks to read!

We could clean it up by making a bunch of intermediate variables like

const processedByFirstFunction = function1(thing, function1SecondParam)
const processedBySecondFunction = function2(
    processedByFirstFunction, function2SecondParam
)
const processedByThirdFunction = function3(
    processedByFirstFunction, function3SecondParam
)
const processedByFourthFunction = function4(
    processedByFirstFunction, function3SecondParam
)
const processedByFiveFunctions = function5(
    processedByFourthFunction,
    function5SecondParam
)

But functional programmers figured out a smart hack to clean this up. What if we made a new operator called the pipe operator, that allowed us to plug functions in backwards. Many functional languages use |>, javascript doesn't have one but if it did we could refactor our code to look like this (no stupidly named intermediate variables)

const processedByFiveFunctions = thing
    // leave () blank if you don't want to pass anything in as a 2nd param
    |> function1(function1SecondParam) 
    |> function2(function2SecondParam)
    |> function3(function3SecondParam)
    |> function4(function4SecondParam)
    |> function5(function5SecondParam)

Now that's some sexy, readable looking function code (Although it does take some getting used to). Since JS doesn't have a pipe operator currently you can try third party libraries to do something more like this.

const processedByFiveFunctions = pipe(
    thing,
    (x) => function1(x, function1SecondParam),
    (x) => function2(x, function2SecondParam),
    (x) => function3(x, function3SecondParam),
    (x) => function4(x, function4SecondParam),
    (x) => function5(x, function5SecondParam)
)

That brings us to our ultra pretty functional cake

const getBakedCake = 
   ingredients => 
   toppings =>
      ingredients
      |> bake
      |> top(toppings) 
// can be called like `getBakedCake(["flour", "water"])(["candles", "icing"])`

Some important takeaways are that:

We never modified any variables (no mutations)
The whole system turns into one value (referential transparency)
No other parts of code were affected or called on (no side effects)

Without going too far down the rabbit hole, developers like functional programming because it's restrictions can yeild less chaotic, more predictable systems. There is an evergoing war between OOP and FP programmers. I've clearly chosen my side but lets talk about a the main caviat to functional programming.

If everything was a pure function, then you could not write good applications. That means that every good app breaks the functional paradigm at some point in order to actually do something. Think about it, anytime you actually perform any action it's not fully Functional Programming any more:

Log something to a screen? Side Effect
Change the state of a counter? Side Effect, and Mutation
Alter a database entry? Side Effect
Generate a random number? No longer a pure function

But just because you can't go 100% functional all the time doesn't mean that you don't see MASSIVE benefits by trying to minimize the chaos when you can. Functional advocates think of application state as Cyclops(X-men) see's his powers. CONTAIN THAT SHIT! Having eyeballs that can shoot a massive laser beam through anything is only useful if you know exactly when you are turning it on and what you are aiming it at. We want our apps to be superheros, not blasting holes in buildings on accident.

OOP Cake

Lastly we're going to talk about my least favorite, but still important type of cake... The OOP Cake. This may actually be one of the most important types of cake for web developers, because OOP reigned supreme in the industry as the defacto way of doing things for a long time.

In OOP, or Object Oriented Programming, we tend to simplify our code not as mathematical equations, but instead as objects that not only can store procedures on how to do things, but also each mantain their own state. Lakes make a cake object really quick.

class Cake {
    initialIngredients = [];
    toppings = [];
    isDone = false;

    consructor(ingredients, toppings){
        this.initialIngredients = ingredients
    }

    async bake(){
        await this.putInOven();
        await wait();
    }

    async top(toppings){
        // do something in herek
    }
}

To be honest, this code looks kind of nice. In the Cake class, I have all my state neatly tucked into the class, and I have all my relevant methods right inside of the class itsself. Now if I want to create a cake and use it somewhere in my software I can just do.

const chocolateCake = new Cake(["brownie mix", "water"],["icing", "cherries"])
console.log(chocolateCake.isDone) // false

looks pretty sleek and sexy! But actually I made a mistake, my cake isn't done I forgot to bake it. NBD lets fix that

const chocolateCake = new Cake(["brownie mix", "water"],["icing", "cherries"])
chocolateCake.bake()
console.log(chocolateCake.isDone) // true

So it works, and isn't super ugly. In this small example, it doesn't seem super hard to look at this and say "Oh shit we just forgot to bake it."

The reason I don't like OOP very much is because, especially when you are working on someone else's 500+ line class, it becomes very difficult to reason about what state is there, why it's there, and what the sequence that things are being processed is.

Don't want to go too far down the "shitting on OOP rabbithole". Alot of REALLY GREAT software has been written in the style of OOP and a lot of REALLY SHITTY code has been written in FP and visa versa.

Summary

As a newb, or maybe even an experienced developer, it can be extremely hard to navigate through all the styles of coding out there. Truth be told, if you're like me, you won't really understand these styles until you do it for a while. For me, I didn't understand what declaritive code was until about a year into writing react code. After hearing it being explained 1000 times, and seeing examples of it, I started to make a mental picture of what it really means. The same goes for OOP, FP, and more.

The best advice I can give is to read a little and code a lot. I think spending 20% of your tech time reading / podcasts is a pretty healthy balance. Hopefully this little cake analogy can simplify this stuff in your head. In the long run understanding what these styles mean will not only help you write code, but also communicate better as a developer. I encourage you to try solving the same problem in different paradigms if you ever get the chance. I clearly have my opinions, go form your own! You can completely hate OOP cakes or FP cakes and still make a shit ton of money as a software developer.

GO MAKE SOME CAKES!

Holy S**T, I love BlitzJS

Jonathan Higger — Mon, 08 Nov 2021 04:13:36 +0000

So I've been tinkering with BlitzJS for the past couple of weeks and I have to say, it's now my favorite way of making websites HANDS DOWN.

What is Blitz?

Blitz is a framework that attempts to be a React on Rails (Ruby on Rails but with React) sort of thing, and it feels friggin amazing to program in. We'll get back to the deetz on this in a bit. But first lets give a quick history of what things were like before blitz.

A Little History on Rails

If you don't know, Ruby on Rails' claim to fame is basically that you can churn out a full-stack website super fast. Here's how they achieve that.

Really Great CLI Tooling
Amazing ORM (Active Record)
MVC Architecture allows you to create your frontend without explicit fetch calls
built in seeds / migration for database
built in integration / unit/ and e2e tests

All of this means you can start doing full stack development the second you run rails g new project-name, and you can have a full stack website built literally within a minute. You can even get relational data working from your CLI. The way they accomplish this is largely defined by their motto "Convention over Configuration", meaning that they've made a lot of the tough tech choices for you, and in doing so preconfigured all of them to work with each other. It's also probably worth noting here that Rails is like THE ruby stack that everybody chooses. It's Ruby's killer tech, and without the Rails framework, it's likely that Ruby would not be a popular language at all.

Unfortunately here's some things that kind of suck about rails.

It uses Ruby instead of JS / TS

This isn't a problem per se, but the thing is that IMO Ruby as a language suffers in a few areas.

Async Programming doesn't feel as good as it does with JavaScript.
Ruby is designed to be terse, sometimes unnecessarily so, and this can make complex code really hard to trace sometimes.
It's difficult to trace where things come from in Ruby, making it often VERY difficult to figure out how to do something that isn't well documented
It's weakly typed, and there's no well-working typescript kind of thing for ruby.
Everybody knows Javascript, not everybody knows Ruby

You're views are locked into being pretty static, pessimistically rendered. sure you can feed them with data, but most of the good stuff happens AFTER you refresh a page (Although there is new ways that Ruby is trying to Tackle this [ripping off Pheonix liveview]). If you are a beginner this basically means that the backend will primarily be driving any UI changes on the front. This simplifies logic, but can also be limiting in the types of things you can create.
It doesn't have the massive Javascript Community

Many tools won't work with ruby very well, ie: firebase, styling libraries, UI testing libraries, etc...

Sure Convention over configuration is great, but what if like I really really need to use some special package. Welp, it might be easy, or it might be really hard and difficult to debug.

Quick summary of pros and cons

Pros	Cons
Fast to make Full Stack Website	Difficult to deviate from the norm
Best practice on DB, Testing from the jump	Ruby < Javascript / Typescript IMO
Amazing Codegen tools	Scalability

On The Other Hand (Javascript)

Javascript, has felt like the opposite of rails. It's power came from it's flexibility. There are so many people with so many libraries constantly coming out that it's difficult to pick and choose which ones actually fit your needs. Furthermore, when you do pick them, now you have to make them play well with each other.

To give you an example, when I was learning to code, people called node-express a backend framework. Which is INSANE. All of express's functionality is a small subset of what rails can do. When you want to set up a full stack website with node you'll need a stack similar to the following

On the backend

Express (handles controllers and routes)
Passport (helps you with protecting routes)
Some Database Client (helps you connect to a database)
Some ORM(prisma), SQL Query Writer, or similar thing (allows you to query your database)
Some Validations Library
Need to go way out of your way to set up migrations / seeds for good database practice

On the frontend

Choose your favorite: React, Vue, NextJS, Ember, JQuery, VanillaJS etc...
Maybe: form libraries, validation libraries, typescript configuration

On both frontend and backend (this takes me for flarking ever personally 10+ hours to start and ever changing after I get the initial setup)

typescript configuration
prettier configuration
eslint configuration
testing configuration
pipeline configuration

So yeah, it's super nice because you can swap out libraries and know what the heck is going on BUT it's A LOT of work and as they say "time is $$$$$$".

In summary on what programming in Javascript has been like

Pros	Cons
Very Scalabile	Since nobody makes a choice for you, you will likely make some bad ones before you make good ones
Ton's of libraries	Configuration can take a very long time
Very Flexible, and transparent configuration	Slower to develop

Alright so How does blitz solve these problems

First let's just look at blitz's core values

Fullstack & Monolithic
API Not Required
Convention over Configuration
Loose Opinions
Easy to Start, Easy to Scale
Stability
Community over Code

I'm not going to get too into it, but lets break apart their mission a bit. The majority of these are fully inline with rails( Fullstack, api not required, convention over configuration, easy to start[although rails is harder to scale from what I understand]). One of the key divergences here is that "Loose Opinions", it basically means that the blitz team cares about you being able to switch alot of the technology.

More on loose opinions

Here is where you are locked in on Blitz. You have to use NextJS, React and.... thats about it. From there you can kind of do whatever you want, although you will have an easier time if you choose to use Prisma, and blitz's queries etc..

In other words, with Blitz they give you a happy path at default but straying from the happy path isn't like trying scale everest, it's just maybe going to be uphill and a little bumpy. In fact Blitz even has tools like "recipes" (which come from gatsby), that allow you to adopt new technologies not core to blitz, that maybe someone else has configured before.

Amazing ( albeit somewhat unfinished )CLI Tools

A little while back, I did an article about nestJS where I talked about their CLI. I really liked the idea of it, and it did save a little bit of time, but it's not nearly as good as Blitz's. The blitz CLI tools gives you some pretty amazing out of the box features, some of which wrap prisma commands. Here are some examples:

blitz g resource modelname attr1:datatype1 belongsTo:otherModel

modifies your schema to generate a new model, in this case your model will have attr1 set to datatype 1, and belong to another model. a real example of this might be blitz g resource dog name:string belongsTo:user

blitz g resource modelname attr1:datatype1 belongsTo:otherModel

does everything that generating the resource does, but also adds an index, show, edit, new page for that model. For example now out of the box you can go to /dogs/new and create a new dog which is pretty insane.

blitz console

allows you to explore your database with a CLI tool. This can be a bit buggy but is still super useful

blitz prisma migrate

wraps prisma to migrate your schema

blitz seed

runs your seeds.ts file

blitz install ___recipe_name___

this will install based off of a recipe. For example you could run blitz install tailwind and BAM you've installed tailwind.

It's some pretty amazing codegen tools that blitz has set up for you, and that's only one of the features that makes blitz feel amazing.

Automatic Codegen

So I don't fully understand the magic here, but prisma utilizes something they call the zero-api layer to generate types from your schema. Which is also pretty F**king insane.

In my backend I have a properties table, which in the schema looks like this.

Now once I migrate that file, I get types not only on my backend, but also on my frontend. At the top of my file I type `import {Property} from "db", and now I have the shape of my data on the frontend, I didn't have to make an interface anywhere. There's a single source of truth on that, which feels amazing. Now if I go to mess with a property on the front I know exactly what's there as soon as I make a change to my database.

This also means that if I make a breaking change to a type on the database, that breaking change breaks the backend and the frontend as well. Which just means you catch stupid type errors instantly which I love.

Routing

The routing comes basically straight out of NextJS but with a twist. I'm not super familiar with next, but from what I understand in nextJS, you couldn't structure your routes by folder, but in blitz you can. So for example if you have the following

`
src

pages
- properties
  - [propertyId]
    - edit.tsx
  - [propertyId].tsx
  - new.tsx
  - index.tsx `

You get the following routes automatically.
/properties/:id is your show page
/properties/:id/edit is your edit property page/properties/newis your create property page/properties/` is your properties index page

This just makes your life easier with routing

Outro

I'm not going to go full on over all of blitz here, because the blitzJS Documentation is already amazing. But here's some features that I never mentioned you get access to.

Free Authentication, User, Password, Email OUT OF THE BOX
React suspense library integration
everything you already like about NextJS
API routes and middleware
Date Serialization
Recipes, and ability to create your own custom recipes
Jest out of the box
A Cypress Recipe if you want e2e tests
The team is trying to make this React Native Friendly (which would be a dream come true)

Long story short, BlitzJS feels amazing. I think it's just one of the best developer experiences that I've ever had and I highly suggest you try it out too.

NestJS: Could be amazing someday

Jonathan Higger — Tue, 01 Jun 2021 05:20:33 +0000

Introduction

NestJS is a nice little framework for using typescript with node. It enforces opinionated design patterns that are supposed to be familiar to Java Programmers who have worked with Spring. It's built off of Node-TS and can be configured a whole shit-ton of ways. I'm personally making a postgres database using TypeORM and I'm not hating the process.

In this article we'll get into

Who nest might be good for
What I like about Nest so far
What I don't like about Nest so far
Why I may or may not stick with nest

Some Context

The name's Jon! I've been programming for about 2 years, I started with Rails for the backend, have done a few node build and burns (admittedly not a whole lot) and then found out I had the opportunity to work on and design a big project. Because I'm a Masochistic idiot, constantly searching to grow my brainpower, I decided I definitely wanted to do my backend in TypeScript and further more in an opinionated Typescript framework like NestJS. That's oversimplified, let us un-oversimplify that in the next section here.

Why I personally chose nestJS

As an instructor at a software bootcamp, I got to do a solid amount of node debugging, and am pretty good at basic Javascript. I've been playing around with Typescript in coding challenges and haven't had too much difficulty keeping up. It seemed like for myself, my career, and my confidence in life... It was finally time to grow my Type-Chops up and become the developer I was always meant to be.

Coming from a rails background, I was convinced that I would learn better practices faster diving head first into a more OPINIONATED framework. Nest seemed to fit the bill, so I said screw it, lets go!!!!!

What I like about the Framework so far

On first glance there was one thing that attracted me to the framework.... CLI tools!

In Rails, if you are familiar, you can effectively create a an entire API in about 10 minutes or less because of how well their CLI tools work! NestJS has them too! Just run nest generate resource fill out the menu options that come up in your terminal, and WHAM you get a shit ton of files made for you.

for example if you create a users resource you will get a file structure something like this

- src
  - users
     - entities
       --user.entity.ts
     - dtos
       --create-user.dto.ts
       --update-user.dto.ts
    -- user.module.ts
    -- user.service.ts
    -- user.controller.ts

This is fucking fantastic! Less room for error, less thinking, bada boom, badabing, WHAM.

As I started to get deeper into it though, I found that my appreciation actually came more from being forced to learn some new design patterns. I was forced to learn about data transfer objects, services, (I already knew about controllers), modules, and while I definitely don't fully understand all of the code, it's nice to see a good design in practice. The code that I wind up writing truly does feel MUCH more organized than if I had not used nest.

I regularly seem to encounter things like "OHHHHH thats why they did this this way, that makes sense"

Also the structure of the Nest Docs is BEAUTIFUL. The UI is great to look at, and with the content that they do cover they do a very good job of.

in summary of the things I like we have

CLI Tools
Forced to learn good design patterns
Very tidy project structure
Well made docs

But there ARE SOME PROBLEMs

OK so I wasn't 100% honest about the CLI tools. They are great, but they are also flawed deeply in my opinion. Here is the thing, maybe I'm a spoiled brat, but in Rails you can literally set up a one to many relationship in under a minute by typing in

rails g scaffold classroom name:string
rails g scaffold teacher name:string classroom:references

And BAM. Right out of the box you get

Postgres connection
Beautifully organized migration files
Controllers
Models
its all done for you, you barely even have to know how to code

you can immediately spin up your server and start seeding classrooms and teachers and are good to go.

but when you type in

nest g resource classroom

here's what you get

A controller
A Service which is what your controller connects to that actually manages database connections
some types that aren't filled in that allow you to move data around
A Module that organizes it

here's what is missing though and its a BIG FUCKING THING

TypeORM integration (Or some other library like sequeliz)

So now what you wind up with is 5-8 different files that you have to go in and do a TON of manual configuration. To give you an idea of what the steps are like. They are something like this.

install typeorm
install types for typeorm
connect typeorm to your classroom entity by specifying it as a typeorm entity
create a classroom repository in the constructor arguments for the classroom service
use the classroom repository to update your classroom services methods
update your imports for your classroom module to include typeorm
update the classroom entity to include all of the data fields that you need
update the create-classroom dto to include all of the data fields that you need to create a classroom
update the update-classwroom dto to include all of the data fields that you need to update a classroom.

THENNNNNNNN you're good to go and start testing!!!

Ok that was a lot, and I don't know what other people's development experiences are like, but to me it seems like the beauty of an opinionated framework is the ability to NOT have to do all that. On top of this here are some other things you no longer get out of the box.

Migrations
The Ability to seed things
Validations ( they are easy to generate in rails I think but I'm not sure)

Also another quick complaint. While the docs are fucking beautiful, and the tone is great for beginners, they need to be more thorough. I had to go down ton's of stack overflow rabbit holes just to find information on for example "What do I actually put in my post request for a many to many relationship".

Now that you know the backstory, here are some more fleshed out opinions

It feels like all of NestJS's problems can be boiled down to this, and I totally could be wrong. NEST NEEDS STRONGER OPINIONS! From everything I read, the Node ecosystem is severely lacking a dominate "batteries-included" framework, and from what I can tell NestJS has the real potential to be the number one contender. But they CANNOT do that if the learning process, or the developing process is this tedious.

Here's some things Nest needs to do before I'd wan't to refer everybody to it (Not that I would reccomend against it now)

Focus on TypeORM support

The cli generators need to connect your entities to the database for you
migrations and transactions from typeorm should be built right into nestJS, and documented directly on the nestJS website on how to use (So far I find NestJS docs 10,000 times better than typeorm's or most other libraries in how they are written).
(Bonus) it would be great if you could specify datafeilds in the cli generators

More generally, build opinions into the app

When I do nest new project_name, I shouldn't have to go down the rabbit-hole and read all the docs to get everything hooked up with passportjs, class-validator, class-transformer. Make some opinions on what people will use all the time for a standard REST API, and build them into the app template, the cli-tools etc...

Get them docs to be a bit more thorough

Include more post requests
Show more workflow on the passport strategy
more tutorial sections, potentially some video walkthroughs

Summary

I genuinely think Nest is great. They do a great job with their docs, and if everything discussed above was actually improved there is no doubt I would enjoy Nest more than rails personally. Maybe I'll do a follow up article in 5 years haha!

From VSCode to Vim... and Back?

Jonathan Higger — Fri, 12 Feb 2021 05:16:48 +0000

How a plummet into the vim rabbit hole resulted in a massive productivity increase

Part 1 Why Vim???

My Background
I am a full stack developer with a background in chemical engineering and being a lifelong musician. While in college I learned nothing valuable about workflow or productivity. Then when I became a student at flatiron, I got to witness experienced engineers with well-developed workflows. I realized quickly that I needed to become quicker, but unlike a lot of my instructors and friends, I became a little bit obsessed with workflows. I think the inner musician in me loves playing with keyboard shortcuts and constantly learning new things about features. I even built an app to increase my typing speeds as my capstone project.

Check it out at doomtyper, a doom themed typing test that I put together using VueJS and Rails.

Sparking my Interest
I started getting interested in vim when my lead instructor at flatiron school would program in vim right in front of us newbs. Every day he would show off his speed in an editor that literally ran out of a terminal. The more I learned about vim the more fascinating it became, here are the things I found really interesting about it.

That being said, I knew that learning vim would be tough, and on top of that, I had a whole lot of important things to learn first in order to make myself a more valuable developer. So for the time being I wanted to focus less on my code editor and more on my code. In hindsight that was a pretty great decision. There was one small caveat to that though...

Pretty early on into my Bootcamp, I got a mechanical keyboard called an Anne pro 2, that was programmable. As a 60% keyboard with no arrows, I decided that I would use "HJKL" (The vim directional keys ⬅️ 🔼 ⬇️ ➡️ ) instead of the standard WASD choice. Fairly soon using this game, I was extremely comfortable using vim arrows, and I would be happy with that level of vim-ery for about 5 months more. Already from that alone, I believe I saved a ton of effort. I didn't realize how much of a pain in the butt it was to have to move your hand to get to arrow keys until I didn't have to do it anymore. To this day if my press caps lock on my programmable keyboard, I am in a function layer that remaps hjkl to left up down right.

When I took the Plunge
After being an instructor at the Bootcamp that I taught at for a few months I was feeling pretty comfortable with my place in life.
To be quite frank, I was on a two-week break from everything and got really bored. I bought a subscription to Vim Adventures, and at that point, the stubborn child gamer in me felt like I had to beat the freaking game. After finishing, I decided to psych myself into ditching VSCode for vim, mainly because I had worked so hard to get through that game. I validated my decision logically with the following points of note.

Vim comes from vi which is one of the oldest text editors to date. All these years later people still use it.
I had been told that vim was much faster than VSCode
You never take your hands off the keyboard
Vim is basically installed on every computer, so you can use vim anywhere that you are ssh'ed into
I wanted a stupid reason to feel superior to everybody around me

Little did I know what I had in store for me

Part 2... The Struggle Bus

Which Version of Vim do I get?
After finishing vim-adventures, I felt like I knew all the important vim TEXT EDITING commands, but still couldn't really navigate my way through a project. I figured the only way I'd ever really get good at it was to just start making projects using vim. So I had to download vim. Sounds simple right?

This is where I met my first hiccup. Turns out there is a shitload of options out there. Here are some of them to name a few.

Mac Vim
Vim
SpaceVim
NeoVim
DOOM Emacs (Emacs with vim bindings)
NeoVim nightly

On top of this, there are also a couple of vim-ey things that all good vim users I know have.

TMUX
ranger

And then when you do all that, turns out there's practically an infinite amount of ways that you can configure all of this stuff. Ultimately after doing my research I decided to use the following setup, which turned out to be a VERY time-consuming decision.

Neovim nightly ( a version of vim that is technically still in Beta)
TMUX

It took me a full late-night to be able to properly get the beta version of Neovim Nightly installed onto my Mac. But there was supposed to be (and they're definitely are) some cool features on it.

Lua Configuration Support (Which I never used)
Advanced Language Server Support ( I definitely used this )
Ranger integration with picture support ( Which I never used )
Treesitter (Which I never used)
Floaterm a floating terminal inside of vim( Pretty great, but buggy as hell)
COC integration (an all in one tool based on language servers, a technology I would later learn was invented by the VSCode team)

The Struggle bus
These cool features were not free, and I didn't really understand what half of them were. I honestly found out about them through forums from people talking about how they configured their nvims. Unfortunately to be able to use literally any of these features I first had to learn.

vimscript
- to learn how to configure settings properly
What the hell a language server is
- to learn how to get good code coloring
What plugins are out there to help me do the thing that I already know how to do.

Long story short, I had a steep learning curve to get through and alot of configuration to do. So every morning I woke up. VIMMMMMMM. Go to Sleep VIMMMMMM. My girlfriend would wake up in the middle of the night to me uttering the name of my one true mistress... VIMMMMM( This is a lie I'm single and lonely). I was obsessed and needed to be, in order to put up with all the bullshit associated with getting up to speed.

Every Day I would write new sticky notes with shortcuts to remember. I would spend at least 1 - 2 hours every day tinkering with my vim configuration files, and I would butcher the classes that I would teach because I was so slow at vim it was unbearable.

The pinnacle of my struggle bus was when I taught a class using vim, with the very same instructor that showed me vim in the first place watching me. I completely choked, forgot everything that I ever learned about vim, and about coding, and my brain exploded in front of 10 students and my vim mentor. BUT DID I GIVE UP????? FUCK NO!!!!

Part 3... I CAN VIM NOW

Moment of Clarity
One day I'm teaching a class, and a student tells me to slow down. Wait for what? I've been struggling with vim for so long, I didn't think it was possible for me to actually go fast at this. While simultaneous being a sign of terrible teaching habits, I'd realized that my obsession with vim had finally started to pay off. I was now unintentionally going too fast for other people... Holy CRAP VIM IS AWESOME.

VIM COMPETENCE FEELS AMAZING
Now that I'm confident in my abilities, I'm flipping between files. I'm learning new shortcuts every day without stretching my brain too hard. I'm getting faster every time I use my computer. I can now talk shit about anybody that still uses nano. Life IS GOOD!!!
Here are some things that I can do way faster than ever before:

flip between files
edit text
run commands on a floating terminal
open every part of my code editor with my keyboard
Move cursors around seamlessly
configure my text editor for customization
organize configuration files

Life Is Still NOT Perfect
As fast as I am at vim. Some things still kind of suck. For example, now that I'm used to vim bindings, it becomes annoying to work in a word document. I keep hitting escape, and the truth is I mainly edit markdown files anyways. So why not just do that in vim?

Turns out that in vim, there are all sorts of weird things that begin to happen with word wrap when you start editing. For me, I had to go on an hour-long information binge to figure out the best way to handle these things. On that rabbit hole I find a few ways to fix my problem:

I could change word wrap settings in my vimrc
I could download a cool plugin called Goyo that lets me edit documents easier
I could download another cool plugin called vim-pencil that gives me special text editing features when I edit documents

Ok not too bad, I just have to install a couple of plugins, and we're good to g...
Oh shit, each of these plugins has a list of commands I have to either remember or configure... Fuck
Let's tack a few more sticky notes to my monitor and we should be good to go..... Fuck
Turns out that Goyo's recommended settings interfere with some other settings in my vimrc.
OK finally got it figured out but now that's an hour of my day gone.

I think this is more because I was in the nightly(beta) version, but I also kept experiencing terminal crashes, and in general I didn't enjoy the experience flipping between terminals on TMUX or Floaterm half as much as I enjoyed the VScode terminal. Simple, elegant, a bit slower, but reliable, and I need that extra time to think sometimes anyways.

Part 4... VSCode With VIMBINDINGS??????

If you love vim, please stop reading here. I already know I will be scolded completely and utterly for this segment

VSCode with VimBindings works extremely well
In VSCode all you need to do is go to the plugin manager, search for vim, click on it, and you are pretty much good to go. Almost everything awesome in vim works or can be configured to work in VScode.
Right off of the bat, you get the following features.

Standard Vim Bindings
Some basic use vim plugins
- sneak
- easymotion
- surround
gd, and gf, go to definition and file respectively with no issues

But in my opinion, unlike vim, everything that isn't just text navigation just works smoother with less configuration. If you need to download a plugin get it from the store. You can even configure leader keys to trigger VSCode commands that come with plugins. For example <leader>ss is save, <leader>\ is show error for me.

A few things that I can very easily do in VSCode that I can't do in vim are:

Drag and Drop files to my browser
Install plugins with a button click
Run jest tests with visual cues in the editor
Run a debugger without a shit ton of debugging

The Downsides

There are three main downsides to using vim VSCode that I can think of.

Not being able to open files inside of the terminal means more window management through your Os
- Usually, OS doesn't handle window management as well as IDE's do
Less configurable in general
- I think because of the nature of how vim is written, its code is meant to be played around with. It seems much easier to create your own custom things than it would be on VSCode. It is easy to customize VSCode, but not to the same level of Depth
VIMWIKI is my favorite plugin I've ever used.
- I will still use neovim every single day for this plugin alone. It is just the most convenient way for me to take notes in an organized fashion. I've tried VS Code Notes plugins and nothing will ever compare. #vimwiki4lyfe

Summary

Vim was a fucking awesome rabbit hole to go down, after coming out the other end I feel WAY faster than I did before. I also have a much better understanding of all the moving parts of IDE's that we take for granted. More coming on some of those. But if you are someone who is thinking about going down the vimhole, I say fucking go for it! Worst comes to worst, your girlfriend leaves you, or you get so obsessed with it that you neglect your child. More than likely you will get obsessed for a little while, learn a lot, and develop great habits!

Feel free to reach out to me if you have any questions about what my journey was like!