5 ms·

I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification

I get that this article is satire, but I think the deepest (perhaps) unintentional insight presented by the author's veiled criticism is that the justification for using these tools is presented as "it's 2017" and not as a solution to any particular problem. The issue isn't the 2017 ecosystem, the issue is the 2017 programmer's deference to vanity instead of engineering. All these individual tools exist for a reason, and if your project is already functioning to specification without the use of these tools, you shouldn't be using them; doing otherwise is the developer's fault, not the tool's or the ecosystem's.

rosser 10y ago
It's called "résumé-driven development."
- sixdimensional 10y ago
  And sadly, in the race to stay competitive, it's all too common.
- Spivak 10y ago
  Well yeah, why would you do anything else? When recruiters and job postings are mostly concerned with what languages and tools you know over software development ability and computer science knowledge why would you voluntarily make your life more difficult?
  - rosser 10y ago
    I believe the term you're looking for is "middle ground".
- navs 10y ago
  Might explain why I don't get many recruiters attempting to contact me. Back when AngularJS was the big thing, I'd get bombarded on LinkedIn. Now, having only non-commercial experience with React and refusing to list it on my resume, I'm mostly ignored. Now are recruiters to blame or the companies that hire them?
- TuringNYC 10y ago
  Exactly. In big companies there are architectural review boards to stop unstable platform usage. I agree those can go too far and sometimes slow things down. However, i've see too many startups use the platform du jour w/o any consideration to stability. Worse, some will fork a good platform, make slight changes, and market their fork as the next best thing. Since experience does not matter as much to keyword-driven recruiters, is it any surprise this all happens?
dheera 10y ago
On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?
- derimagia 10y ago
  Different tools specific to their job, they wouldn't be good to combine together. apt-get only exists for linux, requires root and is designed for that, npm doesn't. apt-get installs the latest version, npm expects more specific verisons since it's for code. npm is built for node's ecosystem and apt-get is better for system packages.
- tikhonj 10y ago
  I've thought the same for a while, and now I'm looking to Nix[1] as a solution. Upside: strong fundamental design, extreme reproducibility, great Haskell support. Downside: small community, middling OS X support, essentially non-existent Windows support. It's still squarely in early adopter territory and the documentation is woeful, but if you're willing to put up with that it really does feel like the "one true package manager" I've been searching for. I've been using it at work and while the setup was painful and some things are still awkward (ie statically linking Haskell executables), it's been incredible overall. The up-front work in learning the system and getting it running has paid off already, and it'll pay off even more as I continue using Nix for other things. [1]: https://nixos.org/nix/ https://nixos.org/nix/
- ponyfleisch 10y ago
  > Why can't we just use apt-get and Makefiles for everything? Because Makefiles are quite limiting. > Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python? Because that would be OS specific.
  - shakna 10y ago
    Makefiles are limiting? They have their own macros, and support M4 as well (macros with recursion), not to mention the DSL is Turing complete. Make runs on Windows, OS X, Linux and Android. How is a Makefile quite limited?
unscaled 10y ago
The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill: 1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion. 2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework. 3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that. 4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework. 5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass. 6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline. 7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP. 8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks. 9. Wow, you need so many javascript and PHP libraries! Let's use a package manager. 10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up. We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot. Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices). Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.
nkkollaw 10y ago
I think all these tools give you structure, though. Every project is setup in an identical or similar way, which makes it easy for other developers to jump in and understand what's going on.
- jayflux 10y ago
  But that loses its usefulness if there's new tools every 6 months. Yes webpack gives me structure today, but there could be a new structure tomorrow. Look at Grunt and Gulp, NPM and yarn....
  - nkkollaw 10y ago
    Not really, you'll still be able to follow what's going on if the project follows an old standard way of doing things, compared to a random or made-up way of doing things. I had to update a project that used the Gulp-based workflow 2 days ago, and after 5 minutes I knew what I was doing again. Even if you don't remember you can still look it up, while those who reinvent the wheel seem to never bother documenting their wheel.
cossovich 10y ago
How is the article satirical? I didn't get that at all.
mseebach 10y ago
The article is fallacious in that writing "hello world" (and then working your way up to printing the numbers from one to 10, then asking for your name and printing "Hello, $NAME", then checking the time and printing good morning/evening etc) isn't about building a fully-featured modern web application. You could argue that the example is criminally irresponsible because it neither considers the need for HTTPS and 2FA! And finally, you need to compare apples to apples. Setting up a similarly fully featured application in any language takes significant effort, and may well be easier than in PHP, but Hello World is still easier in PHP.

rosser 10y ago

It's called "résumé-driven development."

sixdimensional 10y ago
And sadly, in the race to stay competitive, it's all too common.
Spivak 10y ago
Well yeah, why would you do anything else? When recruiters and job postings are mostly concerned with what languages and tools you know over software development ability and computer science knowledge why would you voluntarily make your life more difficult?
- rosser 10y ago
  I believe the term you're looking for is "middle ground".
navs 10y ago
Might explain why I don't get many recruiters attempting to contact me. Back when AngularJS was the big thing, I'd get bombarded on LinkedIn. Now, having only non-commercial experience with React and refusing to list it on my resume, I'm mostly ignored. Now are recruiters to blame or the companies that hire them?
TuringNYC 10y ago
Exactly. In big companies there are architectural review boards to stop unstable platform usage. I agree those can go too far and sometimes slow things down. However, i've see too many startups use the platform du jour w/o any consideration to stability. Worse, some will fork a good platform, make slight changes, and market their fork as the next best thing. Since experience does not matter as much to keyword-driven recruiters, is it any surprise this all happens?

