Hacker News new | more | comments | ask | show | jobs | submit login
Stylelint – A modern linter for CSS (stylelint.io)
213 points by tilt 19 days ago | hide | past | web | favorite | 102 comments



Something else that I recently came across- https://japgolly.github.io/scalacss/book/quickstart/standalo...

Typesafe css, so you wouldn't spell px as xp.

Stylelint isn't just a linter- it's also a checker. And looks like it does both jobs well. scala-css does the checker job very well, maybe better if it understands the fields (I don't know if it does).


I generally find that syntax highlighting does a good job of this. My editor will highlight valid CSS keywords and property names a different colour to invalid ones, making it pretty obvious when you've made a typo.


That's like saying JavaScript is enough over TypeScript because of syntax highlighting.


Not really. TypeScript providea much stricter checking than just checking that I have the correct syntax. Whereas this tool isn't checking that my combination of CSS properties makes sense, it's just checking the syntax...


This is nice, and I tried it out... and it's led to a general CSS question.

    #ff9f
Is that valid? What colour is that?!


It's part of CSS Colors Level 4, which is still in draft stages, but some browsers (but not all) already support it. It's the same as #ffff99ff (same draft), which is the same as rgba(255,255,153,100%) or #ffff99


Browser support isn’t really that relevant here. PostCSS has a plugin that adds a fallback during the build step. If you want to use the #RGBA and #RRGGBBAA syntax, you can do it today. (I use it.)


It's relevant information, because not everyone uses the same postprocessing pipeline as you do (or even any at all)


What advantage does this give when we have SASS and other systems that support variables?

This is a spec going through draft-review-deployment so we can type 3 less characters?


Until now, the variants where #rrggbb and #rgb, so the extension to alpha is parallel: #rrggbbaa, #rgba. I personally like that extension, so you can just add an alpha component to a color without transforming it to a different form first. It's also relevant to people using automated systems, since those automatically can choose the most compact representation of a color possible in their output.

> This is a spec going through draft-review-deployment so we can type 3 less characters?

The key phrase above is is part of, it's one of the smaller aspects of the spec.


This doesn't have anything to do with variables, it's simply adding an opacity value to hex-encoded colours. So `#ffff` (or `#ffffffff`) is the sames as `rgba(255, 255, 255, 1)`, and `#ffffff7f` would be `rgba(255, 255, 255, 0.5)`.

Until now, if you wanted to assign a colour with opacity, you had to use the `rgba()` format. Now you can just hex-encode it :)


This is 4-digit hex rgba notation. It's a shorthand for #rrggbbaa, literally as #rgba. In this case alpha is f = 1.0, so #ff9f = #ff9.


That's #rgba where 4th character is the alpha.


Why is it # ff ff 99 ff

Would # f0 f0 90 f0 not be much more logical? It it were decimals 10, 20, 30 would get a shrthand of 1, 2, 3. It would not mean 11, 22, 33. At 1 it's not much of a differenct but at f it's quite a bit.


If you start with the premises that A: the shorthand notation should have access to the 0 value B: the shorthand notation should have access to the full value #ff and C: the shorthand notation should be linear in the RGBA scale, then the current system falls out of that as the uniquely-identified solution.

