So You’ve Learned HTML, CSS, and JavaScript; Now What? (Part 2)
This is part 2 in a long series on first-steps for bootcamp grads or solo learners who have invested time into learning HTML, CSS, and JavaScript as a path towards becoming a web developer, but find themselves mired in the alphabet soup of frameworks, deployment tools, performance metrics, data structures, component libraries, and more.
EDIT: The content of this series will be updated and fleshed out over time, so I’d encourage you to check back to a given piece which did not dive deeply enough into its topic on your first read.
This is for those intrepid individuals seeking to break into a competitive job market with newfound coding skills, but have been unable to approach the inaccessible professional dialogue focusing ever on the shiny pre-requisite-heavy tool of the day or the newest and most irritating means of acronymical truncation of the English language.
So you’ve learned HTML, CSS, and JavaScript; now what?
Experiment With Asynchronous JavaScript
Learn To Consume APIs; So. Many. APIs.
In interacting with hundreds of front-end-developers-to-be throughout my career, one of the most consistent shortcomings or knowledge gaps I’ve seen is an understanding of APIs and their place in a tech stack (Not sure what an API is? Look it up. Now. I’ll wait.).
Nowadays, APIs occupy a critical place in application architecture. Monolithic app structures are being replaced by microservice-based app structures and API gateways. Amazon actually saw this coming so far in advance to the point where all of Amazon’s extremely segmented services and interfaces were built specifically to be consumed as APIs from the very start. Without getting too into why this was a genius move, it positioned Amazon as a tech-agnostic, extraordinarily scalable service; all from treating their own internal teams and digital products as so many microservices.
Practically speaking, APIs allow a developer to create sophisticated applications without having to reinvent the wheel. They give developers access to third-party data and services without which applications as we know them wouldn’t exist. They control data exposure, enable self-service endpoints, and facilitate a standard which has cultivated rich developer ecosystems.
In short, APIs are here to stay. They’re a part of your life now, so get used to using them. Most bootcamp grads have had some experience with consuming freely available APIs utilizing jQuery’s AJAX method. This is all well and good, but jQuery is a bit passé nowadays, and anyway you would do yourself a disservice in general to rely on a library-provided method which you couldn’t reasonably replicate on your own with vanilla JavaScript.
So learn XMLHttpRequest. Make native JS API calls. Make a lot of them. Try all kinds of HTTP methods utilizing XMLHttpRequest. W3Schools and MDN Web Docs are always a great place to start if you’re feeling overwhelmed here.
That said, try to dig beneath the surface of what’s happening. Now that you have the syntax and the practice to execute XMLHttpRequests to make API calls, take some time to understand what it is you’re doing; namely, making asynchronous calls to third-party endpoints in order to receive external data. That asynchronicity is a big, big, big deal. If we couldn’t make asynchronous API calls like this, the usability we’ve come to expect from our applications nowadays would be a shadow of what they are. Asynchronous functions like this, which today are more often referred to in the context of APIs as promises, allow for our apps to execute multiple operations simultaneously.
By contrast, synchronous operations wait for the conclusion of each function in the call stack before moving to the next; whereas asynchronous functions don’t preclude our user-facing application from executing a different task, and possibly presenting some meaningful feedback to a user, while waiting on some external data payload.
Which brings me to my next point.
Practice Promises
Asynchronous operations, hereafter to be called promises, can be extremely intimidating for a new bootcamp grad, but they are absolutely essential if you intend to advertise your confidence as a JavaScript developer. As I mentioned, promises make contemporary usability possible. Period.
For a more technical perspective, they allow us to execute multi-threaded code using a single-threaded language and execution context.
Fortunately, great strides have been made recently in cleaning up promise syntax. Asynchronous functions used to be at the mercy of callback functions, which could quickly send your code spiraling into callback hell. With ES6, promise syntax using the .then() and .catch() methods helped up the readability and cleanliness of async code. ES7 even brought us async/await functions and try/catch blocks, allowing for complex promises to be written with comfortably familiar function syntax.
These are your touchstones for developing your async code expertise.
For those of you thinking “Why couldn’t we just stick with .ajax()?”, I have one more surprise for you. Fetch. Fetch is an excellent merging of promise syntax with a cleaner, more readable, more approachable interface by which to execute XMLHttpRequests and make API calls. It supports a powerful range of features and functionality and error handling, and makes for a much more pleasant experience in consuming APIs and asynchronously fetching data.
Now go forth and learn.
Evan is an illustrator, developer, designer, and animator who tells stories in any which way he can. When he’s not branding businesses or building front-end apps; he’s illustrating children’s books, painting for tabletop games, animating commercials, or developing passion projects of his own.
