A Question About Module Dependencies

After writing some custom Grunt tasks, and getting my feet wet with node, then following this up with some work using browserify. I had a feeling there would be a trend in front-end development for micro libraries (in the style of node) on the horizon.

I have yet to figure out if this will be a good thing for the front-end.

One of the strengths of node modules is how it deals with the dependencies for each module; and that is to keep each module and the modules it is dependant on in a separate package.

That's a lot of utility libraries

This can lead to duplication in a project. As two modules can both have a dependency to the same module but each package for those original two modules will have it's own version of the dependency included.

This can result in duplication in the final version of the product being produced.

As of writing (28th August 2014) there are 91 472 packages on npm; and of the top ten most depended on packages underscore and lodash (two utility libraries that have a common API) are depended on by 11 647 packages (6937 and 4710 respectively). So just over 12% of the packages share this dependency and each package includes it's own version of underscore/lodash.

Version was an important word

One of the advantages of each package having it's own dependencies is the version of the depended on module does not matter. e.g. moduleA could require lodash 1.1.1; while the newer moduleB uses lodash 2.4.1.

In the node world this way is working!

Server side this works great. Everything is kept clean and separated. The advantages of this approach at the server (and local development) side greatly outweigh the costs of duplication.

Will this work for the front-end

In the front-end world of concatination and minification. The costs of duplication seem higher. More data being passed down the wire, more for the browser to process.

As with many things in the development world its striking that balance between the advantages a technology brings versus the costs.

So long term another technique could be used for smart reusable clean modules.

To use this node style technique in front-end development, while trying to minimise the costs of duplication, will require restraint from developers. Restraint from front-end devs to decide on a case by case basis of the costs of adding a new module.

DevTools the third space

It always comes down to coffee and development

I recently thought of a tenuous link between Chrome DevTools and Starbucks. Starbucks set itself an early goal to become the 'third space', the space a person would spend time between work and home.

In my development Devtools has become my third space. Between the source and the output. You'd write some code, check the output and based of the result, you'd go back and update your code. Back and forth a binary existence of either coding or assessing results.

With Devtools I now have a third space, and for me my most important space as this is where I do my thinking. As it gives me hooks into the three areas that make up a website the DOM

theoretical next step

So the next step would be to start saving the changes I'm making in Devtools. Which is where workspaces come in, the ability to map the files delivered to the browser to it's location on the disk, allowing the source files to be edited.

However the files being delivered to the browser are not always the source files that need editing. Pre-processors for CSS and JavaScript are extremely helpful in development but this adds an extra layer between the source files and the workspace. This is where source maps come into play. To bridge that link between the delivered files and the source files.

and in anger?

Reading Remy Sharp's blog source maps may not be the answer quite yet for JavaScript but I plan on testing workspaces, source maps and browserify together. Its in the 'would be nice' column to add to my workflow. The one that 'would be great' to add is CSS.

So I'll grab a coffee set up source maps and workspaces see how they work, try and blur the lines between spaces and report back.

photo credit: el patojo via photopin cc

Devtings getting started

devtings.net now forwards you to the Devtings meetup page. There right now is a the first scheduled event for a pre-meetup meetup. It's in need of a date and location, but to know when and where to schedule it, some members are needed so we can figure it all out.

quick hello

I did get a surprise after I set-up the group. I got an email from meetup HQ giving some advice on running successful meetups and then at the end of the email a 'p.s.' just to let me know they'd updated the topics attached to the group. I checked and saw they'd added 'tech talks' and 'education and technology' to the list of topics. Which I thought was excellent (although maybe a bit ambitious to start off with). They did also mention one fact in the email that meant I had made a small miss-calculation.

live and learn

I set the meetup site on a Tuesday. Thinking that it would be sent out to meetup.com members right away. This is not the case, they actually wait 4 days before posting it out. So rather than the notice being sent out midweek, it will go out just before the weekend. I do like the window though, gives you an opportunity to get the page set-up fully, while at the same time giving you a ticking clock incentive to get it done.

what next

Hopefully get a few members over the next few days and schedule the pre-meetup. Go down the pub (probably), and see what we can turn Devtings into.

devtings

who wants to talk about development stuff?

If you go to meetup.com and search for developer meet-ups, depending on where you are in the country you will see dozens of different meet-ups available for all flavours, variations and discipline of developer. With one small caveat the majority are based in a city.

As a developer who would like to talk to other developers about development, this posed a problem for me. Being based in Hastings the amount of time it would take to travel to these meet-ups made attending any very difficult. So I had an idea; Why not set-up a local developer meet-up. A developer meet-up in Hastings, so devtings.

That's as far as I've got so far, an idea (and a domain, and an IRC channel). This blog post will be about the thoughts and assumptions I've had regarding the setting up the meet-up, and as we move forward my plan is to blog about the reality of it.

meet-ups in theory

One of the things I have realised is that a local dev meet-up can't be the same as a larger meet-up. Firstly you can't be too specific in your topics and audience. A meet-up like Functional Brighton would be too specific to build a regular meet-up around, however talks and discussion about functional programming would make a great contribution. A good model I think for this is podcasting. A podcast like .Net Rocks! will cover various different aspects and disciplines of development. Then with guest experts to deliver some deep insight into the topics covered.

presentations

With a local meet-up it will be more difficult to get a wide variety of industry experts to come and give presentations. But there is opportunity in that as well. There will be people who want to be industry experts, who want to be a presenter at conferences a local meet-up would give them a place to practice, develop their skills and hopefully be a stepping stone for them. The other opportunity is for regular members of the meet-up to give their own presentations. Again this gives people an opportunity to develop their own skills and confidence.

Other items of business

Although the presentations will be an important part of the meet-up, they will not be the only part. The meet-up should be a relaxed environment where developers can discuss anything they want. Structure is important so people know what to expect but at the same time things need to be flexible and if this is going to be a successful venture it needs to grow organically.

How much is this all going to cost?

The costs of a meet-up. Costs are something that can grow and grow quickly. Starting off with organisation; you need an online presence you can point people to. Then with a place people can go it needs to be followed up with some promotion. Venues, food and drink, guest speakers; all these things cost money. So while this idea is getting off the ground we'll ignore the more formal ideas. Keep costs low, see if there is an interest and build from there.

what we've got and what we need

So far we have a domain (devtings.net) and thanks to Alex Hitchins an IRC channel #devtings.

pre-meet-up-meet-up

So far I've floated the idea to a few developers I know and work with and have got a positive response. So the next step, it's to get a few more devs and go to the pub. Start fleshing out some ideas, see what others can contribute and lets take a bunch of devs living in Hastings and start building a community of developers.

Adam Sanderson

I am a front-end developer. My day-to-day work is with JavaScript which is lucky because that's the part of web development I find most interesting.

I've had an idea for a local developer meet-up in Hastings called Devtings