(Ignoring questions about how linear RGBA really is. In this case we're just looking at how to map 0-f to 00-ff. Whether RGBA is broken is a separate question.)


Because it gives you the greatest range, from 00 -> FF. That way you can represent full black and full white without either looking grey.


If #fff was #f0f0f0 then it would be impossible to express pure white in the shorter notation


Its popularity as a shorthand arose from the use of the “web safe” colour palette back in the late 90s/early 2000s which exclusively used 00, 33, 66, 99, CC, and FF: https://en.m.wikipedia.org/wiki/Web_colors#Web-safe_colors


That should expand out to #ffff99ff, where the last pair is the alpha, i.e. rgba


Much love for Stylelint. My last company had some unique style guide rules, and I was able to encode all of them in Stylelint with only a few custom rules. The custom rules were very easy to write and plug in, and everything auto-fixes. Absolutely eliminated a large chunk of developer time wasted in code reviewing the wrong things.


Does this help with Dead Code Elimination?


Nope, but there are tools for this

PurgeCSS (recommended by Tailwind) https://github.com/FullHuman/purgecss

PurifyCSS https://github.com/purifycss/purifycss


Any support for Stylus? I see it supports SugarSS, which I had not heard of, and that looks sort of close...


If using Chrome's Stylus extension's support for using Stylelint to lint a style written in Stylus is the same as on the command line, then the only real issue I've had is that you often need to use colons to separate properties and values to prevent Stylelint giving cryptic errors for which it gives a location that's nowhere near the actual position that triggered the error, leading to commenting and un-commenting code until you find the source.


Should be possible via PostCSS and something like https://www.npmjs.com/package/postcss-stylus-parser. Haven't tried it though, i've moved away from Stylus some time ago as it seemed to be pretty much dead.


I think it's more like 'complete'. What do you miss from Stylus? I prefer it from SCSS when it doesn't require you to type colons, semicolons and brackets for quite less typing and everything you'd expect as a CSS preprocessor is just there. It's TJ's work after all.


The only thing lacking about Stylus is the documentation really - the built-in functions page seems to list functions in random order (could be in order of addition to the language I guess!), there's no master index of the various syntax features, its usefulness varies a lot between different features - some are barely mentioned at all - and stuff like arrays, lists and hashes could do with more clarification.

Actually, looking at some of my standard Stylus includes, you can't have a block mixin that modifies the individual rules in a block, to be able to create something like

  important()
    for $prop, $value in block
      {$prop}: $value !important
I recently discovered a new user style Chrome extension called Stylus after Stylish was removed from the Extension Store for privacy violations, and not only does it allow you to use Stylelint and CSSlint to check your user styles, but it supports an extended type of user style called UserCSS that allows you to use Stylus for writing styles :) It does need you to use colons to prevent the editor and Stylelint complaining, but everything else works:

https://gist.github.com/spiralx/8c547d48cfaa0628ee720a16caaa...


I'm a little confused -- did something happen with/to stylelint? Why is it at the top of HN right now?


I was wondering the same thing. It'd be like a link to the homepage of React being the top link of HN. Stylelint has been around and popular for years now.


Sometimes not so obvious tools get posted like that, you'll see.

I think it's good to see fresh discussions on random tools from time to time.


Someone was in the lucky 10,000 today and wanted to share the joy, presumably.

https://xkcd.com/1053/


I must admit, I'm one of those 10,000.



I got a little excited that it would replace Prettier except with [insert more reasonable style preference here].

Alas, they list the autofix support as partial/experimental.


This is neat, but:

`npm install stylelint --save-dev`

I really wish people wouldn't write cli tools in Javascript. Npm is a disaster and will pollute my system with all kinds of dependency libraries if I run the above command. It would be great to see more tools like this written in Go, Rust or something else that compiles to a static binary.


* on the command line

* in your text editor, for example in VS Code

* in for your build tool, for example in webpack

* via the Node.js API

* as a PostCSS plugin

^ If I was trying to meet compatibility with the above requirements I'd probably pick JS too.

It's easy to complain about npm but the fact is it get so much done every day. I don't want to be compiling binaries and all the compatibility crap that goes on there. I have no problem with well written JS or Typescript.

Yes NPM dependency can be a bit crazy, but it doesn't pollute your system. Using nvm everything is contained in a modules directory. I can literally delete that folder and be back to square one in two seconds flat. Compiling binaries, well, that's where I feel like you end up pulling your hair out.

I have to compile binaries for a certain version of a capybarra gem, to do that I had to roll back x-code. Never had to do anything like that for a straight forward npm.


I'm not so sure that'd be a good idea. A few questions:

1. what benefits would a statically compiled binary provide? Would it be significantly faster? Would it be easier to manage? Would it be easier to modify?

I'd guess the answers to those last 3 would be "yes, but not significantly so", "no" and "no" respectively, but that is a complete guess.

2. Would it be cross-platform?

I work in windows and macos, our CI server uses linux. Would your alternate languages/methods work across all those platforms? if not it's almost a non-starter, because we aren't going to require our devs and CI system change entirely to accommodate one smaller package.

3. how would it be installed and kept up to date?

NPM has the tooling built up for managing this. We have a bot that can ping when new versions come out after a delay, we can see install numbers and gauge when it's safe to install vs when it's brand new and still might be buggy or have un-found issues. We have CLI tooling that can parse the package.json and determine what is out of date, and in one command can update many of them and have the tests run to ensure there aren't any major breakages.

Would your method work on all platforms? How would it differ per platform? Can I install it without having to install and setup the developer tools for Go and Rust?

