6 ms·

I never use Grunt, Browserify or requirejs. I tried but i found it makes everything unnecessary complicated. Nowadays i mostly use a node/express instance and s

I never use Grunt, Browserify or requirejs. I tried but i found it makes everything unnecessary complicated. Nowadays i mostly use a node/express instance and some own modules which concat all my js/coffee files + bower libraries into one on the fly.

antihero 12y ago
So in our app, we have a file per react component, and our stuff is abstracted heavily into layers, so there are hundreds of files. There are also several different entry points, eg for the desktop js, a tiny app that runs embedded on phones. Browserify means that when we bundle each of these apps, it can include only the exact source files that it needs. This would be an absolute nightmare with concat. Furthermore, we also use 6to5 and es6 modules, so whilst we use browserify in our gulp build, if another team used, say AMD, they could pull in our modules easily. I'm interested in using webpack but the docs felt unfinished.
omeid2 12y ago
Gulp[0] is a better grunt alternative for Grunt. It is based on streams and has a very simple API. [0]: http://gulpjs.com http://gulpjs.com
grrowl 12y ago
We're using Webpack, which is similar to Browserify (in the context of this article) but also provides lazy-loading and automatically generated bundles depending on how your code is structured. At the moment, our "app.js" bundle includes the core. As components are requested (in the form of define(['newsfeed'], function(newsfeed) { newsfeed.render(); });), the requested bundle is downloaded and includes all of its dependencies, including pre-compiled SCSS styles in-line and excluding components/libraries used commonly across the application. This happens using static analysis of your code and is fairly transparent to the developer.
smhg 12y ago
In what sense does browserify make things complicated for you? Feel free to explain your express concat process and I'm happy to compare it to browserify.
ep103 12y ago
Node already has most of the features from requires built in, and between that and npm, you don't really have much need for grunt, browserify or require. Those three tools are very useful on other stacks, in order to get a node-like experience, however.
- ossreality 12y ago
  lolwut. Isn't node a requirement for most of those package managers/tools anyway?
STRML 12y ago
It solves a very real code-reuse problem and it's not particularly difficult to use directly from the CLI in a Makefile. If that's not your cup of tea, I have seen several projects move their entire build over to Webpack (which is like Browserify++). I use it to build some of my public projects and it works great. The basics like uglify/concat/md5/copy/tag can always be reimplemented easily in a concise Makefile, but there's really no replacement for how Browserify/Webpack compiles modules. It allows very powerful code reuse and the ability to write entire apps that run both on your server and browser.
jekrb 12y ago
This reads like the "you might not need jquery" of browserify. Sure, you could concat all your files using unix commands and stuff, but does it solve all the problems that browserify solves?
Touche 12y ago
Not sure why you feel this set up is less complicated. Not having to know/care about the order in which files are executed is why module loaders took off.
AgentME 12y ago
Browserify can be as easy as browserify entry.js > bundle.js That's simpler than any decent concat build process I've seen that needed to be able to concat source files from multiple folders and control the order. Browserify gives you a full NPM-compatible CommonJS setup for less effort. (If you want to do stuff with source maps, minification, or automatic rebuilds, there may be a few more steps involved, but they're the same or even simpler steps as you would have to do those same things in a concat setup.)
- Polarity 12y ago
  yea i know but practically it looks different for me. 1.) with tools like browserify i have to look at the folder structure. if i move things around i have to change some paths inside my codebase. or i have to change a map config. with my approach i need two paths. the path to my bower package.json to include all my bower packages and the path to my codebase with two fixed js files. beneath that directory level i can organize stuff how i want and change it every time completely. create folders, move things, rename stuff etc. my script concats always the libs first, then my bootstrap.js, all my app modules and at last a init.js. every project looks the same and works the same. it´s compatible with every big frontend framework and easy to understand. 2.) most bower packages are in js global format. so they just have to be loaded first at runtime and the order of loading things is very clear. 3.) im aware that browserify aims at some problems like lazy loading or reuse stuff in the background/frontend but i am not having to deal with those problems atm. and dont know if i ever have to...
  - whatthemick 12y ago
    "with tools like browserify i have to look at the folder structure" I don't think Browserify cares about your directory structure as long as it can find the entry file it will figure out the rest based on your require calls (and also make sure they are in the right order dependency wise)
lobster_johnson 12y ago
Two words: Source maps. You don't get that with concatenation. As others point out, Browserify is not complicated at all. Moreover, it gives you an actual pipeline process for creating the "bundles" of code. It supports transformations such as brfs and envify, which let you share more code between the client and server. And it's super trivial to set it up so that bundles are served dynamically (via Node) during development, so that you only have to reload the page without running any kind of watch process, but have it generate static, minified versions for production.
percept 12y ago
https://twitter.com/substack/status/337310410657128448 https://twitter.com/substack/status/337310410657128448

