Overall the experience has not been nearly as difficult as I originally thought it would be. The first simple websites I built were before I knew how the web worked and they are bad. I did not know about MDN docs or browser developer tools or many other things which slowed me down. In the back of my mind was that first experience that felt so painful. Since then all of my front-end projects have used React. Coming out the other end of building out most of the functionality that I wanted, I can say it is not near as difficult as I originally thought it would be.
module, and then importing from a relative path includes accessing the file like a normal file served from a web server with the
.js extension. Something so simple that I take for granted is much different when the runtime environment switches.
<script type="module" src="js/myFile.js"></script>
Now to kick off the higher-level difficulties.
There is no global state to fall back on. At least not a ready-built, easy-to-use global state. Obviously, it can be built because so many frameworks have implemented it, but the basic web APIs do not offer something like that. Instead, there are local storage, cookies, and a few other storage methods. I mostly stayed with cookies for this application, but I can easily see how the other storage APIs could come in handy.
Speaking of cookies, getting and setting cookies threw me off when I first started using them. Both getting and setting are done using
document.cookie. Getting was not difficult as the cookies are returned in a fairly easy-to-read format that just needs to be split up and parsed out for the correct value.
Setting cookies, however, is where I originally got confused. What I started off doing was checking if there were cookies returned in
document.cookie, and if there were existing cookies, I correctly formatted the new cookie in the same way that they would be read and then set
document.cookie to the new string. That did not work. After reading through docs, I learned that
document.cookie is an accessor property, which basically means you are not overriding the entire value and it has its own way of handling what is set. Cookies, no matter how many cookies are already set, are created or updated one at a time using notation that looks like it would override all cookies. Here is an example of what that might look like.
console.log(document.cookie); // cookie1=this document.cookie = 'cookie2=that'; console.log(document.cookie); // cookie1=this; cookie2=that
While reading through cookie documentation, I also learned that various attributes can be set on cookies. They control which pages have access to your cookies and which remote requests will be sent your cookies. Some secure defaults ensure your cookies are not sent to third parties, but this helps me understand how sites track your browsing and how targeted ads can get that information.
Speaking of remote requests, I want to discuss
fetch. One of my main motivators for this little experiment was that I wanted to keep my list of dependencies down. Normally to make requests I would install
axios because I like their API and am familiar with it. This time I decided to learn
fetch which is a basic web API just like cookies would be. It turns out
fetch is a very usable API, which seems to have been the theme for this entire experience. Sure the API is different than
axios, but I did not come across anything that
fetch could not do.