[1]: https://raw.githubusercontent.com/chrisfinazzo/blog/master/g...
#!/usr/bin/bash
set -e
git push origin master
rsync -crz \
--exclude-from='rsync-exclude.txt' \
--delete _site/ \
cfinazzo1@chrisfinazzo.com:/home/cfinazzo1/chrisfinazzo.com
Make would be something similar. In fact your entire Gulpfile in Make would look like this:
.PHONY: doctor build serve deploy
doctor:
bundle exec jekyll doctor
build: doctor
time bundle exec jekyll build --incremental
serve: doctor
time bundle exec jekyll serve --incremental
deploy:
git push origin master
rsync -crz \
--exclude-from='rsync-exclude.txt' \
--delete _site/ cfinazzo1@chrisfinazzo.com:/home/cfinazzo1/chrisfinazzo.comThis is not aimed at the person with no experiences who make static websites using notepad in their free time. This is aimed at people who already have their hands deep in the front-end ecosystem.
But web developers don’t build their own tools. They don’t build their own text editors. They don’t write their own operating systems or web browsers. They don’t need to write their own linters.
Sure, they might enjoy writing their configuration of those tools in JavaScript (grunt, gulp, webpack, etc), but that’s not the same as writing your own tool.
If the analogy isn’t already obvious, I’m saying that while a non-trivial UI project’s development pipeline may include a build tool, e.g., Make, you don’t have to implement Make before you can use Make.
This isn’t a dig at web developers either (like I said, I am one). I write shell scripts, and I lint them with Shellcheck. I don’t need to know the language that Shellcheck is implemented in to use or configure it. It could be implemented in Rust, C, Prolog, or even Brainfuck for all I care.
I’m guessing the people that downvoted my previous comment misunderstood my point.
Editors like Brackets are built from the ground up using JavaScript. Any plugin built for it is made using JS.
The front-end build system / tool-chain that I use has been coded by a handful of front-end developers and uses Gulp (previously Grunt but we migrated) as its base. The repository has 620 commits so far and does everything from minifying and bundling code to generating the 10+ of favicon images needed on modern projects.
Even big names such as Webpack are JavaScript based and maintained by JavaScript developers.
What was Gulp’s big idea? Streaming? Congratulations, your operating system has had this facility for over 40 years.
Some of the Gulp plugins are a hoot too. You can download and install a plugin to help you copy files. Our operating systems already know how to copy files. This is pretty basic stuff.
And Grunt? Grunt doesn’t even have streaming. All transformations are done with disk IO as an intermediary. No surprise then that it’s very slow.
Minifying code? Do you use jsmin by any chance? Because that’s written in C.
Generating your favicon images? Is it ImageMagick you use? Because that’s also written in C.
Does Brackets do anything novel? Does it outperform editors written in compiled programming languages? I would be extremely surprised if it did.
Then you declared that this is useless because no developers actually work on the products they will use for development. I responded by giving your examples where this happens.
Now, you are claiming that those tools are pointless because they use libraries in other languages or because there are alternatives in other languages.
What is your point exactly?
> First you claimed that having a toolset built using familiar technologies was useful to nobody (0% of developers!)
That's not exactly what I wrote.
> Then you declared that this is useless because no developers actually work on the products they will use for development. I responded by giving your examples where this happens.
Wrong again. A very small subset of developers actually build their own times. Writing a Gulp configuration is not an example of building your own tool. That would be an example of using a tool, and writing your own configuration for that tool.
This is the core of my argument. If you can't grasp this, then we can't get anywhere.
> Now, you are claiming that those tools are pointless because they use libraries in other languages or because there are alternatives in other languages.
That isn't what I am claiming. I am claiming that most web developers do not build their own tools. Writing some glue code (shell script, Makefile, Gulpfile, whatever), which calls out to another tool (like the aforementioned tools written in C), is not an example of writing your own tool.
Do you care what language your linter is written in? No. You do not. You only care about its API. You only care that it's easy enough to use from JavaScript. If you can write `gulp do-the-linting`, and it lints your JavaScript, you don't actually care what language the linting engine was implemented in. Almost — again almost — 0% of web developers care about that.
I have the impression that this is not an issue coming from me not being able to grasp this concept but from your inability to communicate efficiently without using a condescending tone.
I do all my CI/CD orchestration around node and JavaScript, even for applications/services not using JS.
React, material-ui, redux, react-jss etc, all JavaScript.
Express, cocket.io, hapi, etc... all JavaScript.
I'm not sure where you are coming from here. As to your reference of Make... you don't have to write npm before you can use npm... the same argument is true of JS tooling.
As to your shell scripts, do they (including your make configuration) run in Windows, Linux and Mac without issue? My Node/JS scripts do.
I also have never said that no developer tools are implemented in JavaScript.
If you like, feel free to tell me what proportion (as a percentage) of web developers in the world are actively contributing to the JavaScript projects you listed.
Not using.
Actually making.
> you don't have to write npm before you can use npm...
That is exactly my point.
Given that you don’t have to write npm before you can use it, it shouldn’t matter to you what language it is implemented in.
I feel someone is going to have to take over from me at this point, because I’m not sure how else to explain this very simple, uncontroversial point.
> Actually making.
I've read all your comments in this thread and I've come to the conclusion that your opinion of a "web developer" is about a decade out of date.
It's not.
Every web developer or frontend engineer I've ever worked with in the last decade has been a software engineer in every sense of the word. Focusing on web based applications or architecture is just what they have chosen or fallen in to.
> This isn’t a dig at web developers either (like I said, I am one)
Do you think the majority of people using make contribute to writing make?
Almost 0% of web developers.
As I have said. Repeatedly.
For every one person building one of these tools, there’s at least 100 developers using it, not actually contributing to it.
Not a difficult concept to grasp.
> Sure, many more will use than make, but that's true of EVERY tool that is made.
Yes. I know. Obviously
> Do you think the majority of people using make contribute to writing make?
Obviously not. And this further proves my point. JavaScript developers can use Make to build their JavaScript. It doesn’t matter what language Make is implemented in.
Are you following yet?
TFA chose to write a tool in THEIR platform of choice. If you want something different, write it your fucking self.
npm happens to run on windows, linux and mac with minimal problems.
Also, the tools in TFA are something someone spent time on creating, that serves a purpose that works within the tooling that most of the people that would use the tool already use... and all you've done is poop on that because it doesn't fit your preconceived notions of what the "right" language/platform is.
To clarify: I’ve been working with JavaScript for the better part of a decade. That’s not the only language I work with though, and specifically which languages I’m proficient in shouldn’t at all detract from the point I was making.
I don’t appreciate you telling me what I think either.
VS Code works better than any IDE with similar or more features that I've tried, including those in compiled or preferred languages. Most other Electron apps are good enough. Yeah, they use a little more ram.. I've got 32GB on my desktop at home... I'd rather use 1-2gb of ram for half a dozen apps than to not have said app.
I don't know what you think, but I, personally feel that you are presenting like a pompous asshole who wants to shit all over useful things that people make because it doesn't fit your arbitrary opinion on what is the right language to use. If you want something better, in your opinion, you make it, and watch people shit all over it because it can't match the features of a tool built in a lesser language.
As to Atom, I didn't care for it... VS Code is a better example of what CAN be done with electron in terms of decent performance. Yeah, it's slower to load than sublime or notepad, but I typically open against a project directory and leave it open for a considerable time.