5 ms·

The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of

The problems that npm and browserify solve are at the level of builds and package management. You could use any number of trendy frameworks and tools on top of this. Right. But last week it was RequireJS, not Browserify. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. Last week it was Grunt, this week it’s Gulp, and next week who knows? The list goes on, but it always seems to be the same basic argument: for some reason, we are told, we suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project. It’s long past time we stopped accepting that kind of rhetoric as if it’s some unquestionable truth. Ultimately web pages are still primarily made of the HTML, CSS and JavaScript that you serve to browsers. Everything else should have to pay its way, and there are always costs in complexity and maintainability when you introduce any external dependency into your project. Now just to be clear, I am absolutely not saying don’t use good tools. If you are working on a large, complicated project, of course you should be systematic about it and control your dependencies and automate your processes. Even if you’re only working on a small project, low cost tools like jQuery or SASS might more than pull their weight. But it’s important to choose tools that fit the problem and offer a good cost/benefit ratio. Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all. There is no good reason that such projects should give up on a simple, effective tool like jQuery just because you can also solve the same problems now with heavyweight tools like React and Browserify and some combination of NPM-managed packages.

williamcotton 12y ago
We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. But last week it was RequireJS, not Browserify. I used RequireJS for a number of projects before being introduced to browserify and npm. I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript. However, after having my reservations answered by people in the node community and seeing how they were using it and seeing the incredible volume of front-end code that was being published to npm, I came around to it. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Bower really doesn't make any sense to use and seems to be falling completely out of favor. Gem and PIP are not Javascript module repositories so they don't make sense in this conversation. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. I spent a year with Angular and I found it suffered from a good many issues. It is slow. It is bulky. It does too much. React's virtual DOM and expressive JSX are fantastic. It is fast. It works on the front-end and the back-end. Last week it was Grunt, this week it’s Gulp, and next week who knows? I agree with you here. I use Make. It works just fine. Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all. Can you please backup your claims that browserify and npm are an "elaborate build process"?. Like anything there it takes a little time to become familiar with something but it is a very straight forward process that makes development and starting new projects much quicker and easier. Perhaps you just need to work with these tools a bit more so you can understand what they do? I mean, if you're using SASS, you've already got a build process. But I get it. The gulp thing and grunt thing was always totally insane. Here's a little template and a bit of a joke I made a few months ago: https://github.com/williamcotton/makeify https://github.com/williamcotton/makeify It's a build process that uses good ol' Make. I've been using Make for a long time. It works just fine. Lemme just sum up with this: I've been writing web applications since the mid-90s. I started with perl scripts and cgi-bin. I moved on to J2EE and Tomcat. I worked with Rails for years. I've seen Javascript go from a bunch of random functions strewn throughout an HTML file to what it is today. In between I've used Prototype.js, mootools, jQuery, and who even knows what else. The web has been evolving. The power of the Javascript engines in browsers has been evolving. The world is in a constant state of flux and I am ALWAYS looking for better tools. I personally feel that I've been doing this for long enough to recognize what is really an advancement and what is just some flash-in-the-pan idea. I definitely don't need you lecturing me about software tools and pretending like I don't question my process.
- deleted 12y ago
  [deleted]
- Gigablah 12y ago
  Indeed. Just to add on: "We suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project" That's the problem here. You certainly don't need any of them for a toy project. Of course, you don't need a test suite either. Or a build process. Or any kind of automation. But guess what, I incorporate them anyway because I've built up a discipline over the years. I don't feel overwhelmed by all the different libraries and tools out there because I actually take some time on a regular basis to catch up with the state of the art. It's part of the profession. Any profession, really.
- Chris_Newton 12y ago
  I definitely don't need you lecturing me about software tools and pretending like I don't question my process. I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there. If you are interested in one more concrete example of where my opinions come from and why I still hold them, you might like to read a post I made a few months ago[1], in which I described the rather disappointing results of a recent experiment in using a few modern tools. By the way, you and certain other posters here also seem to be assuming I’m the new guy who doesn’t know modern tools or understand the state of the art. I have no interest in getting into anatomical measurement competitions over this — I’d rather debate the merits of an argument objectively — but just so you know, I’ve been building web sites for going on 20 years and software generally for longer than that. I am not cautious about certain modern tools because I don’t know the current state of the art. I’m cautious because I do know the current state of the art, and after considerable research and experimentation, I don’t think it’s healthy. [1] https://news.ycombinator.com/item?id=8228537 https://news.ycombinator.com/item?id=8228537
  - williamcotton 12y ago
