Original Source: https://www.sitepoint.com/webpack-beginner-guide/?utm_source=rss

Nowadays, we’re forced to use many accessory tools to facilitate, speed up and optimize our web development workflow. Often though, such tools add an extra layer of complexity into the stack. As a result, we need to utilize additional time and effort to learn, understand and use these tools correctly. The same is true for webpack.

When using webpack for the first time, it can be difficult to understand how it works and how it should be used. Although it has good documentation, it can be daunting for novices, and it has a steep learning curve. However, webpack is worth learning and can save considerable time and effort in the long run. In this tutorial, I’ll introduce all the core concepts to help you get started.

Note: in this tutorial I’ve used webpack 4.30.

What Is Webpack?

As its core, webpack is a static module bundler. In a particular project, webpack treats all files and assets as modules. Under the hood, it relies on a dependency graph. A dependency graph describes how modules relate to each other using the references (require and import statements) between files. In this way, webpack statically traverses all modules to build the graph, and uses it to generate a single bundle (or several bundles) — a JavaScript file containing the code from all modules combined in the correct order. “Statically” means that, when webpack builds its dependency graph, it doesn’t execute the source code but stitches modules and their dependencies together into a bundle. This can then be included in your HTML files.

Now, to expand the above cursory overview, let’s explore the main concepts webpack uses.

Webpack Main Concepts

Webpack has some main concepts which we need to understand clearly before digging in its practical implementation. Let’s examine them one by one:

Entry. The entry point is the module, which webpack uses to start building its internal dependency graph. From there, it determines which other modules and libraries that entry point depends on (directly and indirectly) and includes them in the graph until no dependency is left. By default, the entry property is set to ./src/index.js, but we can specify a different module (or even multiple modules) in the webpack configuration file.

Output. The output property instructs webpack where to emit the bundle(s) and what name to use for that file(s). The default value for this property is ./dist/main.js for the main bundle and ./dist for other generated files — such as images, for example. Of course, we can specify different values in the configuration depending on our needs.

Loaders. By default, webpack only understands JavaScript and JSON files. To process other types of files and convert them into valid modules, webpack uses loaders. Loaders transform the source code of non-JavaScript modules, allowing us to preprocess those files before they’re added to the dependency graph. For example, a loader can transform files from a CoffeeScript language to JavaScript or inline images to data URLs. With loaders we can even import CSS files directly from our JavaScript modules.

Plugins. Plugins are used for any other task that loaders can’t do. They provide us with a wide range of solutions about asset management, bundle minimization and optimization, and so on.

Mode. Typically, when we develop our application we work with two types of source code — one for the development build and one for the production build. Webpack allows us to set which one we want to be produced by changing the mode parameter to development, production or none. This allows webpack to use built-in optimizations corresponding to each environment. The default value is production. The none mode means that there won’t be used any default optimization options. To learn more about the options webpack uses in development and production mode, visit the mode configuration page.

How Webpack Works

In this section we’ll examine how webpack works. Even a simple project contains HTML, CSS and JavaScript files. Also, it can contains assets such as fonts, images, and so on. So, a typical webpack workflow would include setting up an index.html file with the appropriate CSS and JS links, and the necessary assets. Also, if you have many CSS and JS modules which depend on each other, they need to be optimized and properly combined in one unit ready for production.

To do all this, webpack relies on configuration. Although webpack 4 comes with reasonable defaults, for any non-trivial project you’ll need to provide a special configuration file webpack.config.js, which describes how the files and assets should be transformed and what kind of output should be generated. This file can quickly become quite monolithic, which makes it hard to understand how webpack does its job unless you know the main concepts behind its working.

Based on the provided configuration, webpack starts from the entry points and resolves each module it encounters while constructing the dependency graph. If a module contains dependencies, the process is performed recursively against each dependency until the traversal has completed. Then webpack bundles all project’s modules into a small number of bundles — usually, just one — to be loaded by the browser.

Getting Started

Note: you can find the files for our project in the GitHub repo.

Now that we have solid theoretical foundation, let’s implement it in practice.

To start, we’ll create a new directory and switch to it. Then we’ll initialize a new project:

mkdir learn-webpack
cd learn-webpack
npm init -y

Next, we need to install webpack and webpack CLI locally:

npm install webpack webpack-cli –save-dev

Now, the content of the generated package.json should be similar to the following:

{
“name”: “learn_webpack”,
“version”: “1.0.0”,
“description”: “”,
“main”: “index.js”,
“scripts”: {
“test”: “echo “Error: no test specified” && exit 1″
},
“keywords”: [],
“author”: “”,
“license”: “ISC”,
“devDependencies”: {
“webpack”: “^4.30.0”,
“webpack-cli”: “^3.3.0”
}
}

Besides bundling modules, webpack can be used as a simple task runner. We can create webpack tasks by including the name of our task followed by its instructions in the scripts section of the package,json file. Let’s try this now. Open package.json and change the scripts object to the following:

“scripts”: {
“test”: “echo “Error: no test specified” && exit 1″,
“dev”: “webpack –mode development”,
“build”: “webpack –mode production”
},

Within the scripts property, webpack allows us to reference locally installed npm packages by their names. We use that and the –mode flag to define dev and build tasks, which will run webpack in development (npm run dev) and production (npm run build) mode respectively.

Before we test the tasks we’ve just created, let’s create a src directory and put an index.js file in it so that it contains console.log(“Hello webpack”);. Now we can already to run the dev task to start webpack in development mode:

$ npm run dev

> learn_webpack@1.0.0 dev C:UsersUserWebpacklearn_webpack
> webpack –mode development

Hash: 5bb3bdc1efd7b7f4b627
Version: webpack 4.30.0
Time: 226ms
Built at: 2019-04-16 17:48:32
Asset Size Chunks Chunk Names
main.js 3.8 KiB main [emitted] main
Entrypoint main = main.js
[./src/index.js] 27 bytes {main} [built]

Great! It works as expected. But to verify that we get the correct output, we need to display the result in the browser. To do that, let’s create an index.html file in the dist directory:

<!doctype html>
<html>
<head>
<title>Getting Started</title>
</head>
<body>
<script src=”main.js”></script>
</body>
</html>

Now, if we open the file in the browser, we should see the Hello webpack message in the console.

So far, so good. But writing our index.html file manually can be problematic in some cases. For example, if we change the name of our entry point, the generated bundle will be renamed, but our index.html file will still reference the old name. So, we’ll need to update our HTML file manually every time we rename an entry point or add new one. Fortunately, we can easily fix that with the html-webpack-plugin. Let’s install it now:

npm install html-webpack-plugin –save-dev

At this point, to activate the plugin, we need to create a webpack.config.js file in the root directory with the following content:

const HtmlWebpackPlugin = require(“html-webpack-plugin”);

module.exports = {
plugins: [
new HtmlWebpackPlugin({
title: “Webpack Output”,
}),
],
};

As you can see, to activate a webpack plugin, we need to include it and then add it to the plugins array. If needed, we also pass options to the plugin.

Let’s run our build now to see what will happen:

$ npm run build

> learn_webpack@1.0.0 build C:UsersUserWebpacklearn_webpack
> webpack –mode production

Hash: e56a796f5ccfebcc8270
Version: webpack 4.30.0
Time: 1088ms
Built at: 2019-04-16 20:44:47
Asset Size Chunks Chunk Names
index.html 183 bytes [emitted]
main.js 956 bytes 0 [emitted] main
Entrypoint main = main.js
[0] ./src/index.js 27 bytes {0} [built]
Child html-webpack-plugin for “index.html”:
1 asset
Entrypoint undefined = index.html
[2] (webpack)/buildin/global.js 472 bytes {0} [built]
[3] (webpack)/buildin/module.js 497 bytes {0} [built]
+ 2 hidden modules

Let’s open the index.html. As we can see, the plugin automatically creates an updated index.html file for us which uses the title option from the configuration:

<!DOCTYPE html>
<html>
<head>
<meta charset=”UTF-8″>
<title>Webpack Output</title>
</head>
<body>
<script type=”text/javascript” src=”main.js”></script></body>
</html>

Let’s now expand our project and specify custom names for the entry and output properties. In webpack.config.js we add the following before the plugins property:

entry: ‘./src/app.js’,
output: {
filename: ‘[name].bundle.js’,
path: path.resolve(__dirname, ‘dist’)
},

Now, we’ll create an src/component.js file:

export default (text = “Hello webpack”) => {
const element = document.createElement(“p”);

element.innerHTML = text;

return element;
};

