James Hibbard – SitePointhttps://www.sitepoint.com
Learn CSS | HTML5 | JavaScript | Wordpress | Tutorials-Web Development | Reference | Books and MoreThu, 24 May 2018 17:36:09 +0000en-UShourly1https://wordpress.org/?v=4.8.1What Is Node and When Should I Use It?https://www.sitepoint.com/an-introduction-to-node-js/
https://www.sitepoint.com/an-introduction-to-node-js/#commentsFri, 19 Jan 2018 00:25:25 +0000http://www.sitepoint.com/jspro/?p=99So you’ve heard of Node.js, but aren’t quite sure what it is or where it fits into your development workflow. Or maybe you’ve heard people singing Node’s praises and now you’re wondering if it’s something you need to learn. Perhaps you’re familiar with another back-end technology and want to find out what’s different about Node. […]

]]>https://www.sitepoint.com/an-introduction-to-node-js/feed/26 jQuery Form Wizard Pluginshttps://www.sitepoint.com/jquery-form-wizard-plugins/
https://www.sitepoint.com/jquery-form-wizard-plugins/#commentsWed, 30 Aug 2017 18:00:35 +0000http://www.jquery4u.com/?p=13786A jQuery Form Wizard is a jQuery plugin that assists with the creation of forms with some sort of form flow (without refreshing your page). For example, if you had a large form for entering user data, you could use a form wizard to divide it into a series of related steps. This has the advantage of not overwhelming users with a really long form and also giving them some indication of their progress as they enter their information.

In this post we list 6 of our favorite jQuery form wizards, examine their different features and finally look at a couple of paid options, as well as how to create your own. This isn't intended to be an exhaustive list, but if you are looking for a jQuery form wizard, then hopefully this will point you in the right direction.

This popular post was updated on 30.08.2017. Broken / abandoned plugins were removed from the list and new plugins were added to reflect features people were asking for in the comments.

1. jQuery Steps

jQuery Steps is a smart UI component which allows you to easily create wizard-like interfaces. This plugin groups content into sections for a more structured and orderly page view. It has a plethora of features, such as async content loading, state persistence (it saves your input between steps) and transition effects between sections. It can be installed via NuGet or bower and has a well-documented and feature-rich API.

2. jQuery Smart Wizard

Smart Wizard is a flexible and heavily customizable jQuery step wizard plugin with Bootstrap support. It is easy to implement and gives a neat and stylish interface for your forms, checkout screen, registration steps etc. Its features include theme support (with various themes included), URL navigation and step selection and the ability to dynamically hide or disable steps. It can be installed via npm, bower or composer and has a well-documented and feature-rich API.

3. formToWizard

This lightweight plugin turns any webform into multi-step wizard with jQuery, whereby every form <fieldset> is turned into a separate step with forward and back buttons. It doesn't have nearly as many features as the previous two plugins, but does integrate with the jQuery validation plugin to provide validation functionality. It is a single file (so you can just grab it off GitHub and go) and if JavaScript is unavailable, it degrades gracefully.

]]>https://www.sitepoint.com/jquery-form-wizard-plugins/feed/9How to Bundle a Simple Static Site Using Webpackhttps://www.sitepoint.com/bundle-static-site-webpack/
https://www.sitepoint.com/bundle-static-site-webpack/#respondMon, 24 Jul 2017 20:00:11 +0000https://www.sitepoint.com/?p=157341Webpack is all the rage right now. It has over 30,000 stars on GitHub and has been embraced by some of the big guns in the JavaScript world, such as the React and Angular.

However, you don't need to be working on a large-scale project to take advantage of Webpack. Webpack is primarily a bundler, and as such you can also use it to bundle just about any resource or asset you care to think of.

In this article, I'm going to show you how to install and configure Webpack, then use it to create a minified bundle for a simple static site with a handful of assets.

But Why Would You Want to Do That?

Good question. Glad you asked!

