It had been years since being fully immersed in the “frontend” realm as the majority of my professional career had always leaned towards server side, backend and infrastructure roles. A lingering pain point that I had been “putting off”. But I knew if I wanted Feed Army to be in any way successful, it would need a pretty sharp UI. The hurdle of course being that my last forays into the “new” frontend developments were just not at all enjoyable. To be blunt in fact, they sucked.

Everything seemed (in my opinion) so unnecessarily complex? Babel, Bower, Grunt, Gulp, Npm, Npx, Parcel, Rollup, Webpack, Yarn….more madness anyone???

So for you, the reader, to help get a sense of my history - when I was last in the FE world, jQuery was all you needed, Twitter Bootstrap was your CSS base (is Zurb Foundation still a thing?) and either Gulp or Bower was used to concat and minify your JS files. And so, when I wrote my first lines of JS for Feed Army, it went a little something like this:

// Namespace Feed Army Javascript
var FA = {};
FA.adomain = (function () {
  // afunc logs things
  function afunc() {
    console.log("things…");
  }
  /**
   * Public methods
   */
  return {
    afunc: afunc,
  };
})();
// And then calling code
FA.adomain.afunc(); // "things…"

You can drop the above JS into any browser console and hey presto it works. Try it yourself, FA.adomain.afunc() will console.log “things…”. This is where I started. With clear, concise and easy to follow native JS that I was familiar with from writing years ago.

Now all I needed was to make some API requests to my Go backend service…seems easy enough…. it used to be just some $.ajax( calls…. but I hear there’s this other nice HTTP Client package called Axios….

I spent the better half of the rest of that afternoon trying to get the above JS to play nicely with the required Axios client. In the end, “just” to get a response back from my backend service, I ended up using var xhr = new XMLHttpRequest(); such was my frustration.

Which horse was best?

I was clearly well aware of the most “popular” frontend frameworks that were in play at the time. And I whittled the available choices down to x3. VueJS, Angular and Aurelia.

You may be surprised to see that React was not even in the running. But that is because I could/can in no way with clear conscience wantingly choose a vendor package from a company in which I so despise so much.

So down to only x3 to choose from, my clear favourite was of course VueJS.

Learning new concepts and a new framework in any language is never a simple task. Concerted effort is required to ensure patterns and concepts become second nature. If you think you can simply Copy/Paste code examples, then you’re in for a bad future experience. So as I introduced myself into Vue’s documentation, putting aside dedicated time to work through code examples and walkthroughs, I still couldn’t shake this nagging voice in my head, “Why does this all still seemed so obtuse and complex?"

It’s around this time that I started to search for an alternative.

To be fair, this isn’t anything new to me. When I start to feel that something doesn’t quite seem right, both in code and in life, I generally check to see if there isn’t a better alternative. It’s the same reason I use Gitlab over Github, or why I moved to using Bonzo and Qwery by Dustin Diaz when I felt like jQuery was getting far too large in size. Sometimes there is not a better alternative, but I at least have the reassurance that I checked to make sure.

A Revelation

To be honest, I don’t actually remember how I even found Svelte to begin with? I’d never heard of Svelte before, nor was it a colleagues recommendation. However, I certainly “do” remember how I “felt” when I started walking through the Svelte Tutorials. It was like meeting old friends! HTML, script and style, how have you been all these years!

The more tutorials I completed, the more blog posts I read, and the more core concepts I learnt, the better it all felt.

Reactive components, rendered with scoped css styles, animation built in, and app logic that runs from compiled, minified, native JS with ZERO dependencies. It seemed all too good to be true….and yet it is not!

Any Regrets?

Nope.

I have been using Svelte now happily in development and production on and off for well over a year now. Sure there are some quirks and gotcha’s that I will share as I can. But for the most part, Svelte has been an absolute delight. And interestingly enough, it was some months later that the prominent Go developer @MatRyer, someone for whom I respect not just as a person, posted this blog article pace.dev/blog/2020/02/26/tech-stack-at-pace.html revealing the tech stack in use at pace.dev.

I almost fell off my chair on reading they too had decided on Svelte since feeling the same pain points with VueJS that I had experienced. A comfort in knowing that my own technical decisions were also being mirrored half way across the globe.

If you haven’t already, put an hour of time aside and try Svelte for yourself. You don’t even need to install as you can code directly in the REPL.