NPM isn't perfect, but it does a LOT of things right. Being able to `npm install` something, have it go to a local folder, then have it just run on all platforms is one that it does VERY right in my opinion. It's installed alongside node.js, and the install process is quick and painless in 99% of cases. And considering this tool is probably fast enough as-is in javascript right now, I don't think there would be any significant gains by rewriting it in some other compiled language to offset the downsides (like not being able to easily inspect and modify the code that was installed, which I have done on many occasions to find and fix bugs in 3rd party libraries).


I think these are good questions, and I agree with them regarding the downsides of binaries.

I do think there’s an interesting path here though, and that’s writing said tooling in a language like Rust, but distributing it in an npm package and have it pre-compiled as webassembly. It still feels native to JS people, you don’t have to deal with cross-platform issues, but you gain static typing and speed. There are other aspects of it too, like more consistent performance, and lower memory usage...

Interesting times!


And that's why I tried to avoid saying it's a bad idea in general.

I'd love to see more diversity in languages on NPM. Things written in Go but compiled and distributed as binaries over NPM (maybe with a small JS wrapper), or things written in Rust but compiled to wasm and distributed over NPM.

If the compilers in those other languages get a bit better at outputting WASM or JS, we get closer to the idea of being able to really use the best language/tool for the job, then cobble them all together near the end to make one truly great product where each part is written in a language which is best suited to the sub-task it's doing!


Agreed on WebAssembly... I'm thinking/hoping that a number of binary packages will be migrated to, or at least tested via webassembly. There are some modules in C that are impossible via webassembly, but a great number of them are.

Having the wasm versions in npm could be really useful.


I’d like to point out here that Sass was originally a Ruby gem.

It was then reimplemented in C and released as Libsass for a significant performance gain.


But it was again rewritten in Dart and the Dart version is now the reference implementation. And they did that because for a lot of Sass users, working with Ruby sucked, simply because they didn't have the tooling and knowledge built up to handle it correctly.

Libsass's main "claim to fame" is that just about all languages (including Javascript on the backend) can interop with C/C++ pretty effortlessly. The rewrite was more about enabling more and more users to use the languages and package managers they are used to rather than about speed (especially since the Dart SASS implementation is quite often FASTER than the libsass version!) Take a look at the Sass perf benchmarks below for more info:

https://github.com/sass/dart-sass/blob/master/perf.md

Although keep in mind that a lot of the performance benefits go away when you run Dart Sass via javascript compilation in regular node. But IMO that gives you a lot of choice. You can get the best performance by installing the Dart toolchain and running it "natively" on dart, or you can run it via node for "okay" speed in most cases, or you can deal with native compilation via C/C++ and libsass for a mix of both. It's a nice setup they have going on over there!


I’m not really disputing any of that.

My point is that the performance benefit of implementing a web UI build tool in a compiled language is not always insignificant.

And as you conceded in another comment in the thread, you can use npm to distribute pre-compiled binaries, so I don’t think the “it’s too cumbersome to download a binary” argument holds much water either.


We are on the same page! If the binaries are distributed over npm and work well in the npm ecosystem, them I'm all for it! My only reservations are about blindly writing things in compiled languages, or not using package managers at all because it's easier to distribute, which I don't think it is.

One of the really good things sass did with the rewrite in dart was make the default installable package include the dart VM along with it. So the install process is almost identical to any other JS package, which is why IMO they did such an amazing job with it


The Purescript compiler is built in Haskell, and they use NPM to distribute the binaries. npm i -g purescript fetches a platform-appropriate binary and installs it.

I'm not affiliated with the project (I just dabbled briefly), but I would guess writing a language like Purescript in Haskell would probably be easier than writing it in Javascript.


If it was written in a compiled language you could just copy the binary over to your system. You wouldn't even have to mess around installing the language or build tools.

Golang and Rust are both very cross platform and compile to Mac/Linux/Windows natively.

The main benefits to using a more modern language would be:

1. Easier distribution (like I said, just copy a binary)