kagamine 12y ago
In a project right now that uses grunt, gulp, bower, npm, and angular (w. bootstrap). Just getting up and running to the point where we could actually code took too much brain. Going along nicely now though, at least until something needs styled, then there's all the bootstrap stuff and custom css from the main project bleeding into our plugin :)

williamcotton 12y ago

We could have an actual discussion about the evolution of front-end tools if you could leave some of your hyperbolic rhetoric at the door. But last week it was RequireJS, not Browserify. I used RequireJS for a number of projects before being introduced to browserify and npm. I had reservations at first because I didn't want my front-end code to be reliant on a back-end environment even if the language was Javascript. However, after having my reservations answered by people in the node community and seeing how they were using it and seeing the incredible volume of front-end code that was being published to npm, I came around to it. Today, as well as NPM, we have Bower and gem and pip and however many other package managers. Bower really doesn't make any sense to use and seems to be falling completely out of favor. Gem and PIP are not Javascript module repositories so they don't make sense in this conversation. Last week it was Angular, this week it’s React, and next week maybe it will be Web Components. I spent a year with Angular and I found it suffered from a good many issues. It is slow. It is bulky. It does too much. React's virtual DOM and expressive JSX are fantastic. It is fast. It works on the front-end and the back-end. Last week it was Grunt, this week it’s Gulp, and next week who knows? I agree with you here. I use Make. It works just fine. Most web projects aren’t large and complicated, and many don’t need elaborate build processes and package management schemes at all. Can you please backup your claims that browserify and npm are an "elaborate build process"?. Like anything there it takes a little time to become familiar with something but it is a very straight forward process that makes development and starting new projects much quicker and easier. Perhaps you just need to work with these tools a bit more so you can understand what they do? I mean, if you're using SASS, you've already got a build process. But I get it. The gulp thing and grunt thing was always totally insane. Here's a little template and a bit of a joke I made a few months ago: https://github.com/williamcotton/makeify https://github.com/williamcotton/makeify It's a build process that uses good ol' Make. I've been using Make for a long time. It works just fine. Lemme just sum up with this: I've been writing web applications since the mid-90s. I started with perl scripts and cgi-bin. I moved on to J2EE and Tomcat. I worked with Rails for years. I've seen Javascript go from a bunch of random functions strewn throughout an HTML file to what it is today. In between I've used Prototype.js, mootools, jQuery, and who even knows what else. The web has been evolving. The power of the Javascript engines in browsers has been evolving. The world is in a constant state of flux and I am ALWAYS looking for better tools. I personally feel that I've been doing this for long enough to recognize what is really an advancement and what is just some flash-in-the-pan idea. I definitely don't need you lecturing me about software tools and pretending like I don't question my process.

deleted 12y ago
[deleted]
Gigablah 12y ago
Indeed. Just to add on: "We suddenly need 73 different tools and templates and scaffolds and packages and boilerplates just to start a simple project" That's the problem here. You certainly don't need any of them for a toy project. Of course, you don't need a test suite either. Or a build process. Or any kind of automation. But guess what, I incorporate them anyway because I've built up a discipline over the years. I don't feel overwhelmed by all the different libraries and tools out there because I actually take some time on a regular basis to catch up with the state of the art. It's part of the profession. Any profession, really.
Chris_Newton 12y ago
I definitely don't need you lecturing me about software tools and pretending like I don't question my process. I’m sorry you saw my posts that way. My intent was simply to challenge the specific post to which I responded, where you appeared to be claiming quite clearly but without any particular argument or evidence that projects today should be using Browserify, React and a bunch of NPM modules instead of jQuery. I stand by that challenge and my comments here, but please don’t read more into them than is there. If you are interested in one more concrete example of where my opinions come from and why I still hold them, you might like to read a post I made a few months ago[1], in which I described the rather disappointing results of a recent experiment in using a few modern tools. By the way, you and certain other posters here also seem to be assuming I’m the new guy who doesn’t know modern tools or understand the state of the art. I have no interest in getting into anatomical measurement competitions over this — I’d rather debate the merits of an argument objectively — but just so you know, I’ve been building web sites for going on 20 years and software generally for longer than that. I am not cautious about certain modern tools because I don’t know the current state of the art. I’m cautious because I do know the current state of the art, and after considerable research and experimentation, I don’t think it’s healthy. [1] https://news.ycombinator.com/item?id=8228537 https://news.ycombinator.com/item?id=8228537
- williamcotton 12y ago

kagamine 12y ago

In a project right now that uses grunt, gulp, bower, npm, and angular (w. bootstrap). Just getting up and running to the point where we could actually code took too much brain. Going along nicely now though, at least until something needs styled, then there's all the bootstrap stuff and custom css from the main project bleeding into our plugin :)