6 ms·
Life is definitely too short to not be using npm, browserify and React! https://www.npmjs.com/package/browserify https://www.npmjs.com/package/browserify http
by williamcotton 12y ago
Life is definitely too short to not be using npm, browserify and React!
https://www.npmjs.com/package/browserify https://www.npmjs.com/package/browserify
https://www.npmjs.com/package/react https://www.npmjs.com/package/react
And then use just what modules you need. All the functionality of jQuery has already been ported to various modules.
https://www.npmjs.com/package/extend https://www.npmjs.com/package/extend
https://www.npmjs.com/package/promise https://www.npmjs.com/package/promise
https://www.npmjs.com/package/serialize-form https://www.npmjs.com/package/serialize-form
- random28345 12y ago> Life is definitely too short to not be using npm, browserify and React! These are all cool things, but sometimes you want to simply make a web page without setting up node and npm and all that jazz. Think of it this way... jQuery is like getting a subset of the most common functions you get by using in browserify, but without requiring a build step!
- klibertp 12y ago> sometimes you want to simply make a web page without setting up node and npm and all that jazz No, absolutely impossible. That would mean I'd have to actually write JavaScript instead of LiveScript and that would be unbearable... ;) On a more serious note: yes, node is a bit of an overhead. It may be too much for very simple, one-off projects, but it starts making sense as soon as the project becomes even a little bit more complex.
- williamcotton 12y agoThis is about more than just a build process. jQuery's imperative DOM manipulation is a horrible way to manage state compared to React. These tools aren't just "cool things". They were designed to solve really pressing issues related to managing complexity in front-end web applications by eliminating global state in both the DOM or the JS runtime environment. They tend towards a more declarative and functional approach to system design. A build process that integrates with a versioned package manager is fantastic.
- uptownJimmy 12y agoThis reads like a parody.
- williamcotton 12y agoWhy is that?
- Chris_Newton 12y agoYes, 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 agomake 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 agoThe 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.
- ryanSrich 12y agoI really really want to use all of these new tools, and to a certain extent I already do, but they just seem like layers of overhead on top of other layers and by the time you get down to doing what you need to do, jQuery is just much simpler.