4 ms·

Yes, why use a tried and tested tool that can be incorporated into your site and served efficiently with just a single extra line, when instead you could make b

Yes, why use a tried and tested tool that can be incorporated into your site and served efficiently with just a single extra line, when instead you could make building your site more complicated than compiling an entire Linux distribution from source, spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do, and lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives, leaving you with a maintenance headache for as long as your project lasts after that? Doing the simple, effective thing is just crazy talk, I tell you.

williamcotton 12y ago
make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives 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.
- Chris_Newton 12y ago
  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.
- ebiester 12y ago
  So, basically, you end up rewriting the glue code and plumbing, keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it. And that's fine, if writing a framework per project is something you have time for. But make no mistake -- you're writing a framework.
  - williamcotton 12y ago
    you end up rewriting the glue code and plumbing I'm not sure what you mean. Can you give an example? keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it System administrators, developers of pretty much any language, and even chip designers have to deal with the issues related to code that wasn't written in-house. We live in a modular world. But make no mistake -- you're writing a framework. React and the Common JS module system are enough of a framework especially when compared to jQuery. I'm getting the feeling that most people on this forum don't really know nor care how these tools work and are mainly interested in making snarky jabs. Your criticism isn't digging deep enough in to these tools to even make much sense.
- usrusr 12y ago
  > Just search npm and pick the one that is being used the most. This is basically the algorithm for picking jQuery
- NikhilVerma 12y ago
  I don't like how browserify will only ever work by serving combined files. Granted it has source maps but it's still terrible that you just can't debug your app with individual files with it. Neither do I assume setting breakpoints works very well in it?

williamcotton 12y ago

make building your site more complicated than compiling an entire Linux distribution from source http://browserify.org/ http://browserify.org/ Browserify is not at all complicated. spend days choosing between a bunch of almost identical micro-libraries for every little thing you need to do Just search npm and pick the one that is being used the most. lock yourself into a proprietary framework that will be considered legacy code as soon as next week’s trendy framework arrives 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.

Chris_Newton 12y ago
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.
ebiester 12y ago
So, basically, you end up rewriting the glue code and plumbing, keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it. And that's fine, if writing a framework per project is something you have time for. But make no mistake -- you're writing a framework.
- williamcotton 12y ago
  you end up rewriting the glue code and plumbing I'm not sure what you mean. Can you give an example? keeping track of twenty-eight security bulletins instead of one, and hoping that someone doesn't get a zero-day in a less used library that doesn't has much security attention paid to it System administrators, developers of pretty much any language, and even chip designers have to deal with the issues related to code that wasn't written in-house. We live in a modular world. But make no mistake -- you're writing a framework. React and the Common JS module system are enough of a framework especially when compared to jQuery. I'm getting the feeling that most people on this forum don't really know nor care how these tools work and are mainly interested in making snarky jabs. Your criticism isn't digging deep enough in to these tools to even make much sense.
usrusr 12y ago
> Just search npm and pick the one that is being used the most. This is basically the algorithm for picking jQuery
NikhilVerma 12y ago
I don't like how browserify will only ever work by serving combined files. Granted it has source maps but it's still terrible that you just can't debug your app with individual files with it. Neither do I assume setting breakpoints works very well in it?