SCOTT:
Hi John.
JOHN:
Can you come out and play? [Laughter] Let me ask my mom!
[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Ready to master Angular? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours -- AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “angularadventures” you'll get a $10 credit!]
CHUCK:
Hello everybody and welcome to Episode 62 of the Adventures in Angular Show. This week on our panel we have Ward Bell.
WADE:
Hello there!
CHUCK:
John Papa.
J:
Hello everybody.
CHUCK:
Lukas Reubbelke.
LUKAS:
True story, bro.
CHUCK:
I’m Charles Max Wood from Devchat.tv and this week we have a special guest – Scott Allen.
SCOTT:
Greetings and salutations.
LUKAS:
Yahay!
WADE:
Now, how do we know this is the real Scott Allen?
SCOTT:
Well, there are a few out there on the internet.
CHUCK:
Impostors not accepted, huh? [Chuckles]
SCOTT:
I don’t know Ward. I don’t know what I could do to prove my identity.
WADE:
I think that if we were talking about identity in today’s show, it would be a perfect segway – or not. Today, we are talking about package managers in the brand new world of – well, how would you even characterize this brand new world, Scott?
SCOTT:
Well, it think things have certainly changed since we got the 2015 specifications for JavaScript and modules became a real thing because that seemed to accelerate a movement towards different types of package managers – package managers that could handle modules a little bit better.
And certainly, if I’m going to continue – I think there’s a few tools spreading around that we were kicking around the idea of discussing. And when you’re talking about package managers, there’s certainly going to move from simple package management, something like Bower, where you just want to Bower-install something and Bower will happily download that something and put it on your file system.
There has been a move to something more sophisticated like Jspm where – Jspm is a package manager. You can say, “Jspm, please install Angular or Angular 2 or jQuery,” and it will grab some bit and put them on your file system but then it also maintains some configuration that can be used at runtime so that you can load these libraries as modules or load modules s modules.
CHUCK:
That’s what I was going to ask first was, yeah, are we talking about traditional package managers or are we talking about module managers.
SCOTT:
Well, in the case of Jspm there’s a little bit of overlap there because there are certainly other tools that don’t necessarily get involved in package management as much. They say, “Use Bower, use Npm – use whatever you want to get things onto your file system.” But once they're there, you can treat them as modules or you can write code in modules and we will take care of putting everything together for you so that you can actually serve it into a browser in an efficient manner. And tools like that – hpack would be one mutable example and Browserify would be another one. Of those three – Jspm, Webpack and Browserify – they all have slightly different perspectives on the world and that would influence which of those tools you may choose and which workflow you may use with others.
JOHN:
Now, to pick up on Chuck’s point though, because there seemed to be a lot of functions and [inaudible]. There’s finding packages and maintaining packages and libraries of packages – blah, blah, blah, blah – just the packaging itself. And just one area of functionality – and there were tools dedicated to that, but your also talking about my application requests these modules using these – the exact same tool; is that what we were saying here or are we really keeping the dividing line between those things that manage packages and click them on my machine versus [inaudible] those tracks, assessing those packages once they’re wherever they are. [Crosstalk]
SCOTT:
So it all blends together. I guess going back to the opening question – what’s different now? What’s different now is that people are starting to offer code that cannot execute natively in the browser, so it’s written with ECMAScript 2015 or ES 7 or whatever future standards out there that hasn’t been implemented yet. Or using modules where the syntax for the language has been defined quite clearly but the browser implementation to actually deal with modules isn’t there yet, so you need some sort of library to help you with that.
That’s what’s different about the world today. So if you're going into something and you want to build an application using Angular 2, and you want to use TypeScript which will compile into modules, you're still going to need some tool or runtime polyfill which will understand how to load that code and get it into the browser to execute in the proper manner.
JOHN:
Got it.
LUKAS:
I think we’re talking about a few different things, right? We’re trying to clarify what these are and there’s – you’re saying, as you were talking about –. How do you get your modules first place, like Npm Install. Some of these things do that for you, particularly Jspm does that as well for you. But then there’s the next step that once you got these things, how do you load the modules in the browser as you said. Then you can use a third side of that which is how do you bindle? Can each of these bundle or not?
CHUCK:
What do you mean by bundle?
LUKAS:
So bundling means – loading modules is where you're saying ‘I’ve got 20 modules in my app and they kind of successively load each other as they go.
CHUCK:
Right.
LUKAS:
Which could be great, but in a large application, once you can be on demo-land, you might want to make bundles of certain sections of your application. Maybe the customer sales partner application holds in shifting modules and then there’s another part that pulls in another 20 modules. So you want to create bundles that can do that for you.
I see this conversation as, “How do we solve each of those? How do you get your modules on your machine? How do you load your modules? And then how do you deal with bundling? I have no predisposed idea of one thing has to be all three of those either.
SCOTT:
Oh sure. So let me kick around something that I was thinking about today in preparation for this podcast which is these three primary tools that people are using today to deal with modules. So we’ll talk about package management, bundling and things like that also but there’s a tool called Browserify and if you look at the Browserify philosophy, it was essentially looking at the world through the lens of a Node.js programmer. So you're Node.js programmer offering JavaScript using CommonJS modules, and now you want to have that script put together and loaded so it can execute in a browser which doesn’t understand anything about CommonJS; that is something that Browserify can do.
And there’s another rather popular tool called Webpack, which has a slightly different philosophy which is that you're writing JavaScript code doesn’t have to be a Node and there’s a good chance that you're writing modular JavaScript code where JavaScript file is a module and it will import things from other places and export things. And it can be using CommonJS or it could be using asynchronous module definition; it could be using ES syntax – ES 6 syntax – it doesn’t matter. What Webpack can do is you can tell Webpack, “Here’s the entry point to my application. Now please take that file, analyze it, figure out what the dependencies are – what are the modules that depends on it and what the dependencies of those modules are – and just put something together for me so I can efficiently deliver a script to the browser that is a single download that will give me all the features I need.
That might be just a features that are enough to get your shell page up and running. So a minimal download – a minimal code download just to get things up and running and then later load additional pieces that Webpack had put together for other areas of your application. And you basically just want to get chunks of JavaScript code into the browser to satisfy the user – what the user is trying to do. So they click to a new area, we’ll load some new stuff.
And then there’s Jspm which is a little bit broader in scope. Jspm says ‘there’s a new world where people are going to be writing JavaScript code using ES 6 syntax and they might also want some code that uses AMD syntax or CommonJS syntax – doesn’t matter. We’re going to assume that you're a developer who wants to sit down; you want to install some stuff like Angular 2 so we’re going to have some packet management features to get things onto the file system.
And going back to the other tools like Webpack and Browserify, they don’t deal with that. They just say, “There’s already package managers out there. Just use Npm, just use Bower. Just use whatever you're happy with.” Jspm’s a little more opinionated because it says ‘we’re going to manage your packages for you’ and then you're going to offer your code. And then if you want, you can just install a shim that we provide called Systemjs into the browser and that will automatically load the bits of code that are needed on demand. Even transpile things on the file if you want.
But we’ll also, by the way, provide the ability to bundle things up for you similar to what Webpack does. So you can tell Jspm ‘here’s the entry point for my application; please take the following modules and put them all into a single file for me to deliver it down to the client. And you can split pieces off so you can load again just the sell – enough to get the shell page up and running and then add additional features and pass a JavaScript code that are loaded up later on.
JOHN:
If I get you right, you classify these as basically – Browserify is one option which is the cannonical, more classic way at this point of loading Node modules. I think the two more, I’d say, modern, more recent ones that have been getting strong and growing in popularity more get Webpack technique.
And then the third one would be the Jspm/Systemjs technique, right?
SCOTT:
I would say that’s correct. Those are definitely the newer tools and a little more modern and forward looking.
JOHN:
What I’m seeing is the trend moving towards those two tools. But to be very honest, I think most developers working in the States right now aren’t concerned in any of these yet, and I think they should be because this is where you're heading; you're going to need one of these things to build your modules on your [inaudible] ES 6 or TypeScript; you need something. You can get these kind of things to work with the modules system.
In Angular 1, they didn’t have this [inaudible] modular system for example. But when we go to, what I’ve been seeing very disturbingly is when we’re using Webpack core using these Systemjs/Jspm combo, the configuration of both of these becomes beastly very quickly. Have you seen that, too?
SCOTT:
Yes. I think there’s some developers out there that don’t have any tooling for JavaScript at all and that is going to have to change pretty quickly. And then there’s other developers that have minimal sets of tooling but haent looked at some things like Webpack and Jspm and I think that has to change, too, if we’re going to be building with modern frameworks that are coming out this year and next year and so forth.
CHUCK:
One thing that I’m seeing here – I’ve used Bower and then I used – I’m trying to remember the different systems that I have used for module management. And I’ve never been a fan of the systems that are kind of the all-in-one systems. And I don’t see any of these are necessarily cohesive enough to necessarily justify doing all three jobs.
JOHN:
So let me tell you what I’ve been doing lately on this, and I’m not sure I’ve – I have to be honest here; I had not signified on which way I want to move towards. But today, right now, the path that I’m choosing for Angular 2 or what-not is – I still use MPM before I got introduced [inaudible] and I get those on my machine. I use MPM for Angular – for everything. And then I use Systemjs as my module loader just Systemjs on its own to get my modules into the application. And I’m feeling that helped trying to figure out what I like, whether it’s [inaudible] – how is it going for me? And I’m liking that a lot because if that means a good point where I can make the configuration almost that simple.
The next step would be pulling in Jspm so I can get that bundling aspect for larger apps so that would be that stack. But I’m also very interested in saying, “Okay, another way though is to [inaudible] Systemjs is to just use Webpack to [inaudible] your loading and then use a [inaudible] as well.
And seeing that side by side is very illuminating as far as –. The two things I live for, besides ‘it doesn’t work’ is ‘it does work’ is, what’s the performance of both of them side by side? And I don’t have a good sense that yet.
And the other side of that is, what’s the maintenance aspect? The maintenance aspect – what’s concerning me when I use Webpack amazingly getting into the hundred or 200 module configuration.
CHUCK:
Yeah, I’ve used Bower and Webpack and I’ve liked that combination. I’m not completely sold on Webpack and it’s probably just because I don’t know all of the features yet but I do like the fact that you can specify targets and tell it to watch your files. It doesn’t work perfectly but it works good enough most of the time.
SCOTT:
Yeah, that’s a different aspect of these tools where things like Webpack have additional features that you might use in development. So we’ve been talking about learning modules and bundling things which is what you’ve been thinking of to deliver the working application, but then Webpack includes things like file watchers and all sorts of extensibility points and plug-ins to do different tasks that you may need.
Jspm also – Jspm’s a little bit different I’d say. Actually, Jspm is really oriented towards making for an easy development work flow. So what you could do with Jspm is you could just Jspm and solve a few things, add the configuration file of it, Jspm generates it for you into the browser along with the Systemjs reference. And you can just start working in a browser and refreshing the browser and writing code in ES 6 and you never have to worry about watching files or building JavaScript or anything like that. For some people who are just trying to get up and started with a prototype, to waive it like they would do five years ago where you just start writing some code and refreshing the browser, Jspm provides that experience.
I think Webpack is a little more oriented towards – yes, it will give you the development experience but we’re really focused on – you have to ship an application so we’re just going to assume that you will always do some sort of bundle up things, thus the name Webpack. We’re going to package things up for you where Jspm just have a slightly different philosophy. I think it focuses more on ‘here’s the one tool you need to do everything and development with this tool can be very simple’ but you can also do bundling if you want.
JOHN:
I’ve heard a few things; I don’t know this for a fact but I’ve heard that the design and how they work – that Webpack is not following where the module specs are learning towards. [Inaudible] module specs are not ramified with [inaudible] but that Systemjs is kind of moving in that direction.
I don’t have any concrete [inaudible] to back it up but I’m curious – have you heard as far as –. We all know that [inaudible] is what they're calling it is moving towards hopefully having some kind of a module spec.
SCOTT:
Yes.
JOHN:
So that’s not solidified yet but that means that [inaudible] versus Systemjs aligning that, or do we not know?
SCOTT:
Systemjs is definitely trying to align with that specification and be line for line with the specifications that should be there. So this field should be there and this method should be there for dynamic imports and all of that. And I don’t think Webpack follows that as closely. In fact, I don’t think it does now.
JOHN:
Well, here’s another question – do we care? [Laughter] If there is no spec yet, it doesn’t matter.
SCOTT: no.
CHUCK:
Well, the other thing is is that if I’m using Webpack at this point for all of my build processes, I don’t know that it really is hurting me. I get the output file that I want and I serve it statically anyway.
SCOTT:
Right. From that perspective, you may not care exactly what Webpack is doing. It’s magic but it works.
JOHN:
Yeah, I think as long as you got something that works and most people are just carried at works, it’s performing and it’s consistent and it’s easy to maintain. If you feel you’ve got that, I don’t think any of these options are bad anyway.
SCOTT:
No, but I do think people find them scary and the maintenance aspect is certainly one of them and I know it’s Jspm. I’ve run into issues where upgrading to a new version of Jspm and now my configuration files are broke or I’m trying to do something that’s just a little bit different than what everyone else does with Jspm or change some pass around, and now I have to fiddle around with the API so that modules are loading from the correct place or are being bundled from the correct place.
I think there is some complexity that is added when you introduce these tools to the development cycle and to producing your code.
JOHN:
I think it’s pretty cool. So I had an experience recently and I was using Systemjs and I found a few things that it was lacking where I needed. And my first experience with that, there was [inaudible] issues just right where I need it and I want that. And I woke up five hours later and it was fixed, and I was really thoroughly impressed. The guy who runs Systemjs is Guy Bedford; I don’t know if this is a common incident or not but an award is to make this one too because I reported the bug, it’s driving me nuts and then suddenly the [inaudible] was just there. It was pretty awesome.
So to me, I like that this community, it seems that both Webpack and Systemjs are [inaudible] GitHub issues. They're both very responsive because we’ve all, too often, bet on something that has disappeared or just stopped to maintain. I think you want to make sure whatever you're picking because you can’t even do any of it without something that’ll work your modules.
SCOTT:
I have also seen Guy Bedford to be very responsive. I’ve seen people open issues in the Gitter chat room and the next day they are fixed.
JOHN:
I think that’s a good sign because it’s fine. We had a show recently on Angular 2 and how [inaudible] it was and my first problem I had wasn’t Angular 2. My first switch with Angular 2 is I couldn’t even get the Angular 2 [inaudible] so I figured out how do I load these modules?
CHUCK:
Hm.
JOHN:
And going through similar things with [inaudible] with – sometimes, they create new changes and just try to get Systemjs and Webpack separately to work with Angular 2 was frustrating to say the least; they have a breaking edge. And then finally once I got [inaudible] I had a lot of fun playing with Angular 2 but it’s unlike the ES 5 world. This is mind–pressuring; you can’t just take Angular 2 work to [inaudible] our frameworks and run them on how much you have the understanding of the base module. [Crosstalk]
WADE:
Yeah, that’s a real shift – I think that’s – what’s driving somewhere our conversation here is that if we were JavaScript programmers before this era, we create a global namespace and Angular, it creates its own and you just assume that everything was there.
You weren’t loading things. It wasn’t typical to be loading things unless you’ve decided to take on a library like Require. So your basic problem was get the stuff to the machine with some standard package manager and then once you got it there, you were often running and your code was unaware of how any of the material got there. It just was assumed to be in the environment and that made things easy but it didn’t make things dynamic. And now you can’t write in any of these new frameworks – Angular 2 being one of them but that’s the way Aurelia is going and the way Ember is leaning and a bunch of the other frameworks. You can’t go anywhere without having, obviously ECMAScript 2015 – you can’t write anything without thinking about loading modules as part of the application itself and that’s driving this. That’s my sense; is that sound right to people?
SCOTT:
Yeah, two points there. So number one, this is why I think some of these tools are so fantastic. In the old days, we were used to just writing JavaScript into a file and loading it into the browser and everything’s done. And then we realized as we mature a little bit, and I’m talking maybe 2008 or so, that putting all these things just into a JavaScript file where they are in the global scope, maybe that’s not such a good idea.
And so for the last seven or eight years, we’ve introduced all these artificial syntactic complexity into the JavaScript files where you have self-executing anonymous functions and iffy constructs and all the strange syntax surrounding all the code all because JavaScript only has global scope and function scope so we wanted always everything inside of a function.
But it’s so refreshing when you use some sort of module letter is that you can treat a file as a module and then you can go back to writing just plain JavaScript code inside of that file without the weirdness of an iffy. Or finding some global object that’s already defined, like the Angular object or getting a reference to an Angular dot module to put a component inside of it; you can just write the code the way you want, you can import that code into a unit test and test it. You can import that code into another module that registers it with a framework like Angular. That’s why it think these tools are so great.
Now maybe one day, we’ll be back at a point where we don’t need tools; you’ll just be able to author JavaScript files and laying them all out on the file system and the browsers will – all the browsers will understand how to natively load modules, everyone will be running HTTP/2 so everything will be loaded efficiently, but I think that’s a [inaudible]. And really, I don’t think we’ll ever reach that point again; I think from here on out, at least for the perceivable feature, we always claim to have some sort of tooling support to do things like transpolation or to do things like bundle and [inaudible] files because even with the HTTP/2 specification where you can have multiple requests in flight over a single connection, I don’t think it’s necessarily going to solve some of the bottle mix of ‘hey, I got this JavaScript file and then it has three dependencies’ and they go out and grab them and ‘oh, I discovered another ten dependencies’.
There’s always [crosstalk] some sort of bundling.
CHUCK:
Right.
JOHN:
Can we take a moment with HTTP/2 and what that does for people?
SCOTT:
The basic idea is that the people who offer the HTTP/2 specification says, “Oh wow. Look at the web now. You go to a webpage and it needs to include 10, 15, 20 different resources. And the way the browsers have been accomplishing that is by opening up multiple connections to the server and requesting things in parallel. But that causes issues because TCP was always designed with the idea that you need to go to the server and get information, open up one TCP/IP socket and connect to that server and start communicating with what you need.
Unfortunately, when you open up all these parallel connections, like we’re doing today, confuses some of the TCP/IP algorithms and this and that. To make the long story short, what HTTP/2 says is that you can open up a single connection to the web server. And unlike HTTP/1 of today where you have to send off a request and wait for the response, with HTTP/2 you can – it’s fully multiplex and you can just send off as many requests as you want to the web server. You don’t have to wait for a response.
So when a webpage loads and the browser sees that it needs these two images and these CS file and these 10 JavaScript files, it can just have one efficient connection where it says ‘give me this resource, this resource, this resource, this resource’ and the server just starts sending things back as quick as it can – every one efficient connection. And the idea was [crosstalk] everyone who does things like in-lining images concatenating JavaScript files and things like that that maybe it will all go away because we’ll be able to pull multiple resources much more efficiently with HTTP/2. [Crosstalk]
JOHN:
Is it going to work better for us, too or we’ll look inside the profile and the timeline and we see the assets coming down. Because right now we have to look at the profile and timeline [inaudible] you see ‘here’s my eight requests’ and then there seems to be a waiting period of a messy code, for example.
SCOTT:
Right. All of that is supposed to improve at least in theory.
WADE:
Of course, as you put it out earlier, that’s great when you know all of those requests right now and they have no mutual dependencies and they don’t have a particular order in which they have arrived or be played. Then it’s like, “Hey, I know all 30 things I want. Go get them,” which is not the world of the programmer as we’ve been describing it and as you’ve been describing it, in which you don’t – you have to get the first thing in order to know what the next thing is. And then when you get that thing, it’s serial; you can’t do them in parallel and HTTP/2 isn’t going to help us with serial dependencies.
SCOTT:
At least not with what we have today and I know – so what I could see happening is with Jspm and System.js is this notion of a dependency cache – dep cache – where you can essentially describe the relationship between your modules upfront so that when someone comes and asks for the foo module, System.js is smart enough to say, “Oh, if you need foo then you also need A, B, C, D and E, so let me just go grab all five of them.”
But building that dependency cache, that would still require a tool during development or when you're building things for production to put that information together.
WADE:
Yeah, and I think that what you were driving at is that the greatest HTTP/2 will be – we are still going to need the tooling to do that and some things like Jspm and Webpack which try and build up that dependency graph are the part of our on-going future.
SCOTT:
Yeah, I think build tools like this are always going to be there – if for nothing else for that reason. And also, I don’t think transpolation’s going to go away now because as soon as the browsers catch up to this year’s specification, heck, we already have frameworks that are using next year’s specifications because next year’s specification is supported by tools like Babel.
CHUCK:
Yeah. I do want to add on though that I don’t feel like – so ES 6, ES 2015, whatever it is – that’s a huge leap and I don’t think that next years – the years after that, the subsequent years are going to be as large leap.
SCOTT:
True.
CHUCK:
And so the targets for the browsers and the transpilers for future versions of JavaScript aren’t going to be as big either. But I do agree with you that we are still going to need those tools because we’re going to constantly have either Legacy browsers that support the older versions of the ECMAScript. Things are going to be moving ahead and we’re going to be wanting to use a new version; it’s either because the framework support it, certain browsers support it or because it just makes things easier.
SCOTT:
True. And if you walk into the average development shop – I don’t know if that’s the correct term – but the shop where someone has been doing jQuery for a few years and this may be been doing Angular for the last year, too. And you throw all the stuff at them, the new language features, these new tools – you have to do this and that. This module loading stuff, I think it’s just overwhelming to a lot of people. And they're right now turning it off and shutting it down for a little bit.
WADE:
Yeah, but most of the people who are listening to this or has gotten this far in the podcast have decided that they're going to face it [chuckles] otherwise they’d check out. So if they're here and still listening – all three of you out there.
Scott, you seem to have some pretty wide-range experience with these choices and I don’t think we want you to pick a winner, but I do think that it’d be great if you could –. I sounds to me like you're paying attention about Webpack on the one hand and Jspm. Can you leave – unless you think Browserify needs to be part of the conversation – if it boils to those two, how would you put them side by side, not so you have to say this guy wins and that guy doesn’t but that we can understand what making a choice means and what might be involved in making decisions.
SCOTT:
Sure. I think the way I would phrase this is that if I was starting a project today with a team that was going to be a public internet site so it have to be efficient, I would probably choose Webpack as my tool and have it do all the bundling and all the great things that Webpack could do.
On the other hand, if I was starting a project tonight just trying to prototype something or explore some features, I would probably use Jspm because it’s the one tool where I can Jspm install this and Jspm install that and just load a couple scripts in the browser and everything is taken care of for me. I don’t have to write a new grunt file or anything – [inaudible] file; it just all happens.
WADE:
Yeah. So now – I’m imagining a developer listening to this and saying, “You know, I’m an enterprise developer and I’m thinking about building this but I don’t– Jspm’s going to paint me into a corner,” well that just decided it for me because Jspm is just for ‘Hello World’. Is that really what you're saying or are you saying Jspm will get me – will paint me into a corner that I can’t get out of? Or what’s – why would I start with the Webpack today or why should I be afraid of Jspm tomorrow?
CHUCK:
Mom, Ward’s being mean again! [Laughter]
SCOTT:
I would put it like this. I think the tools have different philosophies. I think Webpack is geared towards ‘let’s bundle up your code and make it efficient and get it into the browser’. Jspm – I believe its philosophy is on a much wider development experience that includes not only a package management but also the module loading and the bundling. So you absolutely could shift an application production that’s using Jspm to bundle up all the files for you. And the end result at the end of the day, both these tools have a lot of overlap.
Webpack doesn’t do package management; it assumes you're going to be using something like Npm or Bower. But if you throw Npm and Bower into the mix, both these tools, they have a lot of feature overlap, they can do a lot of the same things. They can both bundle, they can both support plugins so you can include transpilers like Babel so you can include other loaders like you want to be able to bundle CSS together as part of the module and make sure it gets into the browser.
They all do the same things; t’s just hard to choose because the differences are subtle. And to me the differences are Webpack, I consider, is a serious tool that’s very oriented toward packaging things, whereas Jspm again is a much broader development experience and wants to be your package manager and your bundler and your module loader, and support your transpiler of choice.
WADE:
Alright, so what I’m hearing is if your inclination is to be, at all times, as close to production ready as possible, you’ll need Webpack. Like you want to be able to practice right almost from the get go, what it would mean to get your application into production and you want all your ducks in a row, and you want to know that those ducks are in a row and will work. Whereas with Jspm I might be saying, “You know, I put a premium on quick and easy to get going here and if I suffer later to get it production ready, that’s a trade-off I’m willing to make.”
SCOTT:
I think that’s somewhat fair.
JOHN:
That’s pretty interesting. I’ve had – I found that I haven’t a whole lot of difference in [inaudible] and what each of those will give me, meaning pretty much everything I’ve looked for from Systemjs/Jspm combo. There’s another way to do that in Webpack and vice versa.
The biggest difference I’ve found between them is the configuration and it’s a mental hurdle for me. I don’t feel comfortable in either one of them quite frankly; it’s just a lot of config to set up. And yes, once it works it works but people are like ‘yay, configuring once it works you got it’ but what happens when it doesn’t work? Then you have to figure out how to modify that configuration. That’s sometimes a problem; you have to understand how it works to go there. But I think the biggest problem is for both of them, honestly, is that for many people say, “Hey, the thing I learned about Systemjs and Jspm or Webpack isworking toward here is that I can just plug them in and then I [inaudible] the browser transpiler within [inaudible],” and that scares me because I don’t think any production app could ever want to be here. Why would you want the browser to transpile thousands of files in the browser? [Crosstalk]
SCOTT:
Yeah, you definitely wouldn’t. I can write a Hello World application with Jspm that you can watch in the development tools – there’s 15, 20 requests of the server for different JavaScript files. Because as transpiling on the fly and just loading modules willy nilly when it needs to. It’s a nice development experience because I didn’t have to set anything up or do anything with a configuration file. I just Jspm install a few things and started writing code but it’s, like you were saying, it’s certainly not what you would ship as a production application.
JOHN:
Yeah, we’ve been very totally sold with the transpiling browser but I think what you're saying is that while that may be great for a short-term development, you still [inaudible] do this, you so want to use either one off those tools to do transpolation and building on a server, right?
SCOTT:
Right. It goes back to what I was saying earlier for Jspm. I feel like it has a philosophy of, “Let’s make your development workflow easy.” So if I tell you want to start just transpiling things on the fly and having 15, 20, 200 requests to start the homepage, then you could do that with Jspm and then bundle later, but you would definitely want to bundle.
WADE:
Yeah, in case anybody things that that’s okay, in my experience with the smallest apps is that as a developer, particularly because you're cycling through these things, the weight becomes apparent and painful pretty early, is that your experience, too?
SCOTT:
Right. I want to be able to save a JavaScript file, and by the time I really get my focus on the browser, things should be pretty much pre-loaded for me, right? And if we’re loading lots of little files everytime that I save a file and reloading that page and it takes a couple of seconds, that definitely feels like a hindrance to the flow.
WADE:
Yeah, and that does happen to you with the Jspm and Systemjs and very quickly; at least I found that to be true. Is that your – and that’s – you're saying, yes, that’s true for you, too.
SCOTT:
I’m saying yes. I’m saying – like using the Aurelia framework, you can use the Aurelia framework with Jspm and not transpile anything upfront; just do it all on the browser, but it takes some time. As we null a little request and all the transpolation, you're waiting a noticeable amount of time for the browser to get up and running.
JOHN:
So when you hit that wall, it is quick to fix to get yourself out of that and still stay in the Jspm world or have I driven off a cliff and I might as well start it with Webpack anyway?
SCOTT:
No, it’s pretty easy. With Jspm actually, it’s pretty interesting. What you can do is that you can tell Jspm that you want to bundle and you want to bundle starting with this file or bundle modules A, B and C and it will create – not only create the bundle file for you, but it will modify, if you want, it will also modify the runtime configuration so you actually don’t have to change your webpage at all.
This is actually something that I like about Jspm – I just thought of two things. One, it only works in Webpack and this feature only works in Jspm but let me tell you about the Jspm thing. So during that situation, things are going a little bit too slow. Now you tell Jspm ‘hey, I want to bundle everything and inject the situation for this bundle’. And what Jspm will do is change your configuration so that in your html pages, you don’t have to change any script tags, you don’t have to change anything.
Now, when your page goes off in requests, let’s say, the boot-strapping module, Jspm has configured Systemjs so that Systemjs says ‘oh, the bootstrapper module? That’s in this bundle file so I’m just going to load this one file which brings in 50 other modules’ and now everything’s in the browser. And at some point in the future, then it’s also very easy to tell Jspm that you want to unbundle or remove that piece of configuration about the bundle files. If you want to go back to individual files for some reason, maybe debugging or something like that. Or later if you want to split that one big bundle into a little bundle and a larger bundle and load the little bundle just on the shell page, again that’s something that Jspm can do and it modifies your scary configuration file for you to do that.
WADE:
Cool. I hope you got a blog post on this?
SCOTT:
I don’t. I should. The thing I thought about with Webpack is – and I haven’t tried this feature yet – but I’m pretty sure that I’ve read that it can do a hot reload of these specific script when we’re using Webpack also as the development server so you see the JavaScript file. And instead of reloading the page and reloading all the JavaScript, it can just take that hunk of code and pack it in to the application and now you click a menu item again and it keys differently. [Crosstalk]
JOHN:
I think I would call that hot loading; I kind of think of it as a great erase, right? You're hot swapping a [inaudible], you're prize as you go on the fly.
SCOTT:
Yup.
JOHN:
My own experience has been with Jspm, Systemjs is that I first started working at Angular 2 – it seem like every example; this is months ago – every example was using Systemjs and Jspm such that its module loading and transpiling the browser. And then I found that quickly that the config file was just pretty big for it. As soon as I ripped all that out and said, “I don’t want to do it in browser; I want to start by – I want to [inaudible] the server, I want to transpile that text script to ES file in the server.” I’ll do all that there.
I actually got a smaller configuration because now they actually didn’t have to be concerned with dealing with all that stuff and browser. Not only did it go faster in my own experience but it was actually less config for me to manage. The only additional thing that I had to do is install text script and run GSC, the [inaudible] or use WebStorm and have it do it for me.
So to me that was the way my development experience started like lately and I’m living for that from Webpack, too. I’m about to try [inaudible]. I haven’t tried too much Webpack lately, but I’m about to jump back into that and see how does that –.
WADE:
Yeah.
CHUCK:
That actually brings me into another question that I had and that was how complete are the plugin ecosystems for these where they're compiling assets or building JavaScript files or maybe doing uglifying in one way or another. Do they have options for all of those different things? So for TypeScript or Dart or ES 5 – I just started working on an app that it has imported code in ES 5 and then it has custom written code in ES 6. And so I wanted to build out the ES 6 and then I wanted to build up the ES – compile everything into what the browser will run. Do they have plugins for all that stuff?
SCOTT:
Yes. The amazing thing about these tools is that if there’s something you can think of that you want them to do, chances are some of those are already written in the plugin to do that. So whether it’s TypeScript or ES 6 or – does it support this file over here that was written in cont with CommonJS and also this file over here that was written with ES 6 modules – all those stuff just does everything.
JOHN:
And Charles, I used to use gulp, too, with Systemjs. While the [inaudible] for some of these things, you can still use – go over grunt if you want with either one of those. And I’ve seen several examples of what I can [inaudible] with Jspm, Systemjs where it’s so easy to plugin. People are still driving the workflow with gulp and grunt and just having a cold Webpack or having a cold Jspm to do the bundling at a certain stage.
So it’s not about either one of these – I did not feel like either one of them locks me to a corner when I was dealing with them.
CHUCK:
Yeah, but that’s the way we used to do things, John. [Chuckles]
JOHN:
Yah, like five minutes ago.
CHUCK:
I know right! [Chuckles]
WADE:
So Scott, one of the things that I experienced or then heard charged about Webpack is that you – when you set it in motion, it spits out an enormous amount of stuff that’s hard to fathom. Is that an experience that resonates with you or do you think that that’s overblown or do you think it could be tainted in some way, or is it something that’s just not true? What’s your reaction?
SCOTT:
If you're talking about what the output of Webpack is, yes, the code looks messy; it’s not something that you want to step through or look at.
CHUCK:
Yeah, but it doesn’t generate site maps and stuff that your dev tools can then pick through and put you in the right place, mostly?
SCOTT:
Yes. Source maps work.
CHUCK:
The source maps does site maps?
SCOTT:
Yup. And Jspm, for the same thing; there has been a couple of times with Jspm and System.js where I’ve been trying to figure out what’s happening either because of a problem or just trying to figure out for curiosity’s sake and stepping through that code, also not very fun but that seems to be the world we live in now.
JOHN:
Yeah, I think a misstep at one point with Systemjs and Jspm were brutally on – and I don’t think it’s basic but brutally on something, and all of a sudden it was literally loading about 10 megafiles. I don’t know what I did but I just suddenly [inaudible] and I managed to get myself out of it.
I don’t think it’s easy with any of these tools that end up [inaudible].
WADE:
So what’s it like to configure though? I have very limited experience with Jspm and really with Systemjs and my configuration effort seems rather small and relatively easy to understand. I’m talking about 10, 15 lines maybe, and it looks very – I can manage it and I can see what’s going on in a glance.
What I hear about Webpack is there’s no such thing as 10 or 15 lines; there’s only hundreds. Have I heared wrong or are you going to tell me that you get used to it or are you going to tell me that there’s a specific tool that makes it easier to work with – what are you going to tell me?
SCOTT:
My perspective is that with Webpack – one thing you’ll see with Webpack is that people will write large configuration files because they use Webpack for everything. They even use Webpack as their development server so that spends up a process and surgery html and everything. And that’swhen you can get into a larger configuration file. There’s lots of things that I think are quite ugly about a Webpack configuration file. It’s more on the declarative grunt style than – well, that’s what I would compare it to. It’s very declarative style of ‘here’s this loader and this is the configuration for it and here’s a regular expression to test whether this is where there – when you want to use this loader’ and it goes on and on and on.
Now to be fair, the Jspm configuration file can be large and ugly but for the most part, I never looked in the Jspm configuration file. It’s just managed for me by Jspm, and if there’s anything that I need to change about the configuration, I’ll create a second file with four or five lines of code and just load that after Jspm’s configuration file, so it overrides what’s inside of Jspm.
But this is where the two tools are a little bit different where with Jspm you're not going to be using it as a development serve, so you're not going to have that configuration in there. It’s really just about managing modules.
JOHN:
They’ve got a [inaudible] aspect to learning Angular 1 applications. Where would you point them towards?
SCOTT:
Well I think they both have great homepages which we’ll list in the show notes. What really hooked me on Jspm that goes back to this philosophy of Jspm tries to make for an easy development work flow, there should be a video install on the Jspm homepage that shows a presentation where guys using Jspm just says, “You know, I want to Jspm install such and such a thing and let’s use it in a page. Wow, now I’m going to write some ES 6 code to import that thing and look, it just all works and I haven’t done any configuration or haven’t written any gulp files or I don’t have a build.” I think that’s – will give you the essence of what Jspm is about. And I’m pretty sure Webpack has the same thing. It has a link to a couple of videos from the hub page and some tutorials that will walk you through using Webpack where you can create an html file, create a JavaScript file that’s using an ES 6 syntax and create a CSS file, and Webpack puts them all together and come serve them up to you.
JOHN:
Do you still think that either one of these bundle themselves better or worse [inaudible].
SCOTT:
Interesting question. I don’t think so. The recurring theme throughout the show has been both these tools have a lot of the same features and there’s really no huge differentiator. I think either one will be fine with Angular 2.
CHUCK:
You seem to reason why Angular 2 might – because I heard rumors for a while that they were going to actually adopt Jspm and Systemjs. And then I heard that they were going to recommend it, not necessarily full on adopt it. And now I’m hearing that they’re just saying, yeah, use whatever works. Would there be an advantage to them saying ‘this one works well; use it’?
SCOTT:
Well I think that for a lot of people building frameworks, they always want you to be able to get started with that framework very easy. And I think that it is, again, an advantage of Jspm because it gives you both a package manager and something that you don’t have to write any configuration for because it will manage your configuration. And so out of the box if you just tell people, “Look, you have Node installed, Npm install this tool and then Jspm, and now use Jspm to install Angular and start running a webpage. I think that would be the advantage that Jspm offers.
WADE:
You’re pretty close to the Aurelia approach. Are they taking that attack as well in terms of trying to get – build a community that feels comfortable? Or are they using something else or are they totally agnostic?
SCOTT:
Wrong of the Aurelia team has always been a fan of Jspm, has used it pretty much since the beginning of the public release as the way to work with the Aurelia framework. That doesn’t mean that Aurelia requires Jspm; you can use whatever you like but all of the documentation, all the samples are showing you how to use Jspm to get an Aurrelia application up and running. And is it trying to build a community around that? Not necessarily. I think Aurelia will tell you to use whatever works for you. But certainly, they’ve been trying to have people adopt Jspm. There’s always resistance to these tools and complexities that they have.
WADE:
Yeah, I wasn’t thinking in terms of how it would shackle you to something. I was just wondering whether that was a position – every framework has to figure out what to teach as they’re trying and get people to come to them, say ‘come, come, come use us’. And you try not to confuse the audience that you're trying to retract. And I was just wondering whether – you have experience with a wide array of frameworks and I wonder if you felt that these frameworks were lining up behind something as the easiest pathway to their door. And Aurelia has decided that Jspm is the easiest pathway to their door. I don’t know where Angular 2 is coming down on that but it looks like the same thing. I don’t know about other frameworks; do you know?
SCOTT:
Yeah, I don’t know of the other frameworks. I tend to think the React framework and the people in that community tend to favor Webpack, but that’s my perception anyway.
WADE:
Yeah, I had that perception, too, and I don’t where Ember’s coming down. So it’s interesting, and so much of what people end up with is what they first learn that’s why they give – why the different computer vendors hand out different computers at high school kids and grade school kids, right? So that they can get them hooked. [Chuckles]
But what’s encouraging though from your part is that you're feeling that you really can’t go wrong here in making what choice between one or the other. You're feeling is you can’t go wrong.
SCOTT:
I don’t think so. I don’t think that you would put yourself in a position where you're application’s going to fail because you chose Jspm versus Webpack. I don’t see how that could happen.
WADE:
Good, I have all my own reasons to fail them. [Laughter]
JOHN:
I think conversely whether you picked Webpack and you want to switch to Npm, I don’t think you would take a lot of effort to go from one to the other either. [Crosstalk]
SCOTT:
No, I don’t think so.
CHUCK:
Yeah.
SCOTT:
I think it would be relatively easy to swap out. I think this is one of the situations where in the end, for large applications, this is such a small piece of putting that application together; kind of like people argue over grunt and gulp. I don’t care; it’s something hopefully that we’ll spend a little bit of time offering upfront and then we tweak it as we go along but it’s not really where we invest in a lot of time. It’s just infrastructure that is going to work for us and writing the application is really what it’s about.
JOHN:
You’re not changing – either one of these change the ways of code. If you're still coding as if you're using modules, so what are you using again with Webpack should be [inaudible].
SCOTT:
Right.
WADE:
That certainly sounds like the way it should be, but it is sell to me often that – it’s like going up to a house. I’m sure there’s a great, wonderful house behind that front door, but I can’t find the darn handle; I can’t find the door knob and I can’t get in. and that’s what these things that shouldn’t be in our way, they’ve been very much in the way of my getting a taste of some of these new opportunities, whatever might be behind that golden door, I can’t find the door knob. So I hope this clears up what you’re suggesting now, and this is a rarity for our show, which is that it’s actually going to be okay no matter which way you go, which door knob you install. [Laughter]
CHUCK:
So I have one more question and that is, let’s say that another package manager/module loader comes in – comes along – we see this all the time, right, where there’s some new, hot framework and everybody’s like, “Ohhh! You got to be – you got to have that!” How would you evaluate that to say whether it’s better, worse or the same as Jspm or Webpack?
SCOTT:
I would probably look at it from two different angles. The first angle would be in production, does it produce code that is significantly faster or significantly slower than the tool I’m using today? That will be one way to look at it. The second way to look at it would be, does it have an impact on my development workflow? Does it require me to write more configuration or less configuration? Make sure it supports the transpilers I need whether it’s TypeScript or Babel or what have you. But I can’t imagine another one come along and not have all the same plugins and extensibility points.
CHUCK:
And I guess [inaudible] than is is, is there a feature that you wish these had that would impact one of those two things?
SCOTT:
Well, as far as Webpack goes, I wish there was a way to use it with a little less configuration. Like John pointed out, the configuration files can be a little bit long depending on what you do with Webpack but they can also be difficult to read, I think. So I wish that was a little bit different.
Jspm – some of my biggest problems have been with, as a package manager, sometimes things get cached or sometimes things don’t get placed on the right place in the file system. I don’t know what goes wrong but I occasionally have that experience where I just waive out my Jspm packages folder and reinstall everything from scratch, get things working again. Maybe if there was a way for Jspm to diagnose some of these issues and give me some clear air messages on why something couldn’t be found or is not loading or versions aren’t resolving properly.
JOHN:
Why is Npm – I don’t really want to do the Npm, Bower [inaudible]. I actually was one who uses Systemjs module than I use Jspm for the bundling. Getting the packages quite frankly, I’ve been happy with Npm; I don’t necessarily need to get another [inaudible] so if I had a wish, I think Jspm should just forget about that part and I’ll delete the module loading and I’ll be with [inaudible].
SCOTT:
Yeah, that’s true. I guess to Jspm because it is managing the configuration of where things live for you, where different modules are. It has to tape in to that pipeline somehow, and typically when you install something with Jspm, it’s just going to and the Npm repository and grabbing bits for you.
But maybe there’s a way for you to figure these things out.
WADE:
To be honest, I’m blowing my Node modules folder repeatedly anyway because just –.
SCOTT:
Yes.
WADE:
Things go wrong right there. I was like, “Ack!!” Clear the decks, reinstall, see what happens. [Crosstalk] But that we could do – [crosstalk].
JOHN:
I’ve got to remember that on speed dial.
WADE:
Yeah, exactly. We could do a whole show on how things go wrong with packages and versions. [Chuckles]
SCOTT:
Oh boy.
WADE:
Because it’s just nothing but hell.
SCOTT:
It is.
WADE:
What a bright note. What a bright note to end the show.
SCOTT:
Yes, thanks for it.
WADE:
Let’s have picks. [Laughter]
CHUCK:
Woohoo! Alright, John, do you have some picks for us?
JOHN:
I’m going to say it’s up, it would be six. I think this show assumes that [inaudible] and package tools, packages or module loaders which assumes you're doing ES 6 or TypeScript and possibly doing Angular, too. So there are a lot of assumptions we’re making here.
My big pick in this one would be I think when you're going to do with JavaScript next year, you need to learn more about these things. You need to learn how modulars work and [inaudible] with ES 6 or TypeScript and [inaudible] because these things are not going away. This is where it’s all heading.
CHUCK:
Awesome. Ward, what are your picks?
WADE:
I’m sorry. I should have picks but I don’t, so on to the next person.
JOHN:
Can I pick a classic pick? I want to thank Ward for it. [Laughter]
WADE:
I usually pick Lance John, so that’s really nice.
JOHN:
You’re going to be on my teamwork. [Laughter]
CHUCK:
there you go. Really quick, I’ve got a couple of picks. I did pick this on other shows this week and I know that that drives some people crazy, but too bad I guess. My wife and I, we cut the cord to the TV and we’ve been using Netflix and Hulu and Amazon to get our shows and stuff. And my wife was lamenting the fact that not all of the shows that she likes to watch every week are on Hulu Plus or these other systems at least not right away. And she didn’t really like watching them on her computer and they don’t always work on her iPad. And so I started looking around to try and figure out what can I do to set up an antenna. And so I started out and I ordered one off of Amazon and we hooked it up and we got four channels, too, which were in Spanish and two which were other stuff.
My sister in law lives or used to live a mile from here, and she could get 20 or 30 channels on her antenna. So we went and got an antenna that’s had a better range on it – same problem. So then, I
went online and looked around and it turned out that a bunch of the websites said that we could only get those couple of channels, but it also seemed like some of the neighbors have antennas up and they were getting all of the channels. So I finally found a website that’s called tvfool.com and you can actually search your area. So if the smaller antennas aren’t working for you, you can’t figure out what’s available in your area, go there instead of antennaweb.org and it actually listed out all of the TV stations we wanted and showed that we could get them but we had to get a high powered directional antenna and pointed at the transmitter because we are just behind the part of the mountain that the transmitter sits on.
So we didn’t have a direct line of site; we had a kind of direct line of site. We got one of those antennas – works great. Got about 40 channels, called about 20 of those because they were either in Spanish which I don’t speak, or they were shopping channels which I’m not really interested in watching and neither is my wife. But that’s for [inaudible] finds so now we have all of the three letter local stations and a couple of PBS stations for the kids. And so that’s kind of nice, so tvfool.com.
We got the antenna at Lo’s; we just got the $70 jobber but that’s a lot less expensive than TV subscription through dish.
WADE:
Chuck, why didn’t you just go into the closet and take a coat hanger out and shape it to an antenna and stuff it into the back like we used to. It doesn’t work like that?
CHUCK:
It doesn’t work like that if you're not direct line of site. If we were direct line of site, we could have put rabbit ears up and stuff.
SCOTT:
I am reminded by the way of the great Bob and Ray show in which they took a TV antenna and turned it into a coat hanger. [Laughter]
CHUCK:
That’s awesome! Anyway, so that’s my pick. And then, I’ve also been reading the Michael Vey books by Richard Paul Evans. Not super sophisticated books; they are young adult fiction but they're fun reads and they're pretty fast reads. If you have an afternoon free and you want a book, go pick up Michael Vey’s Prisoner of Cell 25. The latest book is Michael Vey’s Storm of Lightning or something like that. And yeah, they're kids with powers which relate to electricity which is kind of fun and interesting. Anyway, those are my picks. Scott, what are your picks?
SCOTT:
I think my pick will actually be an old TV series that I’ve been watching on Amazon because actually I don’t watch a lot of TV. And sometimes when I travel to places, people ask me, “Where are you from?” And I’ll say, “Hagerstown, Maryland,” and they’ll say they have no idea where that is unless they're somewhere in Maryland also. So I’ll say, “Oh, it’s near Baltimore,” and they’ll say, “Baltimore? So you’ve watched The Wire, right?” And I’ve always had to say, “No, I’ve never watched The Wire.” But there’s a reason for that because when I started watching these things now, I tend to binge watch. I started The Wire last week and I just find myself awake at four o’clock in the morning with a full beard and [laughter] everything [inaudible].
I’ve just gotten through ten episodes of it but it’s a really good TV series. I was actually quite amazed at some of the just little subtle things that go on in the background that help the story along.
WADE:
I know exactly what you mean. It’s amazing as the time goes by. I’m trying to catch up on 30 decades of The Price is Right and it’s –.
SCOTT:
But there’s a way that that story relates, it’s because The Wire is set and – it’s actually filmed in Baltimore, Maryland.
WADE:
Indeed.
SCOTT:
And some of the not so nice parts mostly.
CHUCK:
Yeah, and when Ward says 30 decades of The Price is Right, that’s how old Bob Barker was before he retired. [Laughter] Alright, well, thanks for coming Scott! If people want to follow up with what you're working on or get in touch or anything like that, what are the best ways to do that?
SCOTT:
Sure! If you just search for Ode to Code, you should find my website and find me on Twitter and Facebook, and I use that moniker everywhere.
WADE:
It’s been really great having you on Scoot and that was extraordinarily helpful for me in understanding where the state of package managers are today.
CHUCK:
I agree. It was a great episode. [Crosstalk]
SCOTT:
You guys are always fun to talk to.
CHUCK:
Not always. [Crosstalk] Catch me when I just wake up. Alright, well I guess that’s the show!
[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]
[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit cachefly.com to learn more]
[Do you like to join a conversation with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today.]