2. Better performance (but like you said, often doesn't matter)

3. Much better code (subjective, but static typing offers real benefit as does having a very nice standard library).


But when 99% of your target audience (in this case JS and web developers) already have the runtime installed, then "just copy a binary" isn't easier, it's harder.

`npm install stylelint` is about as easy as it gets. copying a binary requires you to put it somewhere, make sure your path is setup correctly, find a way to automatically install it (or put it in the repo causing the size of the repo to bloat), and ensure you are downloading the right version for each platform.

And you still didn't address the other issues. How do you know when it has an update, or a security update! NPM warns you if the author deprecates a package version with big yellow warnings when you do something letting you know it's unsupported and has security issues. A binary won't do that.

And then you still have the issue of being unable to modify the code, or even see the code on your system.

And "much better code" is subjective as hell! Go sucks to work with and read for some because it's a bit verbose, especially when dealing with errors and some of the hoops that have to be jumped through to handle or make generic functions. Rust is a HUGE language IMO, I've never used it professionally, but I've been trying to learn it and every single time I see a rust codebase I'm looking up new syntax or some other feature I didn't know about. That's not to say those are 2 bad languages, but that all languages have their downsides. JS is no different, but again when your target audience is 99% devs that use JS on a daily basis, other languages, no matter how easy to understand and use, are going to be harder to work with for them.

I'd love to see more diversity in this area, but if you are telling me to "download and run this binary" as the install method, it's probably not going to be included in an app that I manage, because there's too much extra work that has to be handled, like installing it automatically on the CI server, installing it locally for devs, keeping it up to date, checking it for security issues or problems (if the dev even reports them), and a lot more.


The just copy it argument doesn't really fly as far as Linux, Windows, Mac too. Not to mention incompatible versions of said OSes alone, not to mention others.

While I wouldn't mind seeing more libraries as wasm for use with node in npm, I don't think the case is really made to have to have even broader tooling to use it alone. I mean, I still don't get why Python hasn't been displaced in Node.


Having to copy a binary is a downgrade. NPM is an xplat distribution platform.

The majority of projects that would use this already use NPM to version their other tools/linters/formatters like eslint and prettier. So now this one tool doesn't integrate with their tooling. For very little upside beyond appeasing a few people on HN.

When you build something, you have to think about more than just your idea of absolute technical superiority. Distribution and toolchain integration and an understanding of your end-users are just as important. Also, would they have the same plugin ecosystem if they hadn't used NPM nor Javascript? https://stylelint.io/user-guide/plugins/


> 1. Easier distribution (like I said, just copy a binary)

I'm not sure how your system is setup, but most of us already have npm installed and using a package manager is about as simple as it gets to distribute tools. Since it's on npm you don't have to worry about apt, brew, or yum distributions. Just the one that is already installed on everyone's machine who will probably be using this, regardless of stack or OS.

Your other 2 points are moot. You don't get to pick the tools of other projects.


When I worked at a web agency as a dedicated front-end developer, the projects would use any language from .NET, PHP, Ruby, etc. I don't want to depend on the back-end of the project in my front-end stack.

All of my work in the front-end ecosystem is made using JS+CSS. Why would I want to install Go or Ruby to build those? Running JS to manage my JS and CSS makes more sense...

One big bonus being that I can actually lift the hood and tweak my build system because it uses the same language as the one it will be parsing.


You just reminded me of a really good point. We already have "previous examples" of people trying to make CSS tooling in another language!

sass was written in ruby originally, and it sucked so much to manage and work with for many devs that they literally re-wrote the ENTIRE thing in Dart so they could gain the benefits of the JS ecosystem (like npm)!

It isn't a compiled language, but it is an example of someone having done this at least once, and ending up regretting it to the point that they spent multiple years rewriting it in a language that compiles to JS and deprecated the ruby version.


Indeed, requiring Ruby to build SCSS files used to be a pain.

Every other part of our toolchain was done via NPM. You could install all of it in seconds via one command... and then people had to hunt the correct and compatible Ruby binaries for their system.

Our .NET developers on Windows hated this. "Why do I need to install Ruby to build your front-end?!"

Dart Sass was a godsend.


Afaik with that command you will not pollute the rest of the system, since there is no global flag. It will end up in node modules/.bin and can be executed with npm scripts.


Or "npx".


I still find that pretty tacky. Is there a reason someone would build something like this in JS instead of a more suitable language? I get that front-end developers probably know JS best from a user perspective it's a bad language choice just from the distribution alone.


Unfortunately, we live in a free society where I need to base all my actions on keeping myself employable. This means I'll spend 4 hours writing a small tool in JS instead of 1000 hours trying to learn semantic modern c/c++/rust/golang. That's 990 hours I could spend making more tools, learning new technologies that employers would find relevant on my resume, or spending time with friends and family.


No it's not. The problem is you're grossly misinformed about languages in general (a more suitable language? wtf?). There's nothing wrong with NPM and distributing packages used by the majority of the ecosystem. And for all of NPM's problems, it works literally better than every other garbage package manager. But I suspect your criticism is more because you read some comments about NPM, not that you know what you're talking about.


I kinda agree about JS CLI tools. However, I'm guessing the target market is JS-led front-end developers. Installing via npm makes it simpler to drop in to a toolchain that's already oriented around npm.

Not saying that's right or optimal, of course.


Not to mention that JS isn't an inherently bad language in the first place. Which is an absurd presumption. Most languages have some nice, good and really ugly parts in practice. Modern JS is pretty nice to work with, and often I can get far more done with it far faster than with anything else I would choose.

Node + NPM are second to none in terms of productivity IMHO. I've used and worked with other languages and tools and find that JS tooling is just plain less friction most of the time.

If I had to switch contexts to 3-4 other languages day to day again, I'd hate it... I remember it being so bad working with 3-4 languages every day that It'd sometimes take me 2-3 minutes just to be able to actually listen to a question by a peer and be able to answer. It can not be underestimated.

Node tooling is probably not the best at anything... that said, it's good enough for almost everything.


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 ...


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.


Could you expand on why you use gulp-shell when you presumably have the ability to run shell scripts directly?


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.


Right, but then why not use bash by itself? Why wrap it in JavaScript at all?


I'm not typing [this][1] often if I can help it.

[1]: https://raw.githubusercontent.com/chrisfinazzo/blog/master/g...


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


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.


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.


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.


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.


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.


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?


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.


> If you can't grasp this, then we can't get anywhere.

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.


[flagged]


Wow. Groundbreaking stuff!

Take your ad hominems elsewhere, thanks.


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.


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.


> 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.


Why do you say that?


You're making some kind of distinction of a web developer just being someone who splices designs in Dreamweaver or something.

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.


I don’t know where you’re getting any of that. If you really had read all my comments, you may have caught the bit where I said:

> This isn’t a dig at web developers either (like I said, I am one)


Who exactly do you think is making tooling like npm, webpack, babel..? It's web developers, dog-fooding their own tools. Sure, many more will use than make, but that's true of EVERY tool that is made.

Do you think the majority of people using make contribute to writing make?


> Who exactly do you think is making tooling like npm, webpack, babel..?

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?


Aside: every open-source project I've worked on that uses make as it's primary script/build pipeline interface doesn't work correctly on mac, windows or many linux environments.

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.


I write tools. I choose to write in the platform(s) of MY choice. 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.


You're a "web developer" and JavaScript is not something you're familiar with?


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.


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.


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.


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.


eslint is written in JS, and runs over codebases far larger than people are likely to have in terms of stylesheets and runs fine. Do you have evidence that this tool will not run in under a second on a single file, or within an acceptable timeframe over a project?

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.


I wonder if CLI tools could be put into a single zipfile with all the dependencies inside and just ran from there. Just like php's phar files.

Or even better, compile into a wasm binary.


There are things like nexe[1] and pkg[2] but the resulting executables end up pretty bloated (30+ MBs for a simple hello world, cause they all end up bundling Node in some way with every executable). nexe doesn't support native Node modules either, IIRC.

[1] https://github.com/nexe/nexe [2] https://github.com/zeit/pkg


1. Yes. If your CLI tool is written entirely in JS, you can even bundle all files into a single file and ship the JS file. With native dependencies, you need to use other solutions. 2. Compile into a wasm binary is not possible because JS is an dynamically typed language. No type at compilation time


And when you need to support Linux, Windows and Mac for developers?


They still need to install Node. This is just a zip file that Node would run that contains all the dependencies inside the zip.


So, you need to include the linux, windows and mac versions in your zip file at the very least for binary dependencies?


With a interpreted language you do not have to worry about losing the source code. Static binaries can also be large.


I don't understand why this comment is so downvoted. It's a very valid point.


Mainly because it's a bit condescending, elitist and snobby. There's very little reason for a tool surrounding front end development to not be built/deployed with the vast majority of tooling for front end development outside of ignorance, arrogance or both.

Most people don't respond well to willful ignorance or excessive arrogance.


For one thing, a significant portion of it is completely wrong, which makes the sibling comment by yakshaving_jgt particularly rich.




Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: