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:
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.
"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.
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.
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 don't want to be misinterpreted you might want to limit the amount of sarcasm and hyperbole in your statements and instead focus on clearly defined criticism of these tools.
You can chalk all the issues that you've had to growing pains.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications. These kinds of applications need sane module and build systems. Once you're familiar with these tools they do not get in the way even when building simple weekend projects.
The jQuery way of handling DOM manipulation comes from an era where the majority of HTML was being processed on the back-end and Javascript was used for light-weight modification of state.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
There are a number of declarative front-end frameworks but I feel that React is the clear winner.
One big issue with Angular and Ember is when it comes to rendering HTML on the server. They're also very slow especially on mobile.
Yeah, the last 2 years have been a mess. We're not out of the clear yet. State and identity management is gearing up to have it's foundations rattled to the core by cryptographic systems that introduce PKI. Because React is just a view layer it'll remain agile enough to work with any sort of upside-down state and data management. Clients keep getting more and more power.
Within the node community the foundations for a decentralized package management system are being built. One that will be just as capable of publishing, loading and building modules from WebRTC as it is from a centralized server.
Yeoman, Bower, Gulp or Grunt don't really solve anything that isn't solved better by other tools.
I urge you to take another look at this stuff. I understand your frustrations but the solution should not be to give up and just go back to jQuery.
You can chalk all the issues that you've had to growing pains.
No. I’m sorry, but the issues aren’t that simple and you can’t just hand-wave them away like that.
The discovery and maintenance overheads, when libraries get so fine-grained that you wind up spending a lot of time just trying to find decent ones that will be compatible and then keeping an eye on them for updates or replacing them when they are no longer sufficiently supported, can be substantial. This has been an issue with general software development since forever. I sometimes call it the “max problem”: if you need a function to return the maximum of two values and it isn’t part of your language’s standard library, then it is almost certainly going to be faster to implement the one-liner function again on the spot than to search for an existing implementation, but this can easily lead to duplicated code, which is undesirable. The increasing reliance on powerful package managers in front-end web development is just a symptom of these problems.
The downsides of using a framework, meaning code that controls the overall architecture of your system into which you plug your own code as a subservient part, are also real. I’ve written about these on HN before, too[1]. Given that a lot of frameworks implement some sort of plug-in system to try to give back part of the flexibility they inherently take away, it is common to run into the excessive discovery and maintenance overheads I mentioned before on the same projects.
In the last 5 years the web browser has changed immensely. It is now capable of running incredibly complex applications.
But they aren’t!
Browsers are now capable of running non-trivial UI applications written in JS, and it’s true that those JS code bases are significantly more complicated than what we worked with a few years ago. However, developers have been building substantial front-end UIs using the likes of Flash or Java to overcome the performance and scalability problems with JS for a long time, and even the largest of these front-ends are only medium-sized projects on the scale of “all software”. There are no magic barriers being discovered in the front-end web development world that haven’t long since been encountered and overcome in other parts of the software industry.
In any case, as I said in my previous post, I am absolutely not suggesting that for these larger JS projects you shouldn’t adopt good tools to automate the development process. Of course you should. I’m just saying that most web sites are nowhere near that scale or complexity, and many don’t need to incur the overheads of adding heavyweight tooling, which is the point I originally objected to. Most sites are not SPAs or CMSes that need to scale up to hundreds or thousands of different types of content.
I think it is also worth keeping in mind that quite a few of the problems these heavy tools solve are only problems in the first place because of other poor tools. As Exhibit A, I cite the use of tools like RequireJS or Browserify to do basic modular design, which is necessary only because JS is a terrible language for developing larger projects and lacks even a basic module system of its own. But again, I’m not disputing that for large web apps by today’s standards a systematic module system is useful, I’m just saying you can go a long way with a one-liner to run Uglify and a one-liner to run SASS, and for many projects that sort of level is all they need.
Using jQuery for building complex interactive web applications is a difficult task because state becomes incredibly hard to reason about.
People keep telling me this, but I have never found it so, and among other things I maintain some substantial code that was built that way and has already successfully outlasted plenty of projects written in trendy web frameworks.
Sure, it’s prohibitively difficult to scale up if you start from the premise that you keep your state embedded in the HTML or the current values of form fields. Toy UIs can get away with this, but it quickly becomes impractical and more structure is needed.
Would I choose to use different tools for a similar project today? Yes, absolutely, there are things we implemented manually a few years ago where it does make sense to use a tried and tested library today.
But there has never been any rule that said you have to rely on bad design and keeping state in odd places, with jQuery or any other library. I was writing web front-end code that did things like separating state from presentation, bundling state changes into a single UI update because rerendering was slow, and implementing what we might now call two-way data binding, long before any of these modern JS frameworks existed. I very much doubt I was the only one. We have a lot of web developers today who have done little if any work on software in other contexts, but these ideas are widespread in other software development contexts and they have been for a very long time.
Likewise, every few years, someone comes along and suggests that a more declarative approach to building UIs is the way forward, and yes, it does have some advantages, but it also has disadvantages. For example, as those using Angular and the like have discovered to their cost, a strategy based on declarative templates doesn’t always scale well when the dominant bottleneck happens when you render changes. This was entirely predictable, I’m afraid, and plenty of people were questioning the Angular hype a year or two back and whether projects locked into using Angular would be difficult to maintain later on. That was before we knew about the whole Angular 2 split, of course.
So, the next logical step is something like React, which is essentially reimplementing a substantial chunk of a web browser on its own terms as an optimisation to overcome the performance limitations of today’s actual web browsers. This is certainly an impressive technical achievement, but will React still be as valuable if a couple of years from now Web Components are ubiquitous and browsers have better logic for avoiding expensive reflows in these kinds of applications? Those both seem like reasonable assumptions, give or take the exact timing.
I urge you to take another look at this stuff. I understand your frustrations but the solution should not be to give up and just go back to jQuery.
As I said before, please don’t read things into my posts that aren’t there. For one thing, I do this for a living, and I keep an eye on this stuff all the time. For another, at no point in this discussion have I suggested that we should just stick with jQuery for everything and not use new tools; in fact, I have explicitly stated otherwise more than once. I challenged one specific post you made, which was a general suggestion that projects should be using tools like Browserify, React and a bunch of NPM-managed modules, even if jQuery was perfectly sufficient to do the necessary job.
Anyway, these posts are getting very long now, and I’ve drifted a long way from my original point so I should probably stop here. Thanks for the discussion.
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
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.