Browserify All the Things

[mikeal]

Browserify event. Maybe just an hour of 10 minute talks followed by hacking and socializing.

[brianleroux]

This! Also: Atomify, Component, and topcoat/resin too. Cc @techwraith On Nov 8, 2013 9:14 PM, "Mikeal Rogers" notifications@github.com wrote:

Browserify event. Maybe just an hour of 10 minute talks followed by hacking and socializing.

— Reply to this email directly or view it on GitHubhttps://github.com/mikeal/jsfest-staff/issues/18 .

[techwraith]

Yes! It would be good to show that npm can handle more than just js.

[mikeal]

JSify

Browserify, Atomify, topcoat and resin?

Component seems a little out of place but maybe I'm wrong.

[rvagg]

dare I suggest Ender / @ded

[mikeal]

does ender pull from npm?

[rockbot]

Yes, ender pulls from npm

On Sunday, November 10, 2013 at 9:55 AM, Mikeal Rogers wrote:

does ender pull from npm?

— Reply to this email directly or view it on GitHub (https://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28155875).

[mikeal]

cool, i haven't used it before. ender would be good.

this event is shaping up, any takers for curating it ;)

[rvagg]

@mikeal perhaps add @ded here? Ender is picking up some new steam at the moment.

Candidates for curators: perhaps @thlorenz or @juliangruber?

[mikeal]

we don't add speakers here, just organizers, once it's announced the CFP's are in a public repository https://github.com/mikeal/jsfest2014-cfp

i was thinking about asking @defunctzombie to curate.

[rvagg]

I was just thinking about @ded being someone who might be able to contribute ideas here; no big deal though.

[mikeal]

sure, maybe he's interested in curating :) @rvagg do you know him well? if so you can go ahead and ask him if he wants to be involved and I'll add him.

[rvagg]

might be best to get someone more heavily involved in the browserify world to curate, that's where most of the action is happening, it'd just be nice to have a bit more coverage of the other operators in this space.

[rockbot]

dunno if you want someone local to SF or not… @iamdustan is in Charlotte, NC and if not a curator would be a really good speaker :)

---

Raquel Vélez @rockbot http://rckbt.me

On Monday, November 11, 2013 at 2:02 PM, Rod Vagg wrote:

might be best to get someone more heavily involved in the browserify world to curate, that's where most of the action is happening, it'd just be nice to have a bit more coverage of the other operators in this space.

— Reply to this email directly or view it on GitHub (https://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28243923).

[techwraith]

@brianleroux what do you think of @dam curating this one? He has a good grasp on all of the different systems for doing modules on the front end. The only downside is that he couldn't speak about Resin.

On Mon, Nov 11, 2013 at 2:24 PM, Raquel Vélez notifications@github.comwrote:

dunno if you want someone local to SF or not… @iamdustan is in Charlotte, NC and if not a curator would be a really good speaker :)

---

Raquel Vélez @rockbot http://rckbt.me

On Monday, November 11, 2013 at 2:02 PM, Rod Vagg wrote:

might be best to get someone more heavily involved in the browserify world to curate, that's where most of the action is happening, it'd just be nice to have a bit more coverage of the other operators in this space.

— Reply to this email directly or view it on GitHub ( https://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28243923).

— Reply to this email directly or view it on GitHubhttps://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28245829 .

[mikeal]

i'm going with @defunctzombie, he wins in published module count :)

[mikeal]

@defunctzombie here you go, everyone has an opinion :) feel free to ignore them, including mine, if you think it'll make a better event.

I'll have a better idea of venues and capacity in the next week or so. For budgeting all I need from you is the travel/accommodation cost of yourself and if you think you'll need to fly in any speakers. This will all factor in to the ticket price and the minimum we need to hit in order for the crowd funding of the event to work out.

[defunctzombie]

Something that might be fun for this one is a roundtable discussion (not long) about the merits of doing client side development using a module system and some gotchas that someone that is use to just pasting script tags might want to consider. This way the various systems mentioned here (resin, ender, etc) can get coverage. My experience is entirely with browserify and making it do lots of different things which many often don't realize it can do.

@rvagg starting with a list of the common "desires" for front end modules might be nice, then building from there about having the various tools talk about how those are solved.

