5 ms·

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 mak

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?
      - yakshaving_jgt 8y ago
        You have misunderstood me. > 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.
- tracker1 8y ago
  Atom, Brackets, VS Code are all built with JavaScript. npm is itself built with JavaScript... most of the tools built in/around npm are build with JavaScript. 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.
  - yakshaving_jgt 8y ago
    Please read my other comments in the thread before engaging further. I have already explained several times that using a tool is not the same as implementing a tool. 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.
    - mawburn 8y ago
      > Not using. > 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.
      - yakshaving_jgt 8y ago
        Why do you say that?
        mawburn 8y ago

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?
    - yakshaving_jgt 8y ago
      You have misunderstood me. > 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.
tracker1 8y ago
Atom, Brackets, VS Code are all built with JavaScript. npm is itself built with JavaScript... most of the tools built in/around npm are build with JavaScript. 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.
- yakshaving_jgt 8y ago
  Please read my other comments in the thread before engaging further. I have already explained several times that using a tool is not the same as implementing a tool. 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.
  - mawburn 8y ago
    > Not using. > 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.
    - yakshaving_jgt 8y ago
      Why do you say that?
      - mawburn 8y ago