One of the primary reasons for doing this is to minimize the number of HTTP requests you make to the server. As the average web page grows, you'll likely include jQuery, a couple of fonts, a few plugins, as well as various style sheets and some JavaScript of your own. If you're making a network request for each of these assets, things soon add up and your page can become sluggish. If you include all of the above in one bundle however, that problem disappears.

Webpack also makes it easy to minify your code, further reducing its size, and it lets you write your assets in whatever flavor you desire. For example, in this article I will demonstrate how to have Webpack transpile ES6 to ES5. This means you can write JavaScript using the latest, most up-to-date syntax (although this might not be fully supported yet), then serve the browsers ES5 that will run almost everywhere.

And finally, it's a fun learning exercise. Whether or not you employ any of these techniques in your own projects is up to you, but by following along you'll get a firm understanding of what Webpack does, how it does it and whether it's a good fit for you.

Getting up and Running

The first thing you'll need is to have Node and npm installed on your computer. If you haven't got Node yet, you can either download it from the Node website, or you can download and install it with the aid of a version manager. Personally, I much prefer this second method, as it allows you to switch between multiple versions of Node and it negates a bunch of permissions errors, which might otherwise see you installing Node packages with admin rights.

We'll also need a skeleton project to work with. Here's one I made earlier. To get it running on your machine, you should clone the project from GitHub and install the dependencies.

What I am doing here is telling Webpack to bundle the contents of src/js/main.js into dist/bundle.js. If everything is installed correctly, you should see something like this output to the command line:

Notice how we can leave out the full path to the Webpack module, as when run from a script, npm will automatically look for the module in the node_modules folder. Now when you run npm run build, the same thing should happen as before. Cool, eh?

Create a Webpack Configuration File

Notice how we're passing the path of the file to bundle and the path of the output file as arguments to Webpack? Well, we should probably change that and specify these in a configuration file instead. This will make our life easier when we come to use loaders later on.

In webpack.config.js we are specifying the entry point and output location of the bundle as properties of the configuration object, which we are then exporting . Run everything again and it should all work as before.

]]>https://www.sitepoint.com/bundle-static-site-webpack/feed/0How to Write Shell Scripts with JavaScripthttps://www.sitepoint.com/shell-scripts-javascript/
https://www.sitepoint.com/shell-scripts-javascript/#commentsMon, 01 May 2017 17:00:03 +0000https://www.sitepoint.com/?p=153388This week I had to upgrade a client's website to use SSL. This wasn't a difficult task in itself — installing the certificate was just the click of a button — yet once I had made the switch, I was left with a lot of mixed content warnings. Part of fixing these meant that I had to go through the theme directory (it was a WordPress site) and identify all of the files in which assets were being included via HTTP.

Previously, I would have used a small Ruby script to automate this. Ruby was the first programming language I learned and is ideally suited to such tasks. However, we recently published an article on using Node to create a command-line interface. This article served to remind me that JavaScript has long since grown beyond the browser and can (amongst many other things) be used to great effect for desktop scripting.

In the rest of this post, I'll explain how to use JavaScript to recursively iterate over the files in a directory and to identify any occurrences of a specified string. I'll also offer a gentle introduction to writing shell scripts in JavaScript and put you on the road to writing your own.

Set Up

The only prerequisite here is Node.js. If you don't have this installed already, you can head over to their website and download one of the binaries. Alternatively, you can use a version manager such as nvm. We've got a tutorial on that here.

Getting Started

So where to begin? The first thing we need to do is iterate over all of the files in the theme directory. Luckily Node's native File System module comes with a readdir method we can use for that. It takes the directory path and a callback function as parameters. The callback gets two arguments (err and entries) where entries is an array of the names of the entries in the directory excluding . and .. — the current directory and the parent directory, respectively.

If you're following along with this, save the above in a file named search_and_replace.js and run it from the command line using node search_and_replace.js. You'll also need to adjust the path to whichever directory you are using.

Adding Recursion

So far so good! The above script logs the directory's top level entries to the console, but my theme folder contained subdirectories which also had files that needed processing. That means that we need to iterate over the array of entries and have the function call itself for any directories it encounters.

To do this, we first need to work out if we are dealing with a directory. Luckily the File System module has a method for that, too: lstatSync. This returns an fs.Stats object, which itself has an isDirectory method. This method returns true or false accordingly.

This made me sit up and take notice. The libraries these researchers were checking for were 72 of the most popular open-source projects out there — libraries like Angular and jQuery that we all use every day. I'd never really stopped to think whether an outdated version of jQuery could present a serious security threat. And I had (almost) certainly never gone back to update an old version of jQuery on a website I had made. Was this something I should have been doing?

My Career as a L33t H4x0r

So, now I was curious and decided to see if I could use an outdated version of jQuery to hack one of my own pages. I started off searching for "jQuery security vulnerabilities" and pretty soon stumbled across this issue on jQuery's GitHub repo. People were pointing to this as a potential cross-site scripting vulnerability which meant that an attacker could execute arbitrary code at the request's origin. That sounded promising ...

The issue was easy enough to reproduce — the problem was that jQuery was executing every text/javascript response it received when performing a $.get() request — but that was as far as my excitement went. As one of the jQuery maintainers pointed out in the thread, this "exploit" was similar to including third party code via <script> tags. This wasn't likely to bring my website to its knees and was hardly the stuff hacking movies are made of.

Take 2: A Bit of Session Hijacking

Not wanting to be deterred, I imagined what I would do if the exploit had worked and I could execute arbitrary code on a user's computer. One thing we are often warned against is session hijacking where a malicious script can manipulate a user’s cookies to gain unauthorized access to information or services they are logged into. I thought I'd try my hand at that.

]]>https://www.sitepoint.com/keep-javascript-dependencies-up-to-date/feed/2What Is the Best Book for Learning JavaScript?https://www.sitepoint.com/best-book-for-learning-javascript/
https://www.sitepoint.com/best-book-for-learning-javascript/#commentsMon, 06 Mar 2017 19:00:16 +0000https://www.sitepoint.com/?p=150025This is the editorial from our latest JavaScript newsletter, you can subscribe here.

"What's the best book to learn JavaScript?" is a question that I've heard asked a lot lately. There are certainly a lot of to choose from. A quick search of Amazon reveals that (at the time of writing) 34 new JavaScript books have appeared in the last 30 days. And another 40 are marked as coming soon. Madness!

So how should you go about choosing the right book for you? Obviously there is no one-size-fits-all approach, but today I'd like to present three of my favorites. I hope they will provide some inspiration and offer additional pathways to explore on your learning journey.

Note: We all have preferences about how we learn, as well as what we expect from learning material. This is not a definitive list, rather a selection of books that I enjoyed and which have helped me further my JavaScript knowledge.

Eloquent JavaScript, 2nd Edition

Eloquent JavaScript by Marijn Haverbeke is a book is aimed at ambitious beginners. The author assumes no prior JavaScript knowledge on the part of the reader and does a great job of introducing them to the language in an informative, yet entertaining way. One of my favorite things about this book is that it doesn't just focus on the mechanics of the language, rather it teaches the fundamental concepts of programming and computer science to boot.

The book is split into three parts — the first concentrates on the language itself, the second concerns using JavaScript in the browser and the third (and smallest) part is devoted to Node.js. It also contains exercises and project chapters (in my opinion a great way of reinforcing the concepts learned). These see readers build such things as an artificial life simulation and their own programming language (I did say ambitious).

Although Eloquent JavaScript starts of slow (looking at variables, functions, basic control flow etc) it soon picks up the pace with topics as recursion, polymorphism and higher-order functions being covered in the first part of the book. This might mean that the absolute beginner has to take multiple passes at the reading, but it also means that there plenty of good stuff for the intermediate level programmer to get their teeth into.

