Posts Tagged ‘javascript’

How to run Webpack Dev Server with PHP

Monday, March 20th, 2017 | Programming

You are making an awesome new JavaScript-based app in React. However, it needs to live inside an existing framework, such as Symfony for PHP. You want the hot-reloading function that you get with Webpack Dev Server, but you also need the content to be served from your LAMP stack because it creates the HTML wrapper page.

What do you do?

The answer is to run two servers: both Webpack Dev Server and your existing Stack. Here is how…

Configuring Webpack

Start by installing Webpack Dev Server as usual.

npm install --save-dev webpack-dev-server

Create a script entry in package.json to run it:

"scripts": {
    "start": "node ./node_modules/webpack-dev-server/bin/webpack-dev-server.js"
}

We also need to make one change to our webpack.config.js file. We need to tell the output to point back at the Webpack Dev Server. Otherwise, it will point at your LAMP stack.

output: {
    publicPath: 'http://localhost:8080/scripts/'
}

Super. Next, let’s configure the LAMP stack.

Configuring your existing server

This step is easy. All we need to do is to point the JavaScript at the Webpack Dev Server.

Let’s say you have this at the moment:

<script src="/scripts/app.js"></script>

Change it to:

<script src="http://localhost:8080/scripts/app.js"></script>

Remember that when you are building for production, you will want to take the changes out. The easiest way to do this is to have a dev webpack.config.js file, and a production one, and have your build tool use the correct one depending on the context.

Ember.js

Monday, March 16th, 2015 | Programming

emberjs Ember.js is a JavaScript framework for creating “ambitious web applications” apparently. What that translates to is a JavaScript framework that allows you to get started quickly and have URL-based apps.

It is under heavy active development at time of writing so means that there is plenty of new stuff but also means that the documentation can quickly get out-of-date, so it might take a bit of time fiddling around to get it bootstrapped up and up-and-running. There is a helpful Chrome plugin that fits into the Developer Tools too, though most of the time I spend time looking at the standard console.

Once you are ready to go, things are easy to build. It uses Handlebars, or at least a Handlebars style syntax, so if you have used Handlebars, or even Mustache before then you will probably have a basic idea of what you are doing. You can then layer up pages within each other to build complex applications that can all be bookmarked.

It is designed to work out-of-the-box with Ember Data, which provides instant support for a REST API. If you do not have a REST API, Ember.js claims it is easy to adapt to something else, though I’m sceptical that it is as easy as they claim. It seems to work best if you build the app, and then create a standard REST API to work with it.

I have implemented some simple embedded Ember.js apps for my photo gallery as well as working with it for some more complex projects elsewhere. It is a fun framework to work with, but the documentation is a little parse and it is not quite as flexible as I would like. See the Ember.js website for more information.

JavaScript: The Good Parts

Friday, February 20th, 2015 | Books

I’ve read Douglas Crockford’s book on JavaScript several time before, but it is always goof to have a refresher. It’s super-helpful and so short that you can easily get through it in a day if you try. I think the appendices are actually bigger than the text.

JavaScript-The-Good-Parts-cover

Testing select fields in Mocha

Thursday, October 10th, 2013 | Programming

Recently I spent a good twenty minutes tearing my hair out over a JavaScript unit test I was trying to write. The answer turned out to be a difference in the way our Mocha-based DOM differs from how it would running JavaScript in a browser.

For example, let’s say you have a select field.

<select name="test" id="test">
	<option value="">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In a browser, the top option would be selected by default, so if you had the following code:

jQuery('#test').val();

It would output a blank value as you would expect. However, run this in Mocha and you will get an undefined or a null. The reason is Mocha doesn’t select the top option by default unless you manually specify it to. So your HTML would have to look like:

<select name="test" id="test">
	<option value="" selected="selected">Select an option</option>
	<option value="1">Option 1</option>
	<option value="2">Option 2</option>
</select>

In which case, it would then return the value as it should.

Web workers

Saturday, February 2nd, 2013 | Limited, Programming

These days, we’re all trying to do very clever things in the browser, that take up heaps of system resources. Often, your application will be doing so much that the system can barely cope – and with JavaScript being a single thread language, heavy processing can tie the UI up and make the user think the page has crashed.

Enter web workers – a background process that essentially allows you to do concurrent JavaScript. You can create a background process from a script, and then send messages back and forth between it and the page, ensuring you don’t tie up the UI.

They’re really simple to use too.

var worker = new Worker('worker.js');

worker.addEventListener('message', function(e) {
  console.log('Message from worker: ', e.data);
}, false);

worker.postMessage('Hello, World!');

Then create a simple JavaScript for your worker.

this.addEventListener('message', function(message) {
  this.postMessage(message.data);
}, false);

You can read more about web workers on HTML5 Rocks.

JavaScript’s querySelector

Sunday, September 2nd, 2012 | Programming

jQuery has an amazing set of selectors, but what happens if you don’t have access to jQuery?

It happens, especially if you’re writing the automated tests or working within an existing framework and don’t necessarily have control over the content of the page. Luckily, you don’t actually need jQuery!

All modern browsers support the use of querySelector. When I saw all modern browsers, I even include Internet Explorer which added basic support for it in 8 and full support in 9. You use it like this.

document.querySelector(“p.introduction”);

This works just like jQuery – selecting all paragraph tags with the class introduction.

The Future of PHP

Thursday, June 14th, 2012 | Events, Programming, Tech

Last month, I went to a talk by Richard McIntyre on “The Future of PHP”.

Turns out, it’s JavaScript.

More and more these days, web applications are being developed with fat front end clients loaded with JavaScript, and the server side processing is primarily used for data processing and APIs. So we’re seeing a shift from PHP being used as a somewhat front end technology to merely (I say merely, there is a lot of work to do it) delivering the content in a format the JavaScript front end can consume.

Perhaps this is why we’ve seen a rise in the number of microframeworks, such as Silex, that I recently blogged about.

I think the overriding message I took away from the talk though is that they’re inventing development platforms faster than I can learn them! I’ve already got a large list of technologies and libraries I need to review and I think I came away from this talk with another half a dozen!

Really enjoyed the talk though, and if you’re interested in PHP and in the Leeds area you should definitely check out the Leeds PHP User Group who host such events on a monthly basis.