<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>Forem: Caden Sumner</title>
    <description>The latest articles on Forem by Caden Sumner (@ghosts).</description>
    <link>https://forem.com/ghosts</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F58631%2F83c3547c-bc98-49fa-8e78-36d0729e5547.jpeg</url>
      <title>Forem: Caden Sumner</title>
      <link>https://forem.com/ghosts</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://forem.com/feed/ghosts"/>
    <language>en</language>
    <item>
      <title>Imbue-js: Making vanilla JS more attractive</title>
      <dc:creator>Caden Sumner</dc:creator>
      <pubDate>Thu, 07 Nov 2019 18:27:14 +0000</pubDate>
      <link>https://forem.com/ghosts/imbue-js-making-vanilla-js-more-attractive-56a1</link>
      <guid>https://forem.com/ghosts/imbue-js-making-vanilla-js-more-attractive-56a1</guid>
      <description>&lt;h1&gt;
  
  
  What's wrong with JavaScript?
&lt;/h1&gt;

&lt;p&gt;I'd like to think I'm not alone in my feeling that the front-end ecosystem is chaotic. When I learned table-layout HTML pages in high school, JavaScript was barely mentioned, but when it was we used basic event handlers in HTML such as &lt;code&gt;onClick&lt;/code&gt; for buttons. As I continued to pursue web development as an interest in college &amp;amp; eventually a career, I learned more JavaScript to handle DOM events and manipulations. Here I was introduced to &lt;code&gt;querySelectorAll&lt;/code&gt; and &lt;code&gt;addEventListener&lt;/code&gt;  which gives developers much more control over the DOM, without having to use HTML to add functionality. &lt;/p&gt;

&lt;p&gt;At some point, developers decided that JavaScript can be used in lieu of any HTML to create dynamic and robust applications, subbing in JSX, JavaScript powered elements, and similar component based frameworks. There's nothing &lt;em&gt;wrong&lt;/em&gt; with this, but it was surely a strange step away from my initial table-focused knowledge I started from. I've cycled through React and Vue and consistently found that they address a lot of use cases, and in many are the right tool for the job, but even so I felt a sense that they add complication to front-end development. I believe that the root of that is the removal of HTML and relying instead of reusable components in JavaScript to manipulate and populate the DOM. &lt;/p&gt;

&lt;p&gt;Eventually I found &lt;a href="https://svelte.dev/"&gt;Svelte&lt;/a&gt; and &lt;em&gt;immediately&lt;/em&gt; fell in love. Unfortunately I haven't found the case to use Svelte in a production app, but I have had the opportunity to use it in side-projects and making toy examples of things. The reason I love Svelte so much is that it brings HTML back to the forefront and instead of replacing or fighting vanilla JavaScript, it enhances it in extraordinary ways and augments front-end development with useful additions. The Vue-like component syntax is also extremely easy to pick up, as it follows similar semantics and separations as standard HTML (although I'm not a fan of the .svelte extension). It's important to note that since Svelte is compiled, it's &lt;strong&gt;not&lt;/strong&gt; technically JavaScript, &lt;a href="https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934"&gt;as discussed in this blog post&lt;/a&gt;. But the speed improvements, and ease of use is a huge benefit that I see propelling Svelte usage forward.&lt;/p&gt;

&lt;h1&gt;
  
  
  So what is Imbue?
&lt;/h1&gt;

&lt;p&gt;This post isn't intended as a rant against Javascript &lt;em&gt;nor&lt;/em&gt; a promotion of the library I'm trying to build (Imbue). It's more of a reflection of my thoughts on the front-end development experience, and my desire for something to address what I see as issues. &lt;/p&gt;

&lt;p&gt;I've worked with jQuery for several years, and for most of my projects, jQuery is the first thing I plopped in to the &lt;code&gt;lib&lt;/code&gt; directory, or installed in Bower, or NPM, or linked with a CDN. It honestly got to the point where jQuery was a required drop-in for a project, and from the look of a lot of recent articles, I was not alone in this experience. Over time jQuery's popularity surged and at some point I, like many others, began to see it as an unnecessary, slow, bulky, and strange requirement. Sites like &lt;a href="http://youmightnotneedjquery.com/"&gt;You might not need jQuery&lt;/a&gt; popped up to help people take a step back and remove the dependency from their systems. In a production application I'm working on, I also took a step back and made the decision to slowly rip jQuery away from our app.&lt;/p&gt;

&lt;p&gt;I began by replacing &lt;code&gt;$()&lt;/code&gt; with &lt;code&gt;document.getElementById&lt;/code&gt; and &lt;code&gt;document.querySelectorAll&lt;/code&gt;, the replacement wasn't hard and I did anecdotally feel like everything ran faster after the replacement, &lt;strong&gt;but&lt;/strong&gt; I immediately hated looking at the source code of our pages. I made the discovery that the main reason I used jQuery was because the vanilla JS methods for the DOM are poorly named, sometimes confusing, and lacking in features. Additionally, the developers I worked with were just as ingrained in the jQuery mindset as I was, and we all had to dust off JavaScript books and take a look at the DOM related methods again. &lt;/p&gt;

&lt;p&gt;So this is where Imbue comes in. Imbue is a small (~5kb currently) library (not framework), that provides semantic and simple prototype extensions to vanilla JavaScript, to speed up development and make source code easier to understand. The lengthy "document ready" code that jQuery made &lt;code&gt;$(document).ready()&lt;/code&gt; is supplied in Imbue as &lt;code&gt;document.whenReady()&lt;/code&gt;, the selector methods in jQuery are replaced by &lt;code&gt;document.getElement()&lt;/code&gt; and &lt;code&gt;document.getElements()&lt;/code&gt;, which simply use &lt;code&gt;querySelector&lt;/code&gt; calls underneath. HTMLElements are extended to have &lt;code&gt;whenVisible()&lt;/code&gt;, &lt;code&gt;onClick()&lt;/code&gt;, &lt;code&gt;getData()&lt;/code&gt;, &lt;code&gt;setData()&lt;/code&gt;, &lt;code&gt;toggleClass()&lt;/code&gt;, and many more. &lt;/p&gt;

&lt;p&gt;I'm exploring just how much functionality Imbue should provide, keeping in mind that it's not a jQuery replacement, but a substitute for projects that just need the DOM related functionality. The main reason I decided to write this post, was that I was curious to see if any other developers would find benefit in a mini-library like Imbue, and whether or not your projects could eschew jQuery for something like lighter and more focused?&lt;/p&gt;

&lt;p&gt;Would love to have a discussion on the usefulness, how to move forward, and the current state of front-end development overall.&lt;/p&gt;

&lt;h1&gt;
  
  
  Check out Imbue
&lt;/h1&gt;

&lt;p&gt;&lt;a href="http://imbue.js.org/"&gt;imbue.js.org&lt;/a&gt;&lt;/p&gt;

</description>
      <category>javascript</category>
      <category>jquery</category>
      <category>library</category>
      <category>frontend</category>
    </item>
  </channel>
</rss>
