[Touche]

With Browserify you have extra steps as well. Install browserify. Install a watch thingy (in grunt or gulp or write a shell script or whatever). Remember to run that watch thingy every time you develop.

That's why I prefer client-side loaders. All you have to do is copy the loader into a folder and create a .html file. I have my dev folder hosted by apache so I don't ever have to worry about starting some process, running npm install and watching it install the entire internet, etc.

[cnp]

When people complain about these types of "steps", it makes me wonder if they're not thinking clearly about what these steps actually mean, especially for larger projects or when working on a team where synchronization is absolutely key. These processes are here to help you help yourself.

Steps like these allow you to systematically control every aspect of the development process, and adapt. In the long run, these steps work in your favor.

They also allow you to hook into the more modern aspects of development. I mean, you don't want to type `npm install` --that's fine; what you're essentially saying is that this incredibly useful ecosystem is irrelevant to your needs. I find that very hard to believe.

[Touche]

You misunderstand me. The benefit of a client-side loader is that these things can be added gradually. That doesn't mean you don't use many of the same tools. There's just not that 15 minutes of setting up your project folder, and of course not having to run a watch task every time you develop.

[untog]

Remember to run that watch thingy every time you develop.

Well, that's the beauty of it, for me. I run everything through gulp, so I don't need to remember to run the watch thingy - I type:

    gulp watch

which starts up my dev web server, complete with LiveReload shims enabled. Then when I'm ready to build I do

    gulp dist

and it packages everything up.

[Touche]

I'm confused, you say you don't have to remember and then you say you typed gulp watch. Is the fact that you typed something an indication that you remembered to do so?

I understand that some people like this workflow, what I don't like about it is when I start working on a project I don't want to spend 15 minutes setting up build scripts, downloading the entirety of npm, etc. I just want to start hacking in the browser. Client-side loaders make that really easy, just drop in the .js file and go.

Again, I know some people like that workflow and I'm not saying you're wrong, just pointing out that there is a tradeoff, it's not a clear win by any stretch.

[untog]

I'm confused, you say you don't have to remember and then you say you typed gulp watch.

Well you have to type something in order to start your project unless you like using file:/// URLs. "gulp watch" doesn't just run the watch task - it runs the entire dev environment with watch. How do you run multiple projects with Apache?

And while setting up these modules is a process, I only really have to do it once - I have a template directory I just copy into a new project. Then everything in the src/ directory gets processed accordingly once I type 'gulp watch'.

[Touche]

> Well you have to type something in order to start your project unless you like using file:/// URLs. "gulp watch" doesn't just run the watch task - it runs the entire dev environment with watch. How do you run multiple projects with Apache?

Apache serves everything under ~/dev and that's where I stick new client-side projects.

[untog]

Do you have a build process? I still want to concatenate and minify for production, so I'm using a build task anyway. At that point having everything run in one place is no bad thing. Especially for whoever comes after me.

[Touche]

That really depends. If I'm writing a small module that others will use, there's no reason to build that. Or I might just be experimenting with some new browser API.

It's nice to be able to just start coding without the friction of setting up every project as though it were some large thing that would include production builds, automated tests, and many other developers. Of course you can work on those types of projects with client-side loaders just as easily.

I recommend trying out jspm: http://jspm.io/ It is all about removing the friction that people often have with client-side loaders (I have to maintain another config file, the horror! ;) but is also forward-compatible as it implements the upcoming ES6 module loading stuff. You can use CommonJS, AMD, or ES6, and mix and match the three.

[fourstar]

I see that you are trying to stick to your guns, but it sounds like you never even gave this a try. It's so easy to do, and if you write Sass, LESS, or any other css preprocessor languages, then you're already doing this somehow (and if you don't you're working on tiny projects).

Client side loaders (et al AMD based RequireJS) are dumb. I've been there, done that. I'll minify my js code and then "just drop the .js file" into my page, and let gulp watch for changes.

[Touche]

Client-side loaders support plugins too. Less, Sass, CoffeeScript, ES6, literally anything you want. I don't know why you would accuse me of not giving Browserify a try (I have several projects that use it, but I guess that's not giving it a try) when you didn't even know that client-side loaders support plugins.

Hell, you could even use a client-side loader exactly as you are doing with Browserify/Webpack. Just set up a watch task that builds unminified and there you go! It's just nice that they aren't dependent on a cli process. But unlike you, I'm not trying to convert anyone here, just pointing out that there are advantages to using client-side loaders. For example, it promotes separation of client-side code from server-side code. Using the same package.json file for both promotes bad practices like developing with the server running and writing code that's not easily testable without the server running.

[sanderjd]

Your process also has "extra steps", like installing and configuring apache, installing a loader, and creating an html file for it. There isn't anything that's just free, and different people just understand and prefer different workflows. For instance, I don't use browserify, but its workflow makes a lot of sense and "sounds right" to me, whereas yours sounds really strange.

[Touche]

Installing Apache/Nginx is a 1 time deal. A browserify/webpack workflow requires that you set all of that up for each project, and to start your watch task every time you develop. So if you're working a few different projects you either have to switch between them or start new watch tasks for each. I understand that some people enjoy this workflow and am not saying they are "wrong", just pointing out the added requirements.

[cnp]

Hmmm... I'm sure most people are like me and have their own scaffold set up, and don't rebuild everything from scratch. For every project that I write, I do...

1. git clone https://github.com/WINTR/grunt-frontend-scaffold

2. npm install; and then

3. grunt dev

...which watches everything on localhost:3000, including my unit tests and source code, and reloads on change. Dead simple, fast and consistent stuff and everything I could possibly need set up in less than 1 minute, every time.

Most teams, I imagine, work in a similar way.

Not to mention, if I wanted to pass over the project to another developer, I would just have to tell him to clone the repo and hit `npm install`.

[jessaustin]

Maybe this isn't such a problem, but having a system-wide httpd means that all projects have to be on the same version.

[lobster_johnson]

Use the browserify-middleware package, like so:

    app.use('/js', browserify('./app/js', {
      transform: ['reactify', 'envify'],
      extensions: ['.jsx'],
      cache: app.get('env') !== 'development',
      minify: app.get('env') !== 'development',
      gzip: app.get('env') !== 'development',
      debug: app.get('env') === 'development',
      precompile: ['./app/app.js']
    }));

The server will dynamically bundle the JS for you; all you need is to run the server. In our apps, we do this for development, but in the production environment we do the packaging at deploy time (via Google Closure to minify) to create static files that can be served by Nginx.