Next, we rename index.js to app.js to reflect our changes, and swap its content with the following:

import component from “./component”;

document.body.appendChild(component());

Now, let’s run webpack in production mode:

$ npm run build

> learn_webpack@1.0.0 build C:UsersUserWebpacklearn_webpack
> webpack –mode production

Hash: 9f78936f8a2a21061f0b
Version: webpack 4.30.0
Time: 1689ms
Built at: 2019-04-17 23:43:40
Asset Size Chunks Chunk Names
index.html 190 bytes [emitted]
main.bundle.js 1.04 KiB 0 [emitted] main
Entrypoint main = main.bundle.js
[0] ./src/app.js + 1 modules 227 bytes {0} [built]
| ./src/app.js 79 bytes [built]
| ./src/component.js 148 bytes [built]
Child html-webpack-plugin for “index.html”:
1 asset
Entrypoint undefined = index.html
[2] (webpack)/buildin/global.js 472 bytes {0} [built]
[3] (webpack)/buildin/module.js 497 bytes {0} [built]
+ 2 hidden modules

Let’s examine and clarify the information from the webpack output. Beginning from the top, we see the hash of the build, webpack version, and the time it took to execute the build. Next, we see the files generated in the dist directory (index.html and main.bundle.js). Below them, we see the entry module (app.js) and its dependency (component.js). The output after Child html-webpack-plugin for “index.html”: is related to the internal work of the html-webpack-plugin and we can safely ignore it.

So now, in the dist folder, we have the newly generated bundle file main.bundle.js. If we open index.html in the browser, we should see Hello webpack displayed on the page. Also, if we check the source of index.html, we’ll see that the value of the src property in the script tag is updated to main.bundle.js.

The post A Beginner’s Guide to Webpack appeared first on SitePoint.

Original Source: http://feedproxy.google.com/~r/1stwebdesigner/~3/Uy9iRDKkbpU/

When we think of content management systems (CMS), we often think about popular offerings such as WordPress and Drupal. Both rely on a traditional MySQL database, where a website’s content and settings are stored. However, not all systems work this way.

A flat file CMS, for example, eschews the need for a database server. They store site data in a simple text file. This cuts down on latency and can vastly improve site performance. It also opens the door for more customized data structures, easier portability and the ability to scale.

Today, we’ll introduce you to some of the more popular and intriguing flat file systems. They vary in feature sets and range anywhere from free to a few hundred dollars. Read on to find an option that fits your needs.

Statamic

One of the most well-known flat file systems, Statamic is based on the popular Laravel PHP framework. It offers a full suite of features, from built in forms, powerful media management and version control via git.

Manage your site through a well-thought-out dashboard (you can even access updates and maintenance features via the command line). There is also a library of third-party themes and addons that allow you to extend site functionality.

We should note that Statamic is commercial software, with a single site license running $199 USD. This entitles you to unlimited support and updates, however. And the software will run on virtually any server that can handle PHP. If you want to try it out first on a local environment, a free trial is available.

Kirby

Kirby is all about customization. For example, while an installation includes a templating engine based on PHP and HTML, you also have the ability to replace it with just about anything you want. But it doesn’t stop with your standard design and development. The CMS also allows developers to customize the admin panel to reflect the needs of the site itself. Things like the admin layout, permissions and fields can be added via files called Blueprints.

You’ll also find some unique features, such as the ability to use Markdown (extended via KirbyText), version control and a built-in REST API. True to form, Kirby will also work with other data sources – including databases.

Note that Kirby is also commercial software, with licenses running €99 per site. But you can try it for free on your local server.

October CMS

Like Statamic above, October CMS is based on Laravel. It features unobtrusive templating and utilizes the Twig template engine. This makes theming a fairly straightforward experience. Included support for Partials and Components allow for building modular sites, where code can be used and re-used. Extend things even further by installing (or creating your own) plugins.

Assets such as media files can be easily managed through the UI. Plus, you can integrate files from AWS or other cloud-based services. Files are sortable by type (images, video, documents, etc.) and can be stored in folders. This is somewhat similar to what you’d expect to find in an operating system.

October CMS is free and open source.

Grav

Grav separates itself from some other flat file systems in a few ways. First, the admin panel is optional. The CMS can be administered directly via the command line by default, but a full-featured dashboard is available via a free plugin. Second, like WordPress, it’s capable of a multisite installation – meaning you can run multiple websites from one instance of the CMS.

Like others in this roundup, you’ll also find lots of flexibility. Grav includes the ability to write content in Markdown or HTML, add custom fields, posts types or taxonomies, and works with the Twig templating engine. You can also extend functionality via plugins.

Free and open source, Grav boasts an enthusiastic community of developers.

Bolt

Featuring a back end built with a focus on content creation, Bolt offers a plethora of options for online publishers. A user management feature allows administrators to assign user levels to specific types of content, while a developer level allows for settings and template tweaks.

Theming is handled via Twig, and built-in form capabilities allow you to correspond with users without the use of a plugin. On the back end, Bolt is built on top of the Silex PHP framework and uses Symfony components. One unique feature is the ability to completely white-label the CMS – allowing developers to fully brand the admin area.

Bolt is open source available for free. Plus, all of its core code is available on GitHub.

Fast and Full of Features

Just hearing the term “flat file” can give the impression that you’re missing out on something. If it doesn’t use a traditional database, it can’t be very good, right?

A deeper look shows that a flat file CMS can be very competitive. The features available in the systems above are on par with their database-driven counterparts. And there are even some pretty compelling advantages to choosing flat file.

Among the biggest is that you can run a full-featured CMS quite efficiently on just about any level of web hosting. You don’t need a ton of horsepower to run a fairly large, high-performance website.

So, if you’re in the market for a new CMS, don’t be afraid to check out a flat file system. You may be surprised at how much they can do.

Original Source: http://feedproxy.google.com/~r/abduzeedo/~3/uWW5yUZnnJE/life-lesson-my-learnings-completing-30-ux-design-interviews

Life Lesson – My learnings from completing 30+ UX Design Interviews

AoiroStudioMay 16, 2019

François here from ABDZ. I would like to share a life lesson, it’s more than a lesson actually. I recently completed about 30+ UX design interviews during the course of the last 4-5 months, It’s not something I would pride myself about but I did learn numerous lessons that I would treasure to share on ABDZ. Wherever you are a long-time reader, new to the blog, professional or beginner; there are some actions in this article you can unquestionably learn from. Shall we give it a start?

Why? What? How?

First of all, why did I started this ambition? What were my goals? And how did I managed to tackle them. Right? Well it all started from a lack of accomplishment and unhappiness I was feeling from my previous gig. This lack of happiness became more of a real issue so I decided to part ways and tackle this “quest” to find me, the best design job I could possibly find and for my family. I was going to go all out on this “quest” because I have true confidence in my past work, my profile, and furthermore with my skill set. First and foremost I had my list of “requirements”:

Good salary
On-site anywhere in the World
Great challenges
Team ethics, design process
Benefits

A remote position would be a great addition to the list. For my case, I needed a change in the scenery. I have been living in the same city for 30+ years and cold winter days shouldn’t be part of our daily life anymore. *Cough Hello Montreal!

Some tools

During the course of these interviews, there were some weeks where I actually had more than 6 interviews all lined up in the path of two days, which is a lot to take in. So It was good to have Notion for example where I was able to create a “workspace” for all the places that I applied to and enter the individually updates. You should definitely check it out if you haven’t yet. Find the best tools that work the best for you and I find out that going “analog” helped a lot as well: the simple pencil/notebook was easily my choice for quick note-taking and later review everything into Notion.

Notion HQ

Before to begin

Remember job searching is not easy. Depending on your goals, your background, your experience and etc. During my search, I did get false hopes, got lied to, ghosted and it’s part of the game. It’s draining and not motivating at times, but again if you have the right balance and preparation. You should be able to balance it all, be warned still. There is nothing short of easy unless you have to give it your best. On the other side, I did meet and had conversation exchanges with some of the best in our industry. It’s always rewarding to know there are good people in our community. I will come back to that.

There is nothing short of easy unless you have to give it your best.

First, your resume

Be as transparent as possible. Look at your resume and if you were sharing a piece of you especially your work experience. I did manage to get my resume reviewed by several recruiters and collect their feedback so I can improve it. It helped a lot to justify several questions they might have got and I solved them through iterations on my own. I did collect small details that I just didn’t care but it was very important. Think of previous job dates! Recruiters and managers have little time to scan your resume so make sure you have a clear description of:

Company, your role, dates
What were your tasks for the role
What were your/or team design process
Skills, tools, “fields of design”
Be prepared to rework your portfolio many “many” times

Yes, you heard me! I think I have worked my portfolio 5-6 times and now I just can’t look at it anymore! Hah! It’s the best part of our job I think, reliving the past work and re-envision what worked well and what you would have done better under different circumstances.

Include the problem, process and solution
Include your contributions vs your team
If you wanna share a side-project? Please do!

Build your portfolio with 3-5 case studies, why case studies? It’s great to emphasize your past work through storytelling and share the pillars: problem, process, and solution. Try to visualize it this way, imagine yourself presenting your portfolio without you being there. Is it easy to navigate, does it answer to the pillars? We can totally continue this subject on the next on ABDZ…to be continued.

Understanding the hiring process

Hiring teams nowadays are doing a tremendous job to keep you in the loop during the entire process. Hat’s off to the recruiters for their work and taking the time to process it all. I am thankful for the many recruiters I have met and their work to make the entire process easier and less painful at times. Especially when “wait” becomes a great factor of “inquiétudes” which means worries. Some companies will even take the time to send proper documentation so you understand the entire hiring process which is a huge step from past years. Don’t be afraid to ask questions, even if you think they are dumb. They are no dumb questions.

Prep, prep and prep!

Recruiters might help you a chunk with the hiring process but you still have to do the heavy lifting. Preparations! Take the time to learn about the company you are applying for:

their story, product and services (if it does apply)
hiring process (on-site interviews), design process, company’s ethics
be passionate on learning more about them

About the on-site interviews, I beautifully “failed” one last year and I wrote my experience on ABDZ. There are a tons of great references out there but my piece of advice. Practice! The more you practice, the more you will be comfortable when you will be in this situation.

Build a network

You think the community is big but it is actually small. So keep it alive! My biggest job facilitator for me has been Twitter. I love Twitter and it’s an incredible platform to meet and interact with some of the best in the industry. If you are not on Twitter yet, please do NOW. Like NOW. If things don’t work out, don’t burn bridges with people because you never know when you will cross their path again. This is a lesson for me, I did burn bridges in the past and it’s not a great feeling. I learned my lesson though. Now, I rather take a neutral approach with everybody and keep it leveled even if things don’t go the way you would expect.

by YaroFlasher

Don’t be an a**hole. Period.

It’s kind of related to my previous paragraph, we navigate through a small but powerful community. Let me share this story that will totally make you see how our community is amazing and filled with incredible people. I went inside someone’s DMs on Twitter and poked that person for a job opportunity (That company was looking for their next designer). That person went to ask for my resume and portfolio so I sent it. And that person came back with very good critique feedback on my portfolio. It mentioned that my portfolio (at the time) was just “a detailed version of my resume.” I could have just flipped that person off and that would be it. But instead, I was so motivated by that critique so I spent the next four days redesigning my portfolio. That newer version of my portfolio opened even more doors that I could ever imagine. It totally pays off to listen for a change and learn to accept a critique of your work which is never easy. Thank you to this person for taking their time to critique my portfolio.

It totally pays off to listen for a change and learn to accept a critique of your work which is never easy.

Epicjobs by Dann Petty

One last thing but not least. I would like to share a shout to epicjobs.co, it’s a rad initiative by the mighty Dann Petty who is making this mission to help us find a job. You get to meet the people behind those job postings which is pretty wicked if you ask me. I wish this initiative existed before I started my search but wanted to take with you guys because it’s really great and helpful for our design community. Make sure to follow #epicjobs.

Last words

I hope this article helped you in some ways, again this experience helped me a lot understanding my goals and your dream job might be closer than you think. Again, be yourself. It’s the best advice I have ever got and if things don’t work out. Don’t let it go and work harder to achieve your goals. If you have any feedback, give me a shout on Twitter and if you have any inquiries for us at ABDZ. You find us through ABDZ Facebook.

Original Source: https://www.hongkiat.com/blog/childhood-technology/

Have you ever reminisced about the technology you used as a child or teenager? It’s amazing how excited we were back then with electronics like the Nintendo game console or a mobile phone the…

Visit hongkiat.com for full content.