My only gripe with Eloquent JavaScript is that it focuses on ECMAScript 5 with ES6 hardly getting a look in. This is a shame (and I hope it is addressed in the next edition), but overall I don't think that it detracts from the value of the book as a great learning resource.

You Don't Know JS

You Don't Know JS by Kyle Simpson is a series of books that examine the inner workings of the JavaScript language. Book one of this series assumes little or no prior JavaScript knowledge and introduces various programming building blocks which are explored in more depth in subsequent books. Saying that, I would hesitate to recommend this series to a beginner, as by the end of book two (Scope and Closures) the author is already tackling some pretty advanced stuff. For example exploring closures through implementing his own module loader.

I’d like to start this newsletter with a massive thank you to everyone who took the time to fill out our survey. You rock! We had a great response and the results turned up some interesting facts about our audience. Here’s a brief summary of the main points.

Of the people that answered:

41% described themselves as front-end developers, 28% as full-stack

55% described their skill level as intermediate

50% consider ES6 to be the future, 39% had heard of it and wanting to find out more

75% use some kind of build tooling (be it a module bundler or a task runner)

55% want to learn more about languages that compile to JavaScript

56% use PHP as another language on a regular basis, only 7% use Ruby

55% would like to see more content on application architecture, design patterns etc

For those of you that are interested you can find the full results of questions 1-10 here. Please note that question 11 is not included, as it is a free text question and thus impossible to summarize.

There were a few surprises in there for me, for example that there is such a high interest in compile-to-JS languages, or that such a small percentage of respondents use Ruby (sniff!). There was also a lot of actionable feedback. We’ll be weighing this up in the coming weeks and incorporating it into our content strategy.

Reader Feedback

In the final question we asked readers what we could do better. We got a lot of great comments and rest assured, we read them all. Thank you everyone that took the time and thank you too, to everyone that said we are doing a great job. We appreciate that!

Other people left more actionable comments and I’d like to answer some of them here. Anyone whose comment I haven't addressed, or who has further comments of any kind is welcome to drop us a line.

Here's what people said:

We developers are always worried about our tools and shifts in tech trends (i.e., backing the wrong horse). It would be great to have more pieces aimed at validating our stack-choices. For example, "Is Angular adoption outpacing React in Enterprise?" or "What is the average salary of developers vs JS framework specialty?" or "What are some hot new npm packages we should be aware of?" This sort of analysis brings SitePoint from "nice" to "IMPORTANT". Tutorials and tips are nice but they are everywhere. On the other hand, it's hard to find good analysis to help with business decisions.

Great feedback, thank you, noted. We do actually have an article in the pipeline on useful npm packages, so watch out for that. And we will take the idea of more analytical content on board.

Tutorials should include editors so that we can practice right away

Many of our tutorials have embedded demos for exactly this purpose. For simple client-side demos we use CodePen (example). For more involved code we use services such as Plunkr (example). We also include a GitHub repo with every tutorial so that readers can clone the demo and run it locally.

The small tips that are missing from most of tutorials turn to be the small pieces that prevent newbies like me to understand and follow the articles. Don't skip steps, for smaller they are.

Got it. We can't always cover every aspect of every technology in every tutorial, as we need to pitch our articles at the widest possible audience. When we do skim things for the sake of brevity, we endeavor to link to articles that will help you fill in the gaps. Also, don't forget that there is SitePoint forums — a great place to ask questions if you get stuck.

]]>https://www.sitepoint.com/sitepoint-2017-javascript-survey-results/feed/1Editorial: What Do You Want to Learn in 2017?https://www.sitepoint.com/what-do-you-want-to-learn-in-2017/
https://www.sitepoint.com/what-do-you-want-to-learn-in-2017/#commentsMon, 09 Jan 2017 19:00:27 +0000https://www.sitepoint.com/?p=146719This is the editorial from our latest JavaScript newsletter, you can subscribe here.

