When I took the Web Development course during the OSU post-bacc Computer Science program I learned Node.js with Express and the rendering template Handlebars. Promises were briefly touched on and async/await was not even mentioned in the course. Since that time, I’ve heard that the course has undergone a redesign which teaches students React. I imagine async/await is touched on as well, which brings the course up to speed with “modern” practices of web development.
My capstone project is a single-page web app that we’re developing with Node.js and Express, familiar territory, however I wanted to improve my knowledge of web development and embrace a few more modern constructs, both to be up
to speed with current development practices and to make my life easier while programming.
how do I make web development more enjoyable?
I was initially drawn to TypeScript and React to ease some of my least favorite parts about “old-school” web development, which are: lack of type clarity and confusing rendering engines. After some research and discussion with the team I found that both TypeScript and React would be completely new technologies for all of us, and to be able to deliver a high-quality project we wanted to stick with a stack we already knew.
This felt like a bummer to me, because I didn’t want to return to the “dark ages” of web development without improving as a programmer. Over the last few weeks, a middle ground started to appear that would solve a few of my requirements.
What I wanted:
- TypeScript for more stable linting, formatting, and type checking
- React for easier conditional rendering and writability
- async/await for more readable/maintainable code
But I didn’t want to overwhelm myself and my team by learning all of these languages/frameworks/tools in just one
term.
What I substituted:
- ESLint and Prettier in place of TypeScript
- To lint and format our code during development and whenever we push to main via CI from GitHub Actions
- EJS in place of React
- A stable, community-embraced templating engine to replace Handlebars
- async/await to refactor Promises into more readable/maintainable code
a middle ground appears!
These substitutions aren’t perfect, but they greatly improve the development experience I had back in the Web Development class: which involved far too much debugging, lack of type clarity, confusing callback-hell, and a severe lack of documentation for Handlebars. As a result I went from actively avoiding development with JavaScript to embracing it, and almost enjoying it. There are so many quality of life improvements to be had when embracing a more modern stack, one of which is that I’m writing cleaner code at a faster pace while these new technologies “hold my hand” along the way.
You may have noticed that I kept async/await in my substitutions list. After reading a couple of good blogs related to refactoring Promises into async/await I felt I gained a good knowledge of using it. I implemented it into my code and have fallen in love with how much more Pythonic and readable it is when interacting with calls to the Spotify API. As long as I keep in mind that async/await is “blocking” and make sure to capture errors in try/catch blocks, I am good to go and can finally replace the confusing syntax of most Promises. This learning process felt like a worthwhile adaptation to embrace as it didn’t take too long to get comfortable with it, so I kept it in my current toolchain.
key takeaways
I feel like I’ve gone from developing in the dark with no guide and a host of confusing tools to feeling empowered and supported by this new toolchain. This helps me focus on making our project as close to our requirements as possible, without having to stress about the annoyances that the old toolchain would bring. I still think the TypeScript/React stack is an even stronger candidate than what I’ve settled on here, so I’m excited to learn it in the future to see how it improves my web development skills. However, in the meantime I finally feel like I’m crushing JavaScript, rather than having it crush me.