antihero 12y ago

So in our app, we have a file per react component, and our stuff is abstracted heavily into layers, so there are hundreds of files. There are also several different entry points, eg for the desktop js, a tiny app that runs embedded on phones. Browserify means that when we bundle each of these apps, it can include only the exact source files that it needs. This would be an absolute nightmare with concat. Furthermore, we also use 6to5 and es6 modules, so whilst we use browserify in our gulp build, if another team used, say AMD, they could pull in our modules easily. I'm interested in using webpack but the docs felt unfinished.

omeid2 12y ago

Gulp[0] is a better grunt alternative for Grunt. It is based on streams and has a very simple API. [0]: http://gulpjs.com http://gulpjs.com

grrowl 12y ago

We're using Webpack, which is similar to Browserify (in the context of this article) but also provides lazy-loading and automatically generated bundles depending on how your code is structured. At the moment, our "app.js" bundle includes the core. As components are requested (in the form of define(['newsfeed'], function(newsfeed) { newsfeed.render(); });), the requested bundle is downloaded and includes all of its dependencies, including pre-compiled SCSS styles in-line and excluding components/libraries used commonly across the application. This happens using static analysis of your code and is fairly transparent to the developer.

smhg 12y ago

In what sense does browserify make things complicated for you? Feel free to explain your express concat process and I'm happy to compare it to browserify.

ep103 12y ago

Node already has most of the features from requires built in, and between that and npm, you don't really have much need for grunt, browserify or require. Those three tools are very useful on other stacks, in order to get a node-like experience, however.

ossreality 12y ago
lolwut. Isn't node a requirement for most of those package managers/tools anyway?

STRML 12y ago

It solves a very real code-reuse problem and it's not particularly difficult to use directly from the CLI in a Makefile. If that's not your cup of tea, I have seen several projects move their entire build over to Webpack (which is like Browserify++). I use it to build some of my public projects and it works great. The basics like uglify/concat/md5/copy/tag can always be reimplemented easily in a concise Makefile, but there's really no replacement for how Browserify/Webpack compiles modules. It allows very powerful code reuse and the ability to write entire apps that run both on your server and browser.

jekrb 12y ago

This reads like the "you might not need jquery" of browserify. Sure, you could concat all your files using unix commands and stuff, but does it solve all the problems that browserify solves?

Touche 12y ago

Not sure why you feel this set up is less complicated. Not having to know/care about the order in which files are executed is why module loaders took off.

AgentME 12y ago

Browserify can be as easy as browserify entry.js > bundle.js That's simpler than any decent concat build process I've seen that needed to be able to concat source files from multiple folders and control the order. Browserify gives you a full NPM-compatible CommonJS setup for less effort. (If you want to do stuff with source maps, minification, or automatic rebuilds, there may be a few more steps involved, but they're the same or even simpler steps as you would have to do those same things in a concat setup.)

Polarity 12y ago
yea i know but practically it looks different for me. 1.) with tools like browserify i have to look at the folder structure. if i move things around i have to change some paths inside my codebase. or i have to change a map config. with my approach i need two paths. the path to my bower package.json to include all my bower packages and the path to my codebase with two fixed js files. beneath that directory level i can organize stuff how i want and change it every time completely. create folders, move things, rename stuff etc. my script concats always the libs first, then my bootstrap.js, all my app modules and at last a init.js. every project looks the same and works the same. it´s compatible with every big frontend framework and easy to understand. 2.) most bower packages are in js global format. so they just have to be loaded first at runtime and the order of loading things is very clear. 3.) im aware that browserify aims at some problems like lazy loading or reuse stuff in the background/frontend but i am not having to deal with those problems atm. and dont know if i ever have to...
- whatthemick 12y ago
  "with tools like browserify i have to look at the folder structure" I don't think Browserify cares about your directory structure as long as it can find the entry file it will figure out the rest based on your require calls (and also make sure they are in the right order dependency wise)

lobster_johnson 12y ago

Two words: Source maps. You don't get that with concatenation. As others point out, Browserify is not complicated at all. Moreover, it gives you an actual pipeline process for creating the "bundles" of code. It supports transformations such as brfs and envify, which let you share more code between the client and server. And it's super trivial to set it up so that bundles are served dynamically (via Node) during development, so that you only have to reload the page without running any kind of watch process, but have it generate static, minified versions for production.

percept 12y ago

https://twitter.com/substack/status/337310410657128448 https://twitter.com/substack/status/337310410657128448