Hey everyone, welcome to a brand new year on SitePoint JavaScript. I hope you had a great break (for those of you that took one) and are ready to start off 2017 with a bang.

2016 was a crazy year for JavaScript! We saw an ever increasing adoption of ES6 and the rise of progressive web apps. Also, Yarn emerged as a competitor to npm and JavaScript fatigue fatigue became a thing. In case you missed any of this, or you’d simply like to reminisce on the year just passed, we've got you covered. Craig Buckler looks at these events and more in his post JavaScript: 2016 in Review. It’s well worth a read.

Looking forward to 2017 I wonder two things. Will this year be as crazy as the last? And where should I focus my learning efforts in the coming 365 days? The answer to the first question is “almost definitely”, but the answer to the second is somewhat more complicated. Knowing what to learn depends rather a lot on your situation, for example are you looking for a new job? Do you want to become more productive in your current one? Or do you want to check out a couple of new technologies to get a feel for how they stack up against those you already know?

As for me, I decided that one of my goals for 2017 would be to cut back on my use of jQuery. This isn’t because I’ve suddenly jumped on the anti-jQuery bandwagon. I haven’t. Rather because jQuery was so awesome when it first came on the scene, that today I often use it without thinking. I don't stop and consider what browsers can do natively.

]]>https://www.sitepoint.com/what-do-you-want-to-learn-in-2017/feed/11Editorial: What Does Open Source Mean to You?https://www.sitepoint.com/what-does-open-source-mean-to-you/
https://www.sitepoint.com/what-does-open-source-mean-to-you/#respondMon, 14 Nov 2016 19:00:09 +0000https://www.sitepoint.com/?p=143312We love our themed weeks here on SitePoint. Earlier this year we had IoT week, which saw us (me in my tin hat) publishing articles focused on the intersection of the internet and the physical world. The week was a big success, and so now we're back by popular demand with an entire week dedicated to all things open source.

We'll get on to all the goodies we have lined up in a minute, but first I want to take a moment to reflect on what open source means for me.

The open source project I use most often is my computer's operating system (Linux Mint). It is stable, polished, has a sleek UI and puts a whole host of (awesome) free and open source software at my fingertips. It would be easy to take this for granted (I mean you just download it and install it, right?), but in reality it is made possible by an army of volunteers, who are hard at work behind the scenes. I think it's important we don't forget that.

The same goes for the large amount of open source JavaScript projects available to us developers. Whether they are intended to help you build amazing apps, or as a learning resource to help you level up your skills, these are all projects, supported and maintained by the community. Thanks to the collaborative nature of open source, you're free to download and modify any of them and, most importantly, to contribute any changes you make back to the project itself.

]]>https://www.sitepoint.com/what-does-open-source-mean-to-you/feed/0Editorial: Is JavaScript Always the Best Solution?https://www.sitepoint.com/is-javascript-always-the-best-solution/
https://www.sitepoint.com/is-javascript-always-the-best-solution/#commentsMon, 31 Oct 2016 18:00:04 +0000https://www.sitepoint.com/?p=142423Lately, there has been a lot of discussion surrounding the role of JavaScript in modern web pages and web apps. It all seems to have kicked off with an amusing (but not entirely untrue) article entitled How it feels to learn JavaScript in 2016 in which the author expresses his concern at the fragmented state of the JavaScript ecosystem and the amount of tooling necessary to start a JavaScript project today.

In the debate that followed, there was an interesting Twitter poll that caught my eye. It asked if in 2016, it's OK to build a website that doesn't work without JavaScript. Of the 4,157 people that replied, 42% (so 1,746 people) declared that it was. Woah!

As editor of SitePoint's JavaScript channel you might expect me to be among those 42%. Well, sorry to disappoint, but I'm afraid I'm not. As my colleague Patrick recently pointed out, it all depends upon the context. Keeping an open mind as to the most accessible and most reliable method of solving a problem, will inevitably lead to the best solution. Here's a small example to illustrate the point: