From the descriptions of his project, it seems like with every rewrite he focused on some programming paradigm and took it to its logical extreme. But there's a lot of tools in web development,...
Exemplary
From the descriptions of his project, it seems like with every rewrite he focused on some programming paradigm and took it to its logical extreme. But there's a lot of tools in web development, and you should always choose the best tool for the job.
If you need an animation, then absolutely prefer CSS animations before turning to JS. If you need expandos, then summary/details tags are perfect (if you don't mind 88% browser support).
If you need a modal popup however, kludging a giant invisible checkbox may not be the better solution. You're making a lot of assumptions about browser cross-compatibility and rendering. I'd have opted for a more standard JS solution in that case.
I am amazed that even after completely rewriting their browser (EDIT: was referring to IE -> Edge), Microsoft still doesn't support basic UI functionality. I was sad when they announced they were...
If you need an animation, then absolutely prefer CSS animations before turning to JS. If you need expandos, then summary/details tags are perfect (if you don't mind 88% browser support).
I am amazed that even after completely rewriting their browser (EDIT: was referring to IE -> Edge), Microsoft still doesn't support basic UI functionality. I was sad when they announced they were going to be abandoning Edge's rendering engine for Blink, but I suppose I shouldn't be surprised that Microsoft can't write software up to standards. Unless they have finally fixed it, Office still doesn't support their own OOXML file format standard.
Above all else, I am glad I'm no longer dealing with frontend development.
To put it into numbers: All browsers that supports it (excl. Firefox) has supported it since at least 2013 (or creation). And Chrome added support in 2011, nearly 8 years ago. The only other...
To put it into numbers:
All browsers that supports it (excl. Firefox) has supported it since at least 2013 (or creation). And Chrome added support in 2011, nearly 8 years ago.
The only other browser that doesn't support it is Opera Mini.
I've just given up on supporting Microsoft browsers.
The label+checkbox trick works even in older IE versions (I tested it in IE 8 a few years ago), it's pretty safe to use even thought it's an ugly hack.
The label+checkbox trick works even in older IE versions (I tested it in IE 8 a few years ago), it's pretty safe to use even thought it's an ugly hack.
JavaScript is not the problem. JavaScript libraries are the problem. I write all my own code and re-use as liberally as possible, but always with a view to simplicity. I use no libraries. My web...
JavaScript is not the problem. JavaScript libraries are the problem. I write all my own code and re-use as liberally as possible, but always with a view to simplicity. I use no libraries. My web apps are blazing fast. It's a lot more work. A lot more work. I despise the phrase "jQuery" in Stack Overflow Google results. But it's worth it. I would hate to be in the business of hacking together HTML and CSS in the name of eliminating JavaScript as "the problem." It's not the problem. Stacking libraries upon libraries upon libraries is the fucking problem.
At least to me, this seems like an oddly extreme view - almost as much as the original article, really. Bloat is bad, I'm totally in agreement there, but writing off every library on that basis...
Exemplary
I use no libraries.
At least to me, this seems like an oddly extreme view - almost as much as the original article, really. Bloat is bad, I'm totally in agreement there, but writing off every library on that basis strikes me as counterproductive.
Nowadays, I agree that jQuery is largely unneeded, but go back 7-8 years and you'd not only be tripling your workload to navigate around all the browser quirks, you'd likely be degrading the user experience by hitting obscure platform specific bugs that the millions of jQuery users had already spotted. I'd also be very surprised if the overhead of including jQuery alone is visible to a human in a blind test on even the crappiest of devices.
Jumping to the present day, if you need to do significant UI manipulation, you'd need to write your own virtual DOM and diffing implementation to get performance that's comparable to React or Vue - direct DOM manipulation just isn't as fast. You're faster and less resource-intensive with the library than without.
More complex interactions like drag-drop still have clunky and inconsistent browser APIs, too, so if you happen to be looking for those and want a decent UX then you'll need to reimplement the compatibility layer as well as figure out the appropriate easing and animation to make it all feel natural.
Not everyone needs these features, it's true; maybe your definition of "web app" is different to mine. Some awful sites stack a whole load of trackers, ads, scroll overrides, and other horrible bloated crap before even getting to the necessary JS. But I think saying "JavaScript libraries are the problem" is as reductive as "JavaScript is the problem" would be.
This may be part of why I feel the way I do. I go back 20 years using JavaScript. When jQuery was being developed, I already had my own codebase with all my own workarounds and I both had no need...
Nowadays, I agree that jQuery is largely unneeded, but go back 7-8 years and you'd not only be tripling your workload to navigate around all the browser quirks, you'd likely be degrading the user experience by hitting obscure platform specific bugs that the millions of jQuery users had already spotted.
This may be part of why I feel the way I do. I go back 20 years using JavaScript. When jQuery was being developed, I already had my own codebase with all my own workarounds and I both had no need for it, and recognized it for what it would become: something that would grow mightily in an attempt to satisfy everyone's use-case to the ultimate detriment of all. jQuery alone is not the problem (I confess, I've used .min on more than one occasion) but it is the idea of libraries that breeds laziness and ultimately we end up where we are now, with shit stacked upon shit and the web just this side of unusable (this is just opinion, but man, there's a lot of suck these days on sites that should be top-tier, wunderground.com comes to mind as a recent frustration of mine).
I don't want to be a hypocrite, I have used libraries in a very small way despite what I said in my previous post. I also use other third party add-ons when it really suits me, like mpdf, though that's not related to JavaScript.
Perhaps the problem is the indiscriminate and injudicious use of libraries, rather than the libraries themselves. But my original point was to say that hacking HTML and CSS in order to avoid using JavaScript is stupid. There's nothing inherent in JavaScript that causes the problem the OP was trying to avoid. JavaScript should not be blamed for the failures of (the indiscriminate use of) JavaScript libraries.
I think broadly we actually agree with each other - you don't want people to write off JS as a whole just because it's often abused, and I don't want people to write off tools like React for the...
I think broadly we actually agree with each other - you don't want people to write off JS as a whole just because it's often abused, and I don't want people to write off tools like React for the same reason.
Now we just need to figure out how to stop people from letting their slow, clunky, scroll-hacking code out onto the wider web...
Isn't that what a library is, really? Making reusable, agnostic code, available to others. Besides, code doesn't suddenly start to smell just because you give it an author and make it available...
I write all my own code and re-use as liberally as possible, but always with a view to simplicity.
Isn't that what a library is, really? Making reusable, agnostic code, available to others. Besides, code doesn't suddenly start to smell just because you give it an author and make it available via a package manager.
Many libraries are very large, or solve more problems than you currently have. At some point they might even turn into a framework (react, angular). That's danger territory. That's where you can introduce bloat without being careful. It doesn't mean that library shouldn't exist though. Many projects make great use of these libraries/frameworks. You just need to decide if it's a good fit for your current project or not.
Many libraries do one thing and do it well (the Unix philosophy). Some even take it to the extreme (left pad). But in most cases the code will be battle tested and ready for use.
I'm a solo engineer that builds internal tools that change quickly, need to be rock solid, and support >500 users, and this generally follows my philosophy—fuck libraries, but appropriate uses of...
I'm a solo engineer that builds internal tools that change quickly, need to be rock solid, and support >500 users, and this generally follows my philosophy—fuck libraries, but appropriate uses of JavaScript are more than welcome.
Of course, by saying this I also admit that I sway way toward the "old" or "simple" design patterns I've been using for years—PHP (for both client rendering + API requests) using a homegrown library I've hacked together over the years, plus real light JS on most pages to make everything feel modern and interactive, even though most of what I'm doing could have been done in 2008 or so.
(That said, I know I lose out on some really nifty features that I could have if I was more JS-heavy and relying on more libraries, like good in-line filtering and pagination and etc, but I'm more than willing to bounce out an extra speedy server request in exchange for faster load times, less cruft, and less confusion. My tools are never down, compared to anything that runs more, uh, modern toolsets. I almost accidentally achieved four nines of availability last year, pretty much by trying to keep things as simple as possible.)
From the descriptions of his project, it seems like with every rewrite he focused on some programming paradigm and took it to its logical extreme. But there's a lot of tools in web development, and you should always choose the best tool for the job.
If you need an animation, then absolutely prefer CSS animations before turning to JS. If you need expandos, then summary/details tags are perfect (if you don't mind 88% browser support).
If you need a modal popup however, kludging a giant invisible checkbox may not be the better solution. You're making a lot of assumptions about browser cross-compatibility and rendering. I'd have opted for a more standard JS solution in that case.
I am amazed that even after completely rewriting their browser (EDIT: was referring to IE -> Edge), Microsoft still doesn't support basic UI functionality. I was sad when they announced they were going to be abandoning Edge's rendering engine for Blink, but I suppose I shouldn't be surprised that Microsoft can't write software up to standards. Unless they have finally fixed it, Office still doesn't support their own OOXML file format standard.
Above all else, I am glad I'm no longer dealing with frontend development.
To put it into numbers:
All browsers that supports it (excl. Firefox) has supported it since at least 2013 (or creation). And Chrome added support in 2011, nearly 8 years ago.
The only other browser that doesn't support it is Opera Mini.
I've just given up on supporting Microsoft browsers.
The label+checkbox trick works even in older IE versions (I tested it in IE 8 a few years ago), it's pretty safe to use even thought it's an ugly hack.
JavaScript is not the problem. JavaScript libraries are the problem. I write all my own code and re-use as liberally as possible, but always with a view to simplicity. I use no libraries. My web apps are blazing fast. It's a lot more work. A lot more work. I despise the phrase "jQuery" in Stack Overflow Google results. But it's worth it. I would hate to be in the business of hacking together HTML and CSS in the name of eliminating JavaScript as "the problem." It's not the problem. Stacking libraries upon libraries upon libraries is the fucking problem.
At least to me, this seems like an oddly extreme view - almost as much as the original article, really. Bloat is bad, I'm totally in agreement there, but writing off every library on that basis strikes me as counterproductive.
Nowadays, I agree that jQuery is largely unneeded, but go back 7-8 years and you'd not only be tripling your workload to navigate around all the browser quirks, you'd likely be degrading the user experience by hitting obscure platform specific bugs that the millions of jQuery users had already spotted. I'd also be very surprised if the overhead of including jQuery alone is visible to a human in a blind test on even the crappiest of devices.
Jumping to the present day, if you need to do significant UI manipulation, you'd need to write your own virtual DOM and diffing implementation to get performance that's comparable to React or Vue - direct DOM manipulation just isn't as fast. You're faster and less resource-intensive with the library than without.
More complex interactions like drag-drop still have clunky and inconsistent browser APIs, too, so if you happen to be looking for those and want a decent UX then you'll need to reimplement the compatibility layer as well as figure out the appropriate easing and animation to make it all feel natural.
Not everyone needs these features, it's true; maybe your definition of "web app" is different to mine. Some awful sites stack a whole load of trackers, ads, scroll overrides, and other horrible bloated crap before even getting to the necessary JS. But I think saying "JavaScript libraries are the problem" is as reductive as "JavaScript is the problem" would be.
This may be part of why I feel the way I do. I go back 20 years using JavaScript. When jQuery was being developed, I already had my own codebase with all my own workarounds and I both had no need for it, and recognized it for what it would become: something that would grow mightily in an attempt to satisfy everyone's use-case to the ultimate detriment of all. jQuery alone is not the problem (I confess, I've used .min on more than one occasion) but it is the idea of libraries that breeds laziness and ultimately we end up where we are now, with shit stacked upon shit and the web just this side of unusable (this is just opinion, but man, there's a lot of suck these days on sites that should be top-tier, wunderground.com comes to mind as a recent frustration of mine).
I don't want to be a hypocrite, I have used libraries in a very small way despite what I said in my previous post. I also use other third party add-ons when it really suits me, like mpdf, though that's not related to JavaScript.
Perhaps the problem is the indiscriminate and injudicious use of libraries, rather than the libraries themselves. But my original point was to say that hacking HTML and CSS in order to avoid using JavaScript is stupid. There's nothing inherent in JavaScript that causes the problem the OP was trying to avoid. JavaScript should not be blamed for the failures of (the indiscriminate use of) JavaScript libraries.
I think broadly we actually agree with each other - you don't want people to write off JS as a whole just because it's often abused, and I don't want people to write off tools like React for the same reason.
Now we just need to figure out how to stop people from letting their slow, clunky, scroll-hacking code out onto the wider web...
I mean, their last sentence was:
Isn't that what a library is, really? Making reusable, agnostic code, available to others. Besides, code doesn't suddenly start to smell just because you give it an author and make it available via a package manager.
Many libraries are very large, or solve more problems than you currently have. At some point they might even turn into a framework (react, angular). That's danger territory. That's where you can introduce bloat without being careful. It doesn't mean that library shouldn't exist though. Many projects make great use of these libraries/frameworks. You just need to decide if it's a good fit for your current project or not.
Many libraries do one thing and do it well (the Unix philosophy). Some even take it to the extreme (left pad). But in most cases the code will be battle tested and ready for use.
I'm a solo engineer that builds internal tools that change quickly, need to be rock solid, and support >500 users, and this generally follows my philosophy—fuck libraries, but appropriate uses of JavaScript are more than welcome.
Of course, by saying this I also admit that I sway way toward the "old" or "simple" design patterns I've been using for years—PHP (for both client rendering + API requests) using a homegrown library I've hacked together over the years, plus real light JS on most pages to make everything feel modern and interactive, even though most of what I'm doing could have been done in 2008 or so.
(That said, I know I lose out on some really nifty features that I could have if I was more JS-heavy and relying on more libraries, like good in-line filtering and pagination and etc, but I'm more than willing to bounce out an extra speedy server request in exchange for faster load times, less cruft, and less confusion. My tools are never down, compared to anything that runs more, uh, modern toolsets. I almost accidentally achieved four nines of availability last year, pretty much by trying to keep things as simple as possible.)