• MyName (unregistered)

    I don't get it... where's the punchline... nested WTFs?

  • DocMonster (nodebb)

    So "Shoe" was doing things the right way, and the person telling the story was the clueless dumbass?

  • gleemonk (unregistered)

    I'm still not very clear on why you'd want Gulp if you have NPM. But people have told me it does things.

  • Herr Otto Flick (unregistered)

    TRWTF is no webpack, right?

  • RLB (unregistered) in reply to gleemonk

    It does things in the background, is the point. You write Javascript, save your changes, it automatically concatenates and minifies all your files. You write SCSS, as soon as you save it Gulp turns it into minified CSS for your webpage to load. Doesn't do anything revolutionary, it just saves you hitting "build" manually. (And that's only when you've installed gulp-watch.)

    Of course, you probably can make it do spectacular things. There's probably a Gulp plugin for turning animated GIFs into MP4 and vice versa, by now. But you mostly just use it to replace good old make.

  • Martin (unregistered)

    TRWTF is the community who doesn't like make, so they develop maven, then ant, then rake, then grun, then gulp, then webpack... I don't even remember all that shit.

  • Michael (unregistered) in reply to Martin

    It's not the "like".

    They do not understand how it works and think learning about it is too much of an effort for their project. They figure this is the reason to create a replacement. And then they try to sell it to people who know that they haven't fully understood the predecessor, but got a good enough grasp of it to get their work done.

  • my name is missing (unregistered)

    This is a meta WTF. The WTF isn't really a WTF except for us poor saps who go WTF is this WTF doing here? Perhaps the industry has run out of WTFs for this WTF site and everything is Fing perfect now.

  • RFOMI (unregistered)

    Not my friend.

  • RFOMI (unregistered)

    Not my friend.

  • Anthony (unregistered) in reply to Herr Otto Flick

    webpack was probably in the gulp file.

  • Sole Purpose of VIsit (unregistered) in reply to my name is missing

    Yup, it's a different world out there. I'm sure there are non-WTF things in the front-end Javascript/DOM/whatever universe, but I listen to this sortof tale and I have to admit that I have nothing in common with the submitter, with his friend, with the "over-engineer", or with Jane. Without actual details that explain what the code does and how it does it, this is just like listening to your great-aunts moaning about who got the family trousseau.

    One question that springs to mind, however: can anybody explain the point of minifying Javascript? Not compressing (I can't believe I have to say this). Not obfuscating. But ... minifying?

  • Zenith (unregistered) in reply to DocMonster

    If I had to guess, that's the conclusion that I would've arrived at too.

    Also I agree with Michael about make. I have a similar issue with NuGet, especially when the library authors don't offer a non-NuGet download. It was "too hard" for developers, making good money for their "skills," to download DLLs and update the project references so somebody had to introduce a stupid dependency instead? How did that make anything better?

    Also, minified JScript is a dumb solution for a self-inflicted problem. You could use tabs and keep your function calls/headers on one line and get 90% of the benefit. Or you could be one of those fools that put every parameter on a separate line and use spaces to physically line them up "for readability." That habit is far more pronounced amongst framework cobblers that are already pulling in way more JScript than they actually need. Those people get all upset about premature optimization and then do no optimization ever, exposing their real beef as one against those capable of doing optimization, up to and including the eschewing of bloated frameworks.

  • Somebody Somewhere (unregistered) in reply to Sole Purpose of VIsit

    On the other hand, thanks to this article I now know what a trousseau is. So it was at least indirectly educational.

  • No Fun (unregistered)

    Am I the only one who thinks that 'Shoe' was actually the submitter of this story, and they were attempting to point out the WTFy nature of their colleagues' attitudes, but they went for a level of sarcasm that the editor just completed missed? Because even though it's in direct quotes, I refuse to believe that the submitter actually said "Can you believe it? What a n00b!", and meant it seriously. I wonder if there was just a /s that got missed...

  • ELIBBAD (unregistered) in reply to Sole Purpose of VIsit

    I believe that the motivation for minified Javascript is that ASCII text composed entirely of printable characters compresses well, right? So a naive view would say that you'll get about the same compression ratio no matter the size of your input text. The logic is that if you minify and then serve the compressed file, you'll save a few percent more bandwidth, lowering your hosting costs and your users' bandwidth costs.

    In practice, if you make sure to strip out comments and reduce variable names to the minimum, etc. you can get more space savings from minifying than from gzipping, and you're left with something which still gzips well - you can further reduce the file size by more than half. Sure, your compression savings will go from 71% to 65% or something but you are left with something much smaller.

    Of course, avoiding large JS frameworks in the first place will give you much more space savings, but you won't have the nice widgets which spin on hover or anything. If you're relying on client-side functionality for user experience, then you really should consider what tools are available and perhaps adopting one or two of them.

  • spadgas (unregistered)

    Think it's more likely that the real WTF is the people who read this and don't see themselves.

  • Ross (unregistered)

    I believe the real point behind minifying is not to reduce a single js file, but to combine many js files into one, thereby the browser only needs to download one file.

    There's no good reason to remove whitespace at the same time, but that's how it turned out.

  • Whoever (unregistered)

    The expression is "be-all [and] end-all", from Macbeth , not vice versa.

    Also: " he starts googling on the Internet" - as opposed to googling on, what, the beach?

  • JSDev (unregistered)

    Minifying JS has a few benefits. For one, you shrink the file size, making it download a little faster (not much benefit over just compressing, but why not?). This also has benefits for mobile devices, which generally have much slower speeds and also have data caps or charge per megabyte.

    It also parses faster, which matters when you need everything parsed, interpreted/compiled, and executed before your website actually works. Again, it's a small difference, but you're relying on user machines and browsers.

    A more modern advantage is that (if you write your code using new JavaScript features from ES6 or whatever), you are going to want to trans-pile (because translation and compilation are different?) your code to work in browsers that might not have all the features. When you're doing that machine translation, might as well make it smaller since no one needs to read it.

    The final benefit comes with caching. There are upsides and downsides here, but if you combine all of your JavaScript into one file, the browser only has to download it once. Every new page load uses the same cached version and only the first page load is slower. You also slightly reduce the size of your HTML by combining a dozen script tags into one. Of course, if you care more about the first page load, you don't want to include JavaScript that only will be used on other pages. And if you have one experimental page that regularly changes, you don't want that to invalidate the cache for all your other pages and make the browser download everything again.

    Minification doesn't really matter until you get to "web scale". When you have millions of hits per day, then the tiny benefits add up. The only reason most people even think about it is that JavaScript frameworks show off minified versions, and JS code from analytics providers comes minified.

  • Jeremy Hannon (google) in reply to Ross

    Actually there is a good reason to remove whitespace. While size decrease is important for network traffic and server load, the primary point of minimizing is improving the speed of the client side. JavaScript engines have gotten faster, but it doesn't mean that the client using the website has a very powerful device. For a while, it was assumed that any computer anyone ran was powerful enough, but then we have mobile browsers. Plus, you really don't know what other programs and load is already on the client device. The little bit extra in processor and storage savings for the client device can mean a lot to a mobile user, and that little bit of improved customer satisfaction may mean just a few more happy users that become customers.

    Yes, whitespace does take extra CPU cycles and RAM to process.

  • Nupa (unregistered)

    This is why I can't read "Not Always Right" anymore. Something like 90% of the stories submitted are just normal customers who needed something non-obvious explained to them, and the submitter is frothing at the mouth or clearly exaggerating details because they're just bitchy.

  • o11c (unregistered)

    The way this article was written made it painfully difficult to read.

    I'd rather read minified javascript.

  • Agreed (unregistered) in reply to o11c

    This was one of the worst written WTF's i've ever read. It wasn't just not funny, it was painful and awkward to read.

  • David (unregistered) in reply to Martin

    And people didn't like machine language, so they had to invent assembly then FORTRAN and ALGOL. I'm sure with a pile of glue and a lot of work, make could keep all the libraries up to date and in the right versions, but that would be a lot of work for something that modern Java buildsystems do automatically.

  • Sole Purpose of VIsit (unregistered)

    Many thanks to everybody who commented on minifying Javascript. I genuinely felt I learned something today ... though, obviously, not from the OP.

    Still not convinced, particularly about the "it helps you slam everything into a single file/ref/download" thing, however. That doesn't seem to be anything to do with minification. That seems more like organizing and segmenting your source code. (Which is not a bad thing.)

    I checked out JS minifying on, what a surprise, Wikipedia, and it still sounds like a party trick to me. Lots of whitespace reduction, lots of loop refactoring, lots of the sort of thing that would appeal to someone running an afternoon lab for CS 201 students.

    Frankly, if you're running a website that has a million hits a day, I really don't see why you should care about the 10% to 20% saving on bandwidth you "theoretically" get out of minification. You're presumably running over your own infrastructure in any case. Bits is free!

    Then again, what the hey. It looks good on a dashboard or a management chart. (I know this because, well, I've seen it, argued against it, and been whupped like a red-headed step-child.) What the fuck, let's do this thing!

  • Sole Purpose of VIsit (unregistered) in reply to Jeremy Hannon

    If parsing whitespace on the client side is a problem ... I suggest you use a better parsing system.

    Perhaps one, like Lex & co, that spits out tokens to the grammar processor, which may or may not resemble Yacc.

    Unless the BNF for the lexer is whacked out on LSD, skipping through whitespace at a tolerable rate is not going to challenge even a Raspberry Pi.

  • snoofle (unregistered) in reply to Michael

    A very long time ago, on a dare from my boss, I wrote a modest sized application, entirely in make and shell scripts. It took an unreasonably long time to accomplish the task (imagine shelling out virtually everything you had to do), but it worked. That pizza and beer was especially tasty.

    Make is an extremely powerful tool, IF you take the time to learn how it determines dependencies, and assorted other things it does.

  • derpface (unregistered) in reply to Sole Purpose of VIsit

    With a page with 1M hits a day, there is a substantial possibility to save data transferred with minifying, and bandwidth costs money. Minifying is virtually free to do. So, saving real money for doing something that is pretty much free sounds like something useful for a company that wishes to turn as large a profit as possible.

  • TheCPUWizard (unregistered) in reply to Sole Purpose of VIsit

    Sole Purpose of VIsit -- You are correct. Many people conflated "Bundling" [multiple files into one] with Minification. Both have their uses. One advantage of mini over compress is that at the target (which can b a very low capability device) there is no overhead (akak decompression) required.

  • TheCPUWizard (unregistered) in reply to RLB

    "write Javascript, save your changes, it automatically concatenates and minifies all your files. " -- That has value if you are modifying your code in production!!! With a fully controlled (SCM/BVT/CI/CD/etc) environment it really does not.

  • isthisunique (unregistered)

    I normally like to KISS starting out but something like a build process should at least start out in a clean simple build.sh file (or rather part of a set of simple initial scripts) which for all intends and purposes is essentially where you put your history of commands from your first manual build. There's no point to put random scraps in a read me and its hard to break things into blocks to move towards a process with that.

    Once the file starts to get anything close to complicated then you start to think of complex solutions. You often don't want a huge sophisticated build process when starting out. You end up otherwise having the build builder or system setup being 99% of the work. While it's good to have a foundation, it's not always ideal to jump into using mega tools until you have a better idea of what you really need (your build is now doing a few things, your environment is this or that, developers like this of that, etc).

  • I don't get it (unregistered) in reply to MyName

    I read it, but I don't understand the WTF. Can someone explain?

  • Jarz (unregistered)

    Bandwidth is defintely not free if you get to the point you have global reach and you are serving the assets using one of the CDN providers, who charge and some for storage space and number of requests served.

  • Anonymous (unregistered)

    Comment held ror moderation

  • Friendly_Reminder (unregistered)

    "Not enough jQuery. Downvoted!"

  • DocMonster (nodebb) in reply to I don't get it

    As I understood it, the WTF is that the person talking about "Shoe" talks about him as though he's a clueless idiot, when "Shoe" is doing things the right way, so the person saying "Lol this guy is doing X Y and Z" is actually the WTF for not knowing the right ways to do things. It's kind of like in a previous story, "Slacking Off" where the antagonistic "senior" developer, "Larry" was all like "Yeah the new guy keeps wanting us to use Source Control and Unit Testing, I mean what a noob right?" when the punchline is that the new guy was doing it right. Same principle here; "Shoe" was doing things correctly, the person ridiculing "Shoe" is the clueless idiot.

  • Andrew (unregistered) in reply to RLB

    "(And that's only when you've installed gulp-watch)."

    Which is to say, that gulp actually does nothing.

  • ohigetit (unregistered)

    TRWTF is that these people are standing around talking about tooling all day.

  • Ayukawa (unregistered)

    Reading this article must be what a stroke feels like.

  • Ayukawa (unregistered)

    Reading this article must be what a stroke feels like.

Leave a comment on “Poor Shoe”

Log In or post as a guest

Replying to comment #:

« Return to Article