Most shapes in ThreeJS and WebGL can be created using primitives many of which, you can use to create composite geometries, like this really neat christmas tree. Creating complex and unique geometries however takes effort and can be difficult to achieve by simply compositing, mutating and ”extruding” existing primitives in ThreeJS. A better approach, as I highlighted in a previous post, is to utilize the methods like Geometry in ThreeJS that give you the flexibility of defining vertices and faces for custom polyhedrons. In addition to this, ThreeJS also offers support for working with curves and smooth surfaces. ParametricGeometry is example of such a method that gives you the ability to work with parametric surfaces, or surfaces which extend the idea of parametrized curves (fancy terms for bézier curves) to vector-valued functions of two variables—from my understanding this basically means a 3D non straight surface. ...

Walking at angles When drawing in 3D and even in 2D, we rely on shapes to make up a larger geometry, which then go on to form a more complex scene. This may seem rather straightforward but to a machine the task of drawing shapes could not be more complicated. This is largely because most machines only know how to render triangles. Take the humble square. Ordinarily, a square is drawn from point to point around the perimeter of the square, so in the figure below we’d draw a square from 1 → 2 → 3 → 4. From a computer’s perspective however, drawing a square would go 1 → 2 → 4 → 3. ...

Because we’re starting from the basics, this week we’ll focus largely on shapes and rendering shapes to the screen. This task may seem trivial but I assure you there’s a lot happening to occupy a week’s worth of content. To keep things simple, we’ll create our 3D images using ThreeJS, a JS library that abstracts a lot of the complexities of WebGL so you can write graphics with the power of JavaScript! ...

At the start of 2018, I got the opportunity to be part of the first mini batch at the Recurse Center. Recurse Center is a self-directed, community-driven programming retreat in NYC aimed at attracting programmers who want to grow their programming chops in a rigorous yet, supportive environment. Students who attend Recurse generally come in with a dedicated project focus. This helps with setting a course and creating a clear purpose through the course of the term, which lasts anywhere between 1 week and six months. During my time at Recurse, which lasted one week (hence mini), I focused on ramping up on WebGL. While 1 week was far too short to get anywhere near mastery, it did give me the space and time to navigate the vastness of core WebGL concepts and chart a semblance of a path to eventual mastery. If you’re curious about this and my learnings from my rather short stint there, check out my musings over on Github as well as my experiments with WebGL/GLSL—the furthest I got was rotating a triangle. ...

A key step in the data visualization process is the conversion of data to the right format. When working with geospatial related information in particular, data needs to be in geoJSON to be accurately superimposed onto a map. In many instances, geospatial data available via Open Data Portals like data.gov is already in a proper format to be mapped. However, there are times when the available data needs to be cleaned and/or transformed into a more appropriate format to be useable. For example, physical address data needs to be converted to coordinates so they can be properly added to a map. In cases like these, data formatters specifically known as geocoders come in handy. ...

Redirect Rulez Browsers rely on URLs to access content on the web. One way to think about URLs is as a giant phone book for the web. When a browser wants access to a specific resource, it looks it up in the “phone book” and makes a request for it by visiting the address specified. However, like physical addresses, virtual addresses are not permanent and are subject to change. When a person moves irl, they often file a change of address at the local post office so that mail gets routed appropriately. Changing addresses on the web can be similarly achieved using redirect rules. ...

Some of the most cutting edge and effective web performance optimizations, like prefetch and preconnect, involve being proactive. We make predictions to determine where a user is likely to go next and load resources ahead of time so page load is as fast as possible. While there is somewhat of a science to making these predictions, thanks to analytics tracking and extensive user testing, they are still largely manual. Making an accurate prediction therefore becomes progressively more difficult as your site scales since there’s no sure way of knowing where a user will go next. This is where machine learning comes in handy. By training a machine learning model (maybe a markov chain?) with current analytics data, we can take the guess work our of our predictions and more accurately load resources ahead of time. There’s currently ongoing development to make techniques such as this more accessible to web developers. A project worth checking out is called GuessJS, which serves as a landing page for all libraries and tools that enable Machine Learning driven user-experiences on the web. The convergence of machine learning and web performance is still in its infancy. However, with the growing popularity of machine learning (especially among web developers), it’s only a matter of time when techniques like predictive prefetching will become more commonplace on the web.

If you’ve spent some time in frontend land, chances are you’ve heard someone say “it’s just javascript” when referencing a framework, library or snazzy new tool. While the phrase has an element of truth in it—a framework like React compiles down to JavaScript for instance—it often betrays the full picture. For one, a frontend framework like React or Ember often involves complex-ish tooling, templating systems, and high level architectural decisions around state management, and routing. Saying something is “just JavaScript” creates a culture of shaming and heightens the (already fairly high) barrier to entry for newer developers. It also paradoxically “cheapens” the work of practising JavaScript developers by making it seem like their work is trivial. Quite like the oft-misquoted phrase “A jack of all trades is a master of none”*, let’s stop popularizing the half truth that things are “Just JavaScript”. Instead, let’s do the frontend world some justice and express our work with a more nuanced approach that takes into account the chaotic albeit robust ecosystem that we’ve worked so hard to build. Maybe this way we can start having more meaningful, and productive conversations without delving into yet another pithy argument over who or what framework/tool/library is better. ...

Componentization is the central concept driving frontend development today. It enables us to encapsulate core logic of a user interface into smaller chunks thereby making them easier to reason about. While each of these components exist in isolation, they work in concert to build a unified interface. This relative isolation also means that components are reusable and can be easily mixed and matched to create a variety of patterns and styles. An example that best illustrates this is the screwdriver. Though there are many types of screwdrivers, like the phillips head, the flat head, the allen head and so on, these variations can be made by simply changing the head of the screw instead of having to buy multiple single use screwdrivers. By enabling a high level of isolation, components thereby promote ownership while also maintaining the right conditions to efficiently scale. ...

With 2018 drawing to a close, I’d like to take a moment to review some of my personal highlights from the past year. Attended Recurse Center 2018 was by far the first time that I hit the ground running at the start of the year. I successfully matriculated(?) at the Recurse Center in their first ever mini retreat and spent a full week in January learning and building alongside a bunch of incredibly smart, talented recursers. My project for the week was to ramp up on WebGL and gain (pseudo) proficiency in working with shaders. While I managed to somewhat accomplish this, I also spent a good chunk of time pairing on other recurser projects that ranged from building compilers to writing functional code in haskell. The week was wonderful, albeit a tad exhausting and I hope to return again sometime soon. ...