8 ms·

The above command just installs a folder with plain JS files in it, I'm not sure what system pollution you're talking about. It's very convenient for web develo

The above command just installs a folder with plain JS files in it, I'm not sure what system pollution you're talking about. It's very convenient for web developers to use cli tools written using the same languages and stack as their end products. I'm guessing you're not a web developer ...

yakshaving_jgt 8y ago
I’m a “web developer”, and I can say with a good deal of confidence that almost 0% of web developers have any special utility in any of their tools being implemented in a language they’re familiar with.
- Raphmedia 8y ago
  Anyone who actually takes the time to lint their styles will likely have a customized build system. This 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.
  - yakshaving_jgt 8y ago
    Yes, I’m well aware of that. 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.
    - Raphmedia 8y ago
      Do you somehow think that we wait until some charitable Ruby developer comes to the rescue whenever we need something done? 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.
      - yakshaving_jgt 8y ago
        Just because lots of people are doing it, doesn’t mean it’s a good idea. 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.
        Raphmedia 8y ago
        First you claimed that having a toolset built using familiar technologies was useful to nobody (0% of developers!). So I answered that those who do not gain anything from this are not the target demographic of Stylelint anyway. That experienced developers actually gain from having a toolset built in a familiar language. 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?
- tracker1 8y ago
  You're a "web developer" and JavaScript is not something you're familiar with?
  - yakshaving_jgt 8y ago
    That is not at all what I said. I’m not sure what gave you that idea. 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.
    - tracker1 8y ago
      The only thing I gather is that you don't think people should be creating these tools with JS if that's what they choose to do. Because you feel that others should conform to your opinion on what's the best language for a given tool.
      - yakshaving_jgt 8y ago
        I think a dynamic scripting language is a poor choice for software that has non-trivial performance needs. The fact that so many people complain about the speed and memory performance of Electron apps is a testament to this. I remember for a long time also that Atom couldn’t open a file larger than 2MB before crashing. I don’t appreciate you telling me what I think either.
        tracker1 8y ago
        So, make something better... shitting on people that spend time writing useful things is not really helping anyone. The fact is, I appreciate electron apps... they let me use the same things on Windows, Linux and Mac, which I use all regularly. 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.
deleted 8y ago
[deleted]
chrisfinazzo 8y ago
I think it's the lack of a 'common-js-functions' package that is far smaller and less dependency-driven. This is why for the small bit of web development I do, I went with gulp-shell, which just wraps a big shell script that does the actual work. Don't get me wrong, it's got some of the same problems, but there's far less dependency hell to worry about seeing as it's just infrastructure to support the actual commands I'm running.
- yakshaving_jgt 8y ago
  Could you expand on why you use gulp-shell when you presumably have the ability to run shell scripts directly?
  - chrisfinazzo 8y ago
    For one script (deploy), that's 148 characters I don't have to type. Repeatedly, as changes are made. Just `gulp deploy` and it's done. Beyond that, I'm more comfortable in bash, so I'd like to not waste that effort by moving to something else.
    - yakshaving_jgt 8y ago
      Right, but then why not use bash by itself? Why wrap it in JavaScript at all?
      - chrisfinazzo 8y ago
        I'm not typing [this][1] often if I can help it. [1]: https://raw.githubusercontent.com/chrisfinazzo/blog/master/gulpfile.js https://raw.githubusercontent.com/chrisfinazzo/blog/master/g...
        yakshaving_jgt 8y ago
        Right, but why would you need to? You said you were more comfortable in bash, so why not just do it in bash? Or Make? #!/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 Stick that in a file called `deploy`, run `chmod +x deploy`, and then you can invoke it with `./deploy`. 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.com

yakshaving_jgt 8y ago

I’m a “web developer”, and I can say with a good deal of confidence that almost 0% of web developers have any special utility in any of their tools being implemented in a language they’re familiar with.

Raphmedia 8y ago
Anyone who actually takes the time to lint their styles will likely have a customized build system. This 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.
- yakshaving_jgt 8y ago
  Yes, I’m well aware of that. 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.
  - Raphmedia 8y ago
    Do you somehow think that we wait until some charitable Ruby developer comes to the rescue whenever we need something done? 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.
    - yakshaving_jgt 8y ago
      Just because lots of people are doing it, doesn’t mean it’s a good idea. 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.
      - Raphmedia 8y ago
        First you claimed that having a toolset built using familiar technologies was useful to nobody (0% of developers!). So I answered that those who do not gain anything from this are not the target demographic of Stylelint anyway. That experienced developers actually gain from having a toolset built in a familiar language. 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?
tracker1 8y ago
You're a "web developer" and JavaScript is not something you're familiar with?
- yakshaving_jgt 8y ago
  That is not at all what I said. I’m not sure what gave you that idea. 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.
  - tracker1 8y ago
    The only thing I gather is that you don't think people should be creating these tools with JS if that's what they choose to do. Because you feel that others should conform to your opinion on what's the best language for a given tool.
    - yakshaving_jgt 8y ago
      I think a dynamic scripting language is a poor choice for software that has non-trivial performance needs. The fact that so many people complain about the speed and memory performance of Electron apps is a testament to this. I remember for a long time also that Atom couldn’t open a file larger than 2MB before crashing. I don’t appreciate you telling me what I think either.
      - tracker1 8y ago
        So, make something better... shitting on people that spend time writing useful things is not really helping anyone. The fact is, I appreciate electron apps... they let me use the same things on Windows, Linux and Mac, which I use all regularly. 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.

deleted 8y ago

[deleted]

chrisfinazzo 8y ago

I think it's the lack of a 'common-js-functions' package that is far smaller and less dependency-driven. This is why for the small bit of web development I do, I went with gulp-shell, which just wraps a big shell script that does the actual work. Don't get me wrong, it's got some of the same problems, but there's far less dependency hell to worry about seeing as it's just infrastructure to support the actual commands I'm running.

yakshaving_jgt 8y ago
Could you expand on why you use gulp-shell when you presumably have the ability to run shell scripts directly?
- chrisfinazzo 8y ago
  For one script (deploy), that's 148 characters I don't have to type. Repeatedly, as changes are made. Just `gulp deploy` and it's done. Beyond that, I'm more comfortable in bash, so I'd like to not waste that effort by moving to something else.
  - yakshaving_jgt 8y ago
    Right, but then why not use bash by itself? Why wrap it in JavaScript at all?
    - chrisfinazzo 8y ago
      I'm not typing [this][1] often if I can help it. [1]: https://raw.githubusercontent.com/chrisfinazzo/blog/master/gulpfile.js https://raw.githubusercontent.com/chrisfinazzo/blog/master/g...
      - yakshaving_jgt 8y ago
        Right, but why would you need to? You said you were more comfortable in bash, so why not just do it in bash? Or Make? #!/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 Stick that in a file called `deploy`, run `chmod +x deploy`, and then you can invoke it with `./deploy`. 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.com