Depending on the type of crowd for this event the session will either need to focus on educating those that don't use any commonjs style system/tool and those that already do and how they can incorporate it into their development and deployment process.

[mikeal]

@defunctzombie feel free to kick up some ideas about format. we've got a wide variety of formats at JSFest so just go with whatever you think this community will benefit from the most and i'll try to find an appropriate venue.

[rvagg]

As much as us Node-types feel a whole lot of "wut?" towards Bower, Yeoman (and for that matter, Grunt), these tools are incredibly popular amongst pure frontenders who seem to have a strong allergy to npm and even commonjs, with a strong preference for AMD (more "wut?"). While I'm generally +1 on bashing AMD and non-npm solutions, this perhaps isn't very inclusive. Maybe pulling in some of the people promoting these things would be worthwhile? Even having a debate format discussing the merits of the solutions would be fantastic.

[techwraith]

At this point are we talking about doing a more generalized "Modular Front End" event?

On Mon, Nov 11, 2013 at 4:15 PM, Rod Vagg notifications@github.com wrote:

As much as us Node-types feel a whole lot of "wut?" towards Bower, Yeoman (and for that matter, Grunt), these tools are incredibly popular amongst pure frontenders who seem to have a strong allergy to npm and even commonjs, with a strong preference for AMD (more "wut?"). While I'm generally +1 on bashing AMD and non-npm solutions, this perhaps isn't very inclusive. Maybe pulling in some of the people promoting these things would be worthwhile? Even having a debate format discussing the merits of the solutions would be fantastic.

— Reply to this email directly or view it on GitHubhttps://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28256994 .

[brianleroux]

Ya I'd love to fix the 'wut' problem of which you speak @rvagg. Problem is none of these solution is a straight mapping (as you know).

For my part, npm all the things. I get that ppl might want dynamic module loading (AMD) or a different package manager that does not tell me how to load my modules (Bower) but I don't think they get why.

On Mon, Nov 11, 2013 at 4:16 PM, Daniel Erickson notifications@github.comwrote:

At this point are we talking about doing a more generalized "Modular Front End" event?

On Mon, Nov 11, 2013 at 4:15 PM, Rod Vagg notifications@github.com wrote:

As much as us Node-types feel a whole lot of "wut?" towards Bower, Yeoman (and for that matter, Grunt), these tools are incredibly popular amongst pure frontenders who seem to have a strong allergy to npm and even commonjs, with a strong preference for AMD (more "wut?"). While I'm generally +1 on bashing AMD and non-npm solutions, this perhaps isn't very inclusive. Maybe pulling in some of the people promoting these things would be worthwhile? Even having a debate format discussing the merits of the solutions would be fantastic.

— Reply to this email directly or view it on GitHub< https://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28256994> .

— Reply to this email directly or view it on GitHubhttps://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28257055 .

[defunctzombie]

@Techwraith might not be a bad idea overall. I know that for many people not indoctrinated into any sort of "good" js development, the idea of structure or modules is still very foreign. It is too easy and natural to fall back to those globals on the window object and just add script tags with jquery plugins since all of that "just works". So I think it is important to talk about modular front end dev and how that helps but then also go into the mad science of some of these tools. My experience has been that many folks that are not doing node.js dev are just not exposed to the dynamically changing ecosystem of plug and play and trying out these new tools simply because what they do now just works making it a hard sell.

[defunctzombie]

@brianleroux I agree with you and think people overengineer many of these solutions without even thinking about the "why". This is why it is important to show things working not just same as they have now, but to show how things are improved (cleaner/more maintanable code, more code reuse, experimentation, etc). Lots of people are perfectly happy with the hand-me-down monolithic client side frameworks so showing how to work with those might also help.

I like to often bring up the example of trying to write python code without an import statement, or the same for ruby to bring home the idea of why structure is important and how tools can help you avoid assembly errors.

Anyhow, I think this is for the day of discussions, first thing to decide is what to cover and format; basically how to spend the time. The speaking will be left to the speakers ;) So lets work on making the agenda knowing we can't talk about everything so suggest wisely!

[techwraith]

Well, if you're looking for suggestions, here's a few that I'd like to hear people talk about:

• Why use a module system on the front end?
• A talk about/from someone who actually uses a system like this on a large app/team
• NPM isn't just for JS or the just the backend
• Publishing/authoring your html/css/js module in a way that can be used in many systems
• Build systems - grunt, browserify, jake, etc.

[mikeal]

@rvagg is that anecdotal or do you have some data? i can tell you that, from the data i've been able to get out of GitHub, the engagement around front-end modules that are in npm is much higher than "node only" or even "node mostly" modules. however highly engaged you think node developers are, triple that, and you have a good idea of what the activity is in npm frontend. BTW, i'm including Grunt in that, Grunt is definitely an npm module :)

[mikeal]

@defunctzombie @brianleroux maybe rename to "ModularJS" ?

[brianleroux]

We could go crazy and get David Herman to talk about ES6 modules while we're at it since it blows most of these monkey patches right out of the water if it ever ships.

On Mon, Nov 11, 2013 at 4:49 PM, Mikeal Rogers notifications@github.comwrote:

@defunctzombie https://github.com/defunctzombie @brianlerouxhttps://github.com/brianlerouxmaybe rename to "ModularJS" ?

— Reply to this email directly or view it on GitHubhttps://github.com/mikeal/jsfest-staff/issues/18#issuecomment-28258593 .

[mikeal]

one thing i'll warn against is having "vs." talks and i would encourage you to fight against your inclinations of inclusion at the cost of your message.

if the message is "go modular" it is severely weakened by pulling people in different directions. even worse, people get the impression that all these solutions are basically fighting with each other and rather than "picking a side" just decide not to engage.

arguments might make good podcasts but they make really negative and tense in-person events. there's a low of low hanging fruit that everyone agrees on and should be propagated to newer developers but we'll never get to it if we're trying to give everyone 10 minutes to push their opinion.

[rockbot]

On that vein, then, I think talks with the title along the lines of "Why we moved from X to Y - AND HOW!" would be particularly useful, especially to the rather beginner-level audience.

[mikeal]

@rockbot "real world" talks are always ideal. it gives people the opportunity to say "This was our problem and this is what we fixed." It sounds similar but is actually the polar opposite of a talk by a library author that is "my library vs. other thing."

[rvagg]

@mikeal purely anecdotal, but the whole reason Bower exists is because of a phobia towards npm amongst certain frontenders even though Bower is basically a reimplementation of some of the basic features of npm. It'd be worth having a chat with Paul Irish and/or Addy Osmani about this if you ever bump in to them in person.

LXJS2013 was instructive as there was a Bower talk surrounded by a couple of other talks that ended up being strongly anti-Bower (most notably @substack's even though it wasn't explicit). It was obvious that the Bower guys are totally oblivious to the alternatives and thriving ecosystem around, and in, npm, and I find this in general when talking to pure frontenders who tend to get pushed towards Yeoman, RequireJS, JAM, etc. etc.

So, I'm not suggesting argument or competition or anything like that, I'm just saying that in the Node world I believe we tend to be a bit blinkered sometimes towards what actually goes on in the pure-frontend world and if you want to run an event that talks about Browserify, and even Ender (which uses npm as a direct dependency to do module installing and dependency resolution and is CommonJS), then you're talking a language that's quite different to what's really going on out there for people that aren't using Node on the back-end.

But then again, I much prefer to think of myself as a backender these days so I might bow out of this discussion and leave you guys to sort this out and I'll get on with my NodeBase craziness.

[mikeal]

i'll pull some data specifically on bower, but the preliminary numbers i have show that Grunt is about twice as popular/engaged but bower is no slouch.

Component is, literally, about 3% as popular in download numbers than bower.

[defunctzombie]

Been quite here for some time. Assuming this is still happening; I have determined the focus should be on educating users on how to transition from script based site development towards modular development. This includes how to build standalone scripts for modules you may find as well as how to build a basic "app" script and browserify that. The focus will be on browserify but we should aim to describe the "act" of taking sets of files linked via commonjs requires and using tools to turn them into the final result and how to use and reason about that resulting js file.

I notice that lots of users get hung up on when to browserify or what it means and how to slowly transition to it.

[mikeal]

This will happen if I find a venue, but at the moment i don't have one :(