Blog

• Migrating to Eleventy

  Sometimes I feel that, as a front-end developer, I spend so much time working in my day-to-day work with some specific toolchain, that rarely have time to try different technologies, libraries or patterns.

  It's very easy to forget about plain HTML, CSS and JavaScript once you get used to all the boilerplate that tools like React, JSX or CSS-in-JS solutions bring to the project. Sometimes it feels heavy and overwhelming.

  Because I wanted to try something out of my comfort zone, two years ago I decided to implement this personal website. The only requirements I had in mind were that it had to be easy to develop and easy to scale, relying mostly on plain HTML and CSS, including JavaScript only when necessary. I thought about implementing everything by myself, but I found writing the projects and blog content directly in HTML a little bit tedious. At that time, I read a lot about SSG solutions and how (mostly) everything was done at build time, serving pure HTML.

  Between all the available options I checked, I chose Nuxt.js. I had experience with Vue and I was used to structure a project in components. I was interested on how it could work as a SSG solution.

  To be honest, since I had implemented projects with Vue before, it was rather simple to implement this website. The Nuxt.js documentation is really good so I was able to prepare a working prototype really quickly and deploying a final version to production some days later.

  However, I recently felt again like I wanted to try something new and I think this website is the perfect playground to do that. I've heard a lot about Eleventy and how easy is to start a project. And it is true! No mandatory file structure, no module dependencies... Just an index.md file and running eleventy was more than enough.

  In a couple of hours, I was able to have the main front page and the rest of sections with same CSS and navigation than the website I had deployed in production. Also thanks to Nuxt.js components having scoped CSS styles I was able to identify the required CSS for every page and move it to each Eleventy template.

  After two more days, spending four or five hours each on quick testing and reading documentation, I've been able to have the whole website migrated to Eleventy.

  From my point of view, I noted different things:

  Pros

  • Really easy to start. Just prepare a HTML or Markdown file, use the eleventy command and you're ready to go.
  • Not forced to use a specific or a single template engine. I'm currently using Nunjucks, Liquid, Markdown and WebC. All of them together!
  • Not forced to use a specific folder structure.
  • Almost no npm dependencies to start.

  Cons

  • Sometimes I find the documentation difficult to follow and I miss more examples.
  • Some minor issues that might be related to ignorance from my side. For example, when I moved the blog posts from single blog/post.md files to blog/post/index.md, I had to update the .eleventy.js file to watch blog/ folder if I wanted Hot Reloading to work. Posts are still under the blog/ folder even though I created subfolders so I don't understand why it's not working automatically. Most probably I'm doing something wrong but I couldn't find anything in the docs.

  I think I'll spend the following weeks tweaking and improving some small details that are still missing.

  I wonder if it would be easy to include something like babel during the build time in case I want to transpile the small amount of JavaScript I added. There is also a double call to connectedCallback of a WebComponent I implemented that I still don't fully understand. But, in general, the experience has been very rewarding.

  Published on 2023/01/04 under #meta

• The target of Webpack

  First of all, I wanted to say I consider webpack an amazing tool to generate the bundles for your projects. However, I get frustrated every single time I try to configure it from scratch. Usually I'm prototyping and I want to configure everything as quick as I can so I can start working on the actual code. Which is something that almost never happen.

  Yesterday, for example, I decided to start working again in a very old project I have never been able to complete. To be honest, the furthest I ever get is to configure the build process and write two or three functions. After that point, I realize about the complexity of the project, I start feeling overwhelmed and then I quit.

  This comeback to the project has happened twice and, there is always a big gap of time between each attempt. This usually leads to the scenario where, the only part I felt more satisfied of, this is the build process, was outdated. Welcome to JavaScript land.

  This time wasn't different, my last build flow (from 4 years ago) was including browserify and uglify. Don't get me wrong, I really loved browserify at the time (and I still do!) due to the simplicity to generate the builds. However, I think that if I get to the point where this project of mine grows as much as I would like to, I will need more configuration for the build process and I think I will appreciate more file structures like the webpack configuration files. So the sooner I integrate webpack the better. I don't want to think about migrating everything to webpack in the future.

  So I started, as many other times, to search for documentation about how to integrate webpack and all the babel related packages... They are so many that I always forget. Every single time.

  Fortunately, Tania Rascia wrote a very good article in her blog about how to configure webpack so I started to follow her instructions. I recommend it to you if you need a clear guide to start from scratch.

  After all the packages installation I prepared a webpack.config.js file that looks more or less like this one:

  const path = require('path')
  
  module.exports = {
    entry: {
      ['bundle']: path.resolve(__dirname, './index.js'),
    },
    output: {
      path: path.resolve(__dirname, './dist'),
      filename: '[name].js',
      libraryTarget: 'umd'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: ['babel-loader']
        }
      ]
    }
  };
  

  Looks nice, huh? Not so many lines... At this point I don't even remember why I was complaining about the complexity of webpack before.

  Now, let's say my project only has a empty function so far, just like this:

  function a() {}
  
  export default a;

  import a from './a';
  
  export default { a };

  Then I configure the npm script to generate the build:

  "scripts": {
    "build": "webpack"
  }

  Yeah! Now I run npm run build and that's it! Let's take a look to the generated bundle:

  !function(e,o){if("object"==typeof exports&&"object"==typeof module)module.exports=o();else if("function"==typeof define&&define.amd)define([],o);else{var t=o();for(var r in t)("object"==typeof exports?exports:e)[r]=t[r]}}(self,(function(){return(()=>{"use strict";var e={d:(o,t)=>{for(var r in t)e.o(t,r)&&!e.o(o,r)&&Object.defineProperty(o,r,{enumerable:!0,get:t[r]})},o:(e,o)=>Object.prototype.hasOwnProperty.call(e,o),r:e=>{"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})}},o={};e.r(o),e.d(o,{default:()=>t});const t={a:function(){}};return o})()}));

  Beautiful, isn't it? But... wait! What is that? const and () =>?

  

  Didn't I configure well the .babelrc file? Let's take a look:

  {
    "presets": ["@babel/preset-env"]
  }

  It's ok, right? Then why is babel including const and arrow functions to handle the modules? Because, it is babel, right?

  After A LOT of search, I found this StackOverflow question.

  It looks like it wasn't babel at all. Webpack has something called target that let you specify which environment you would like to compile for. It also looks that, if you don't specify any target, it will include any ES6 feature.

  Anyway, let's configure webpack to target ES5.

  const path = require('path')
  
  module.exports = {
    target: 'es5', // DON'T EVER FORGET THIS
    entry: {
      ['bundle']: path.resolve(__dirname, './index.js'),
    },
    output: {
      path: path.resolve(__dirname, './dist'),
      filename: '[name].js',
      libraryTarget: 'umd'
    },
    module: {
      rules: [
        {
          test: /\.js$/,
          exclude: /node_modules/,
          use: ['babel-loader']
        }
      ]
    }
  };

  Now the build looks like I expected from the very beginning, without any trace of const or arrow functions:

  !function(e,t){if("object"==typeof exports&&"object"==typeof module)module.exports=t();else if("function"==typeof define&&define.amd)define([],t);else{var o=t();for(var n in o)("object"==typeof exports?exports:e)[n]=o[n]}}(self,(function(){return function(){"use strict";var e={d:function(t,o){for(var n in o)e.o(o,n)&&!e.o(t,n)&&Object.defineProperty(t,n,{enumerable:!0,get:o[n]})},o:function(e,t){return Object.prototype.hasOwnProperty.call(e,t)},r:function(e){"undefined"!=typeof Symbol&&Symbol.toStringTag&&Object.defineProperty(e,Symbol.toStringTag,{value:"Module"}),Object.defineProperty(e,"__esModule",{value:!0})}},t={};e.r(t),e.d(t,{default:function(){return o}});var o={a:function(){}};return t}()}));

  I understand webpack has to provide as many configuration options as it can, which is part of its flexibility. However, I wasn't understanding why I would want to configure webpack to use a babel configuration in order to have ES5 syntax and webpack wouldn't 't use that configuration to assemble all the different parts in a homogeneous way.

  As I said, since babel-loader is an optional module for webpack, I think it makes sense to have a separate configuration to specify the target of the build from wepback. But this kind of things don't make it easier when you start from scratch.

  Published on 2021/06/19 under #development

• Hello World

  This is a test for the blog!

  Published on 2021/01/17 under #meta