What We Talk About When We Talk About the Real-Time Web

I first heard the term “WebSockets” long before I had any clue what they (Websockets) were. Was it possible to have a singular WebSocket? I’d heard they were a “game-changer,” something to do with the “real-time” web. But it was hard to understand where they fit. Was it a library, or an API, or a protocol? Or was it a “transport?” As it turns out, it’s a little bit of all of these but none of them in particular.

WebSockets have quickly become an integral part of the “Internet of Things.” Most of us have come to take the “real-time” web (e.g., push notifications, chat, etc.) for granted, but it took a lot of doing to get from static HTML pages to the dynamic web apps we now expect. And while WebSockets wasn’t the beginning of that movement, they were a huge step forward. Like indoor plumbing and the right to vote, to understand what makes them so great, we need to understand what came before. …


When I taught English, I was concerned, in general, with the place and function of technology in first-year composition classrooms. More specifically, I was looking for the ways in which feedback is received online, and how computer interfaces affect student uptake and perceptions of feedback. However, this line of inquiry led me to some interesting sources on automated writing evaluations (AWEs), computer programs that aim to provide varying levels of feedback and/or holistic scoring of student work.

As an FYC instructor, the promise of less time spent on mechanics, leaving more time for higher-level concerns, was alluring. I narrowed the scope of my research to focus on the potential role of AWEs, with a mind toward supplementing my feedback to students. However, research in this field leaves questions that demand further attention. Further research and refinement of these relatively new technologies may eventually help instructors to provide deeper, more thorough feedback on student work. …


Since I wrote about garbage collection last week, I’ve been thinking about the subtleties of memory. I, like many, non-traditional programmers, have learned about computer science from the top down (maybe middle to top to bottom if we include learning the fundamentals of OOP). I made my first rails project before I even heard the terms “multi-threading” or “call stack,” let alone understood them. As a result, I learned how to build things without having to learn why they are built that way.

I wanted to change that.

And, wouldn’t you know it, I immediately came across a distinction in two very common data structures that I found really striking. The data structures: arrays and linked lists. Learning the differences in the way they are handled by the computer can be a simple and yet profound way to start thinking about performance, complexity, and memory consumption. …


Silhouette of a man with a galaxy at its center on a backdrop of stars…
Silhouette of a man with a galaxy at its center on a backdrop of stars…

Once upon a time, in the age of C, low-level programming languages, languages that hewed closer to the hardware, required something of developers that virtually no modern high-level language demands: memory management. We had to tell the computer ahead of time how much memory we would need, and it was up to us to make sure we didn’t exceed that allocation. We also had to tell the computer what to do with objects we weren’t using anymore. It was a dirty job, but someone had to do it. Luckily, newer languages have us covered. …


Image for post
Image for post
Examples of neumorphism from JustInMind

2020 was a good year… wait, wait, hear me out. 2020 was a good year for UI design. While the planet was burning, and society was consumed by a pandemic, the internet got sleek. From the deep box-shadow retro look, to scroll-based animations, to gradient text color and the return of glassmorphism, it’s hard to find a 2020 design trend that doesn’t stick the landing.

One of my favorite trends, though, is Neumorphism. It’s subtle. It’s sleek. It’s unfortunately not very accessible, but I digress! …


One of the Web’s most central and lofty ideals is that of universal access. Advances in technology have created unprecedented access to information, entertainment, and community. However, that unprecedented access is still far from universal, and it can be easy for an able-bodied user or developer to neglect the experience of users with different constraints.

When I first got started writing my own code, I was thrilled just to get a form working. I hope I’m not the only person guilty of falling for the thought-trap that “if it works for me, it works.” …


Practical Starting Points for Your First Jamstack Project

Image for post
Image for post

At the 2016 SmashingConf in San Francisco, Matt Biilmann of Netlify offered his vision for the future of web development. More accurately, he described and formalized a process that was already underway. In this emergent present, web developers capitalized on tools offered by 3rd party APIs, CMS, and CDNs to abstract away a lot of hard (and frankly boring) work that would once have been done by backend engineers to maximize security, reliability, and performance. Biilmann dubbed this method of development the “JAMstack,” dependent as it was on Javascript, 3rd party APIs, and pre-rendered HTML or Markdown Markup.

One major advantage of the Jamstack is its easy integration with CDNs to quickly deploy highly-performant static or pseudo-static pages, making it a solid choice for sites with a lot of relatively unchanging content like magazines and blogs. Similarly, the use of headless CMS as a backend makes it easy for said journalists and bloggers to upload their work using an intuitive web interface (no web dev skills required). It’s my personal opinion (an opinion which, coming from a very green developer, should be taken with a considerable amount of salt) that the name Jamstack name undersells the role of CMS and CDNs, but I suppose JACMSCDNMstack is a mouthful (I like to read it “Jack McDenim Stack”). …


Why Tech Should Value the Liberal Arts Experience || Part Three

Craft and Process

I know some very great writers, writers you love who write beautifully and have made a great deal of money, and not one of them sits down routinely feeling wildly enthusiastic and confident. Not one of them writes elegant first drafts. All right, one of them does, but we do not like her very much.

— Ann Lamott, Bird by Bird

In popular media, software engineers (there are like three software engineers in popular media, the rest are “hackers,” but you get it) and writers, the prodigious ones at least, are frequently portrayed hunched over their keyboards, fingers flying furiously across the keys. …


Basic Strategies and Principles for a Less Stressful Debugging Experience

“If debugging is the process of removing software bugs, programming must be the process of putting them in.” — Edsger Dijkstra

Bugs. They’re inevitable. In the same way that most writing is revision, most programming demands debugging. That means developers get lots of opportunities to confront our own understanding. It’s great. Okay, it doesn’t always feel great. If I can appropriate another writing truism from Dorothy Parker, I hate debugging — I love having debugged. And while I have occasionally tried arguing or even bargaining with my laptop, I’ve never found it a particularly effective method. Luckily, we have lots of tools and strategies that are much more effective. …


Why Tech Should Value the Liberal Arts Experience || Part Two

Purpose, Audience, and Context

In the introduction to this blog series, I mused on who my audience might be. This was mostly, like the rest of the introduction, a way of venting about the frustrations of changing careers and consequently seeing the not-insignificant number in front of “years of experience” vanish like a mirage from my resume and applications. It felt good. It might have even resonated with some English majors who like to code. But it was probably not particularly effective communication.

In rhetoric and composition, everything hinges on purpose, audience, and context. Before you decide what to say, you need to know why you’re talking, who you’re talking to, and where you’re talking. No duh, right? This should make pretty good sense to the average person. You don’t flirt at a funeral; you don’t bring pork to Passover. …

About

Dave Frame

Full Stack Web Developer//MFA in Creative Nonfiction

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store