dheera 10y ago

On a similar note, I always find it ridiculous when I have to do things like apt-get install npm && npm install bower && bower install ... Why can't we just use apt-get and Makefiles for everything? Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python?

derimagia 10y ago
Different tools specific to their job, they wouldn't be good to combine together. apt-get only exists for linux, requires root and is designed for that, npm doesn't. apt-get installs the latest version, npm expects more specific verisons since it's for code. npm is built for node's ecosystem and apt-get is better for system packages.
tikhonj 10y ago
I've thought the same for a while, and now I'm looking to Nix[1] as a solution. Upside: strong fundamental design, extreme reproducibility, great Haskell support. Downside: small community, middling OS X support, essentially non-existent Windows support. It's still squarely in early adopter territory and the documentation is woeful, but if you're willing to put up with that it really does feel like the "one true package manager" I've been searching for. I've been using it at work and while the setup was painful and some things are still awkward (ie statically linking Haskell executables), it's been incredible overall. The up-front work in learning the system and getting it running has paid off already, and it'll pay off even more as I continue using Nix for other things. [1]: https://nixos.org/nix/ https://nixos.org/nix/
ponyfleisch 10y ago
> Why can't we just use apt-get and Makefiles for everything? Because Makefiles are quite limiting. > Why can't npm be turned into ppa:nodejs and pip be turned into ppa:python? Because that would be OS specific.
- shakna 10y ago
  Makefiles are limiting? They have their own macros, and support M4 as well (macros with recursion), not to mention the DSL is Turing complete. Make runs on Windows, OS X, Linux and Android. How is a Makefile quite limited?

unscaled 10y ago

The combination definitely seems overwhelming, but each tool is a solution to a real problem. That's where the "(real)" in the title is coming from. Yes, if you're only writing a hello world app you certainly don't need all that bloat, but if you're writing a real world app, here's a list of legitimate requirements you have to fulfill: 1. You offered your client a static page with purple background, blinking title, a guestbook and a visit counter - they miraculously refused; therefore, you need a database. That was true even in the good old days of the LAMP stack, circa the time BLINK tags went out of fashion. 2. Your app will be rather complex (many views, controllers and routes) and probably have more than one developers, and you'd want to somehow manage all of this complexity, have a standardized way of organizing views/controllers/etc. and cut down on hard-to-maintain boilerplate. That's why you want a framework. 3. Your data will change (you need migrations) and inline SQL gets hairy very quickly. You'll need an ORM. You'll need to create models/entities for that. 4. Your client demands an SPA. They want incremental search, sliders, drag and drop functionality and everything else that require a Javascript framework. 5. You need responsive design and nice looking CSS widgets, and a design that easy to update (so that you could replace your primary and highlight colors in a single place). You end up with a CSS framework like Bootstrap and a preprocessor like Sass. 6. You realize you'll end up writing JS code no less than you would write PHP, and you want to avoid callback hell, and the general weirdness that comes with classic ES5, so you go ahead and add Babel to your pipeline. 7. You also need to merge and minify JS and CSS files, so you end up tacking webpack or browserify or a custom grunt or gulp build script (or even both of them) to your pipeline. Yeah, complex pipeline suck, but in the old days we used to zip everything and upload with FTP. 8. The article doesn't mention it, but you may definitely want to set up a CI pipeline that does all of that, and link it with your Git repo using webhooks. 9. Wow, you need so many javascript and PHP libraries! Let's use a package manager. 10. Your SPA needs to communicate with your app somehow, right? We need to use an API for everything. REST is getting a lot of hate recently, but it's not like gRPC or JSON-RPC or GraphQL are simpler to set up. We haven't even mentioned adding OAuth2 support, social login, analytics, error reporting and logging, client-side router, isomorphic apps which generate views on the server side, view caching and object caching, a separate server for static resources, load balancing, a CDN, setting up LetsEncrypt to automatically issue SSL certificates and whatnot. Yeah, setting up a modern web app is complex. Not because this is how we do web app, but because by 2017 users' expectations of web app are much higher than they used to be. If your app is in a position to skip some of the issues listed above, by all means skip it. People often go into overkill mode with all these frameworks (one of my pet peeves at work is people using Spring for microservices). Of course, if all you need is printing "Hello World", even good old <?php echo 'Hello, world!'; ?> is an overkill when you could just use static HTML.

nkkollaw 10y ago

I think all these tools give you structure, though. Every project is setup in an identical or similar way, which makes it easy for other developers to jump in and understand what's going on.

jayflux 10y ago
But that loses its usefulness if there's new tools every 6 months. Yes webpack gives me structure today, but there could be a new structure tomorrow. Look at Grunt and Gulp, NPM and yarn....
- nkkollaw 10y ago
  Not really, you'll still be able to follow what's going on if the project follows an old standard way of doing things, compared to a random or made-up way of doing things. I had to update a project that used the Gulp-based workflow 2 days ago, and after 5 minutes I knew what I was doing again. Even if you don't remember you can still look it up, while those who reinvent the wheel seem to never bother documenting their wheel.

cossovich 10y ago

How is the article satirical? I didn't get that at all.

mseebach 10y ago

The article is fallacious in that writing "hello world" (and then working your way up to printing the numbers from one to 10, then asking for your name and printing "Hello, $NAME", then checking the time and printing good morning/evening etc) isn't about building a fully-featured modern web application. You could argue that the example is criminally irresponsible because it neither considers the need for HTTPS and 2FA! And finally, you need to compare apples to apples. Setting up a similarly fully featured application in any language takes significant effort, and may well be easier than in PHP, but Hello World is still easier in PHP.