J.S. — The “Wild West” of Code
The newest and most challenging module (so far) while attending Flatiron introduced us to the world Javascript. It’s an extremely powerful tool when rendering sites and for our last project we had to create something know as a Single-Page Application. What this entailed was the full functionality of a web app in which the page never reloads, but instead, rewrites the existing loaded content on the page already present in front of you.
Our instructor beforehand mentioned that JS was like the “wild west” of code and it took some time to understand but ultimately you come to realize that the way you structure your code is more in your hands than one would think. It’s almost as if when we were learning Ruby on Rails, it’s syntax just naturally called for a well-organized structure that was hard to divert from even if you tried. Although, if you really want messy code, I’m sure one could achieve that easily enough. However with JS, it’s incredibly easy to lose an organized structure when building an application and is almost a necessity to think “Am I putting this code in the right place?” every step of the way. While object-orientation does exist, it introduces a whole new challenge of maintaining scope while using it. Therefore, it seems easier to write out just one large function when writing code in JS, because everything you’d like to be able to call on is still within scope, however, it’s definitely not passing on code that’s easy to understand for the next person to make edits to.
The biggest challenge to over come when building this app was being able to communicate with the backend properly. In short, the frontend is just simple representations of what’s stored in the database in the backend but getting the frontend to communicate changes almost feels like a never-ending battle. This is where fetch comes into play. Fetch is ultimately the modernized way of sending web requests but handling it’s responses was the main challenge for me. First fetch makes a request, then you handle that request by using the ‘.then()’ after in which you determine what happens after that request was made. It may seem simple enough the way I summarize it’s use but what makes it tend to be complicated is where you’d like to debug in that process. For my project, the fetch requests are being made to a backend rails API meanwhile you’d debug from the browser using ‘console.log’ so after tons of trial and error, it takes some time to figure out exactly where you want to stop your application for the sake of simply knowing what’s going on during each step of execution. You eventually come to see that it’s best to do both forms of debugging, as in ‘console.log’-ing right before the request is made to see where your scope is and what data you have access to and are able to send with fetch, as well as setting up a ‘byebug’ or ‘pry’ in your backend at the location where that request is being made. This way you know what your sending as well as whether or not it’s being received properly.
In the end, JavaScript really is a powerful tool when it comes to controlling the flow of data on the frontend of a web application. It almost completely redefines how users can interact with databases given the objective at hand. However, it’s a tool that given all of it’s ability, can also introduce a lot of chaos if not implemented with abstraction and organization. It makes sense that most students find this module to be the most challenging. It’s freedom is what makes it the “Wild West” of coding but with proper use, the options of what we can create become endless.
