9 ms·

One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible.

One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible. I also think that anything js-adjacent has a real culture problem. Trying to dredge an answer out of a Medium tutorial written in a cloying tone and interspersed with pointless gifs can be such a groan enducing experience. I'm hoping that the community will mature alongside its technology.

BossingAround 7y ago
What you're mentioning is all just a side effect of something being extremely accessible. Webdev is very easy to start and get into, but on the deep end, it's just as deep and difficult as coding a backend of your application in Java or Go. You don't have to search the internet for web dev any more than you have to do so for any other dev job.
noir_lord 7y ago
Couldn't agree more. All that and emojii's sprinkled everywhere like cat vomit.
snazz 7y ago
Man pages rarely are enough in my experience. When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page. You’ll have better luck using the ArchWiki, which is like a much better man page, but a simple Google search (or another search engine) will show a forum post with an easy solution as the very first result. Piping six man pages through grep to find what I’m looking for is simply not as fast as Googling an error message. I think there’s also a sort of cultural difference between languages and tools frequented by newer and older programmers: more experienced people look for documentation and then get working on their project, whereas less experienced programmers look for tutorials and very specific “soft” documentation. Transitioning from modifying tutorials (the type-in-the-code-in-the-magazine of the 21st century) to glancing at the documentation is probably the surest sign of maturity. Still, you can get a ton done by copypasta. This might have to do with learning to code with or without the Internet, I’m not sure. I’m personally very envious of people who can take a look at the docs and just get chopping without the assistance of the GIF-covered Medium posts.
- klez 7y ago
  > When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page This says more about the man pages for grub2 (and grub2 itself, to be honest) EDIT: than about manpages /EDIT. Compare them with the man pages for grub1. There's a sea of difference. If you really want to be blown away by a manpage, look for the one for mplayer, which is difficult to find information in for different reasons, i.e., lots of options and lots of options and flags that depend on other flags and options.
- umanwizard 7y ago
  Yet another reason to prefer the BSD family of OSes over the GNU/Linux family. In the BSDs, self-contained, complete, and correct documentation is a cultural value. Not one that’s always achieved, but a value nonetheless. Information missing from the man pages is a reportable bug. And if the man page doesn’t document something, its code is right there in /usr/src for you to dig into.
  - jnbiche 7y ago
    Agreed. Even in Linux, complete documentation for userland tools is usually a given. Not so with webdev. That said, the source code is there for all of us to read. I'm a frontend developer and spend more time looking at source code when I need to figure out an issue than digging through Medium posts. Particularly when something is behaving in an unexpected manner. I'd urge everyone who hates webdev to try this approach the next time they struggle with an issue. JavaScript, for all its sins, is fairly easy to read. And once you've understood the ~30 most common gotchas in JS, reading the source is highly beneficial (and here's a good intro to those gotchas, including an accompanying video: https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs) Or better yet, work in one of the statically-typed compile-to-JS languages such as Typescript, ReasonML, Elm, ScalaJS, or Purescript and worry about those gotchas much less (and only when wrapping external libraries).
lazerwalker 7y ago
Do you personally have recs for how to parse manpages? In my experience, I've found them far more difficult to grok than e.g. the MDN JavaScript docs. Particularly if I'm trying to look up a tool that I don't already have familiarity with, as opposed to e.g. just trying to look up the correct syntax for a flag.
- hombre_fatal 7y ago
  Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation. Like reading the entire wikipedia entry on cats just to settle a dispute on how many toes they have (18 btw). I think manpages are a popular thing to worship here for nerd points but people don't use them nearly as much as they say they do because nobody actually wants to read a manual when they are trying to Get Things Done. Also, some things are just incredibly hard to figure out, like ffmpeg arguments. Check out http://bropages.org/ http://bropages.org/
  - anthk 7y ago
    Bro pages are a joke compared to the conciseness of man pages under OpenBSD.
  - flukus 7y ago
    > Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation. Because manpages are from a time when reading the manual was expected behavior, searching for a quick incantation more often than not results in learned helplessness because you don't actually learn anything, just the specific spell for the specific situation. I'm as guilty as anyone of trying to solve the immediate problem with a magic spell at times, but bropages embrace this willful ignorance.
    - your-nanny 7y ago
      not to make fun of my old roommate, but I had to give him line by line instructions for him to use a scientific calculator, which he dutifully copied, instead of taking the time to learn calculator principles. know your tools.
awinder 7y ago
I’d honestly love to know what people are comparing to javascript when they complain about rate of change / having to learn, unless it’s just a mental bias on learning something new vs something they’re comfortable with. I’m in a new position working on python and spring APIs and it’s effectively the same deal — researching means filtering through bitrotted methods and advice over a 4-5 year period, new methods & libraries or api usage patterns, etc. Anyone could divine some reasons for why javascript / “web dev” is so different but I’m seeing shades of the same thing mixed with personal biases towards trade offs and design decisions.
- klez 7y ago
  Try C. You can find stuff from 20 years ago and it's still mostly relevant. Or at least applicable.
  - awinder 7y ago
    This is what I’m talking about with this argument being a proxy against learning vs a legitimate difference. I just replaced a big chunk of a 20 year old C system this year. There was nothing even researchable in there because the vast majority was homegrown, or libraries were pulled in and source-modified after going stagnant on the 20 year journey. Same exact symptoms I’ve seen in every other ecosystem.
- MarkMc 7y ago
  I've been programming mostly in Java for 20 years, and in the past whenever I picked up web development it always felt like a kludge. JavaScript was inferior to Java, CSS was frustratingly difficulty to lay out components, and HTML forced me to treat my application like a printable document. Tools and libraries weren't as efficient or robust. Then I had to test on 5 different OS/browser combinations and implement ugly workarounds to fix the inevitable discrepancies between platforms. Recently I've been developing in Flutter/Dart, and it's so enjoyable. The Dart language is an improvement on Java, the Flutter documentation and online support is great, apps look and behave the same on different devices, the API and underlying code is well designed. Plus the tooling and IDE integration is first-class.
- 7y ago
braythwayt 7y ago
Speaking as someone who writes blog posts littered with irrelevant pictures (but never on Medium!), I acknowledge your experience trying to solve a problem based on a blog post. Manpages and documentation are written to be references. Blog posts are written to be tutorials. They have different affordances, and as a result it is very hard to learn how to use something purely from a reference, and very different to solve a problem purely from a tutorial. That’s why really decent reference sites have both step by-step tutorials AND references designed to answer questions quickly and to be easily searchable. If there is an opportunity here, it is for search to understand the difference and know how to present the two kinds of results differently. That way, if you question is, “How does this thing work?” You should get tutorials. If your question is much more specific, like “what parameters does this take?” You should get a reference. Or something hand-wave-y along those lines.
- pteraspidomorph 7y ago
  For js and js-adjacent technologies or libraries, there sometimes aren't any references to speak of, unfortunately. You're supposed to divine the information you need from task-oriented texts and code snippets.
  - klez 7y ago
    Or, if you're using an obscure library, by reading the source code.
  - braythwayt 7y ago
    Look, Sturgeon's Revelation is that "90% of everything s CRUD." That's true of almost every technology I've encountered in 45 years of programming. It's especially true when you lower the bar to entry. There's lots of CRUD because anybody can make something. It also means there are lots of things. If you want well-documented stuff, vote for it by not using things that are poorly documented. Or figure it out and write the documentation. That's how open source works (or doesn't work), and JS/Webdev is not unique in this regard. Microcomputers were poorly documented way back in the 70s. I'll be there were people complaining how shoddy they were on that basis, but that low barrier to entry led directly to us having this discussion on Hacker News today.
bobthepanda 7y ago
The MDN is a pretty good reference complete with availability tables for browsers. The problem with a reference is that a lot of times browsers do quirky things and things that are essentially browser-specific bugs aren’t documented in a reference.
bdcravens 7y ago
I feel this is less the case than it was a few years ago, but a lot of the same complaints can apply to the Rails ecosystem.
CondensedBrain 7y ago
https://devdocs.io/ https://devdocs.io/ isn't exactly equivalent to manpages, but works well enough. You can even download documentation for offline use.
- rzzzt 7y ago
  Thank you for posting this! Parent's comment reminded me of this page, but couldn't remember the URL...
markbnj 7y ago
> One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible. I don't really get this response. First there's the notion that "webdev" is the discipline where information is so fractured that you need to go googling around to figure out how to do everything. All the other disciplines have a magic thing called a man page that just gives you the answers. This is obviously not true, right? The second thing is the idea that a man page for any one component, or even a set of components, could possibly contain enough information to allow you to build a complex system without consulting the experience of peers, colleagues and past practitioners, which is at least what we intend to do when we search google.
- tenaciousDaniel 7y ago
  Also the "manpage" does exist - it's the spec. But I've never met a single person who has ever directly read it.
  - RussianCow 7y ago
    MDN does a pretty good job of distilling the web spec into readable documentation: https://developer.mozilla.org/en-US/ https://developer.mozilla.org/en-US/
    - mgkimsal 7y ago
      it's so 'readable' that a friend of mine is... reading it. Out loud. In to Soundcloud. (well, JS stuff anyway). https://soundcloud.com/user-956222694 https://soundcloud.com/user-956222694
  - err4nt 7y ago
    I'm in the HTML specs and CSS specs every day :D - https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ - https://drafts.csswg.org/ https://drafts.csswg.org/
  - Retric 7y ago
    Reading web specs at least once will save you a lot of time. You don’t need to memorize the things, but it helps learning about capabilities that are easy to miss and keywords that’s make searching far more efficient.
MaxBarraclough 7y ago
> I'm hoping that the community will mature alongside its technology. Which technology? Web development frameworks seem to have a half-life of about 12 months. 'Mature' and 'obsolete' are near synonymous.
- jhoh 7y ago
  > Web development frameworks seem to have a half-life of about 12 months. Initial realeases of the most popular JS-frameworks: Angular – 2010 React – 2013 Vue – 2014
  - MaxBarraclough 7y ago
    Polymer 0.5 - circa 2014 Polymer 1 - 2015 Polymer 2 - 2017 Polymer 3 - 2018 LitElement - 2019 (I'm aware that Polymer insists it isn't a 'framework'. But it is. If their breaking changes cause incompatibilities between components using different Polymer versions, that's what I call a 'framework'.)
    - MaxBarraclough 7y ago
      *also the ~recent deprecation of Bower
  - Pxtl 7y ago
    Angular doesn't count as 2010 because they did massive compatibility breaking change to Angular2 such that it was basically a new framework.
- deiznof 7y ago
  This really just isn't true about the javascript scene anymore, and hasn't been for a little while now. React and Angular alone make up the vast majority of framework usage and they've been out for years. Honestly, a lot of javascript criticism I see nowadays is a little outdated.
  - MaxBarraclough 7y ago
DonHopkins 7y ago
I hope you're not advocating writing documentation in troff instead of html!
hiccuphippo 7y ago
It would be very nice if the whole MDN could be downloaded as man pages or even just html pages with some form of local search.
kyriakos 7y ago
the worst kind is youtube tutorials disguised as blog posts. you open the link, there's 5 lines of intro and then an embedded video. and I hate videos cause usually skimming through text you can get to the part you want to read quickly but with videos you need to go through it
onion2k 7y ago
You can access MDN as man pages - https://github.com/rafaelrinaldi/mdn https://github.com/rafaelrinaldi/mdn
jimmaswell 7y ago
Man page: find the man page, search for terms you hope might be related to what you want, read through a lot of dense paragraphs to maybe find something relevant. Google: just type in a quick description of your issue and get a stackoverflow post with an answer as the first result. I don't get how anyone could prefer the man page.
- umanwizard 7y ago
  For me the issue is not really whether I access the docs through `man` or through the browser. It’s comprehensive, accurate docs provided in one place by the vendor of the tool I’m using, versus wading through a crowdsourced resource like SO which might be incomplete, out of date, or inaccurate. If a library vendor provides good docs on their website, that’s just as good as man pages, but in my experience they usually don’t. There is a staggering amount of misinformation or non-existent information on Stack Overflow. For one simple example: try to figure out how to use the GPS on iPhone. It’s simply impossible. 99% of people on SO think “GPS” is synonymous with “Location APIs” in general. Of the 1% of people who understand the several different data sources used by CoreLocation, nobody can tell you which accuracy settings will cause it to use GPS specifically. If you bother asking, you’ll get a bunch of “middle-brow dismissals” asking why you want to know such a thing, telling you to just use whatever accuracy setting you semantically need, smugly claiming you’re guilty of posing an A-B question, and so on. This is the type of dead simple basic information I would have expected to be present in Apple’s documentation, instead of having to crowdsource it from internet trolls.
  - Theodores 7y ago
    Stack Overflow has a problem of outdated answers written ten years ago by people wanting to collect experience points. Technology moves on and those early answers are simply no good. Recently I decided to learn a few things from first principles - reading the specs. If I then try to put a half decent answer on SO then it will be answer 97, 3563 upvotes behind the 'right answer'. New person who comes along isn't going to get to my detailed answer on page 5, the one that points out how technology has moved on and why the winning answers are not what you needed. They just need to deliver the deliverables and the first answer will suffice. They will take it and add another plus to the upvotes. You can't win, the odds are stacked in favour of the mediocre. This wasn't always the way with Stack Overflow, in fact it replaced forums where the same problem existed but only to stall the nonsense for a few years, we are back to peak nonsense again. I think time is ripe for Stack Overflow to be usurped, nothing against the site which I have so loved over the years, but even mySpace had to be replaced by Facebook.
baroffoos 7y ago
I find manpages to be mostly useless because they ignore the common case to explain every single possible function. For example I use the tar command 99% of the time for extracting files and 1% of the time compressing files. When I open the manual I want to be able to quickly work out how to extract a file but the first bit of non intro text on the man page is >Options to GNU tar can be given in three different styles. In traditional style, the first argument is a cluster of option letters and all subsequent arguments supply arguments to those options that require them. The arguments are read in the same order as the option letters. Any command line words that remain after all options has been processed are treated as non-optional arguments: file or archive member names. For example, the c option requires creating the archive, the v option requests the verbose operation, and the f option takes an argument that sets the name of the archive to operate upon. The following command, written in the traditional style, instructs tar to store all files from the directory /etc into the archive file etc.tar verbosely listing the files being archived: Scanning through the manpage a fair way down and I can't see the one bit info that covers almost all of my use cases for tar. And for anything more complex than a tiny cli tool the manpage is far too large to use usefully.
- detaro 7y ago
  For the specific example of tar, the EXAMPLES section of the man page covers what I typically need, but that's not true for all man pages.
  - baroffoos 7y ago
    For some reason my copy of the tar manpage on fedora has no examples section
- your-nanny 7y ago
  one of the very first thing in tar's man page is an example of how to extract a file: https://linux.die.net/man/1/tar https://linux.die.net/man/1/tar but what evs. sometimes the man page is the thing, sometimes not.
- em-bee 7y ago

BossingAround 7y ago

What you're mentioning is all just a side effect of something being extremely accessible. Webdev is very easy to start and get into, but on the deep end, it's just as deep and difficult as coding a backend of your application in Java or Go. You don't have to search the internet for web dev any more than you have to do so for any other dev job.

noir_lord 7y ago

Couldn't agree more. All that and emojii's sprinkled everywhere like cat vomit.

snazz 7y ago

Man pages rarely are enough in my experience. When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page. You’ll have better luck using the ArchWiki, which is like a much better man page, but a simple Google search (or another search engine) will show a forum post with an easy solution as the very first result. Piping six man pages through grep to find what I’m looking for is simply not as fast as Googling an error message. I think there’s also a sort of cultural difference between languages and tools frequented by newer and older programmers: more experienced people look for documentation and then get working on their project, whereas less experienced programmers look for tutorials and very specific “soft” documentation. Transitioning from modifying tutorials (the type-in-the-code-in-the-magazine of the 21st century) to glancing at the documentation is probably the surest sign of maturity. Still, you can get a ton done by copypasta. This might have to do with learning to code with or without the Internet, I’m not sure. I’m personally very envious of people who can take a look at the docs and just get chopping without the assistance of the GIF-covered Medium posts.

klez 7y ago
> When I encounter an issue with grub-install not writing to my EFI system partition, good luck finding much about it in its very short man page This says more about the man pages for grub2 (and grub2 itself, to be honest) EDIT: than about manpages /EDIT. Compare them with the man pages for grub1. There's a sea of difference. If you really want to be blown away by a manpage, look for the one for mplayer, which is difficult to find information in for different reasons, i.e., lots of options and lots of options and flags that depend on other flags and options.
umanwizard 7y ago
Yet another reason to prefer the BSD family of OSes over the GNU/Linux family. In the BSDs, self-contained, complete, and correct documentation is a cultural value. Not one that’s always achieved, but a value nonetheless. Information missing from the man pages is a reportable bug. And if the man page doesn’t document something, its code is right there in /usr/src for you to dig into.
- jnbiche 7y ago
  Agreed. Even in Linux, complete documentation for userland tools is usually a given. Not so with webdev. That said, the source code is there for all of us to read. I'm a frontend developer and spend more time looking at source code when I need to figure out an issue than digging through Medium posts. Particularly when something is behaving in an unexpected manner. I'd urge everyone who hates webdev to try this approach the next time they struggle with an issue. JavaScript, for all its sins, is fairly easy to read. And once you've understood the ~30 most common gotchas in JS, reading the source is highly beneficial (and here's a good intro to those gotchas, including an accompanying video: https://github.com/denysdovhan/wtfjs https://github.com/denysdovhan/wtfjs) Or better yet, work in one of the statically-typed compile-to-JS languages such as Typescript, ReasonML, Elm, ScalaJS, or Purescript and worry about those gotchas much less (and only when wrapping external libraries).

lazerwalker 7y ago

Do you personally have recs for how to parse manpages? In my experience, I've found them far more difficult to grok than e.g. the MDN JavaScript docs. Particularly if I'm trying to look up a tool that I don't already have familiarity with, as opposed to e.g. just trying to look up the correct syntax for a flag.

hombre_fatal 7y ago
Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation. Like reading the entire wikipedia entry on cats just to settle a dispute on how many toes they have (18 btw). I think manpages are a popular thing to worship here for nerd points but people don't use them nearly as much as they say they do because nobody actually wants to read a manual when they are trying to Get Things Done. Also, some things are just incredibly hard to figure out, like ffmpeg arguments. Check out http://bropages.org/ http://bropages.org/
- anthk 7y ago
  Bro pages are a joke compared to the conciseness of man pages under OpenBSD.
- flukus 7y ago
  > Yeah, manpages feel like the equivalent of being served a book on a subject where I just want to know a quick incantation. Because manpages are from a time when reading the manual was expected behavior, searching for a quick incantation more often than not results in learned helplessness because you don't actually learn anything, just the specific spell for the specific situation. I'm as guilty as anyone of trying to solve the immediate problem with a magic spell at times, but bropages embrace this willful ignorance.
  - your-nanny 7y ago
    not to make fun of my old roommate, but I had to give him line by line instructions for him to use a scientific calculator, which he dutifully copied, instead of taking the time to learn calculator principles. know your tools.

awinder 7y ago

I’d honestly love to know what people are comparing to javascript when they complain about rate of change / having to learn, unless it’s just a mental bias on learning something new vs something they’re comfortable with. I’m in a new position working on python and spring APIs and it’s effectively the same deal — researching means filtering through bitrotted methods and advice over a 4-5 year period, new methods & libraries or api usage patterns, etc. Anyone could divine some reasons for why javascript / “web dev” is so different but I’m seeing shades of the same thing mixed with personal biases towards trade offs and design decisions.

klez 7y ago
Try C. You can find stuff from 20 years ago and it's still mostly relevant. Or at least applicable.
- awinder 7y ago
  This is what I’m talking about with this argument being a proxy against learning vs a legitimate difference. I just replaced a big chunk of a 20 year old C system this year. There was nothing even researchable in there because the vast majority was homegrown, or libraries were pulled in and source-modified after going stagnant on the 20 year journey. Same exact symptoms I’ve seen in every other ecosystem.
MarkMc 7y ago
I've been programming mostly in Java for 20 years, and in the past whenever I picked up web development it always felt like a kludge. JavaScript was inferior to Java, CSS was frustratingly difficulty to lay out components, and HTML forced me to treat my application like a printable document. Tools and libraries weren't as efficient or robust. Then I had to test on 5 different OS/browser combinations and implement ugly workarounds to fix the inevitable discrepancies between platforms. Recently I've been developing in Flutter/Dart, and it's so enjoyable. The Dart language is an improvement on Java, the Flutter documentation and online support is great, apps look and behave the same on different devices, the API and underlying code is well designed. Plus the tooling and IDE integration is first-class.
7y ago

braythwayt 7y ago

Speaking as someone who writes blog posts littered with irrelevant pictures (but never on Medium!), I acknowledge your experience trying to solve a problem based on a blog post. Manpages and documentation are written to be references. Blog posts are written to be tutorials. They have different affordances, and as a result it is very hard to learn how to use something purely from a reference, and very different to solve a problem purely from a tutorial. That’s why really decent reference sites have both step by-step tutorials AND references designed to answer questions quickly and to be easily searchable. If there is an opportunity here, it is for search to understand the difference and know how to present the two kinds of results differently. That way, if you question is, “How does this thing work?” You should get tutorials. If your question is much more specific, like “what parameters does this take?” You should get a reference. Or something hand-wave-y along those lines.

pteraspidomorph 7y ago
For js and js-adjacent technologies or libraries, there sometimes aren't any references to speak of, unfortunately. You're supposed to divine the information you need from task-oriented texts and code snippets.
- klez 7y ago
  Or, if you're using an obscure library, by reading the source code.
- braythwayt 7y ago
  Look, Sturgeon's Revelation is that "90% of everything s CRUD." That's true of almost every technology I've encountered in 45 years of programming. It's especially true when you lower the bar to entry. There's lots of CRUD because anybody can make something. It also means there are lots of things. If you want well-documented stuff, vote for it by not using things that are poorly documented. Or figure it out and write the documentation. That's how open source works (or doesn't work), and JS/Webdev is not unique in this regard. Microcomputers were poorly documented way back in the 70s. I'll be there were people complaining how shoddy they were on that basis, but that low barrier to entry led directly to us having this discussion on Hacker News today.

bobthepanda 7y ago

The MDN is a pretty good reference complete with availability tables for browsers. The problem with a reference is that a lot of times browsers do quirky things and things that are essentially browser-specific bugs aren’t documented in a reference.

bdcravens 7y ago

I feel this is less the case than it was a few years ago, but a lot of the same complaints can apply to the Rails ecosystem.

CondensedBrain 7y ago

https://devdocs.io/ https://devdocs.io/ isn't exactly equivalent to manpages, but works well enough. You can even download documentation for offline use.

rzzzt 7y ago
Thank you for posting this! Parent's comment reminded me of this page, but couldn't remember the URL...

markbnj 7y ago

> One of the things I don't like about webdev (among many) is that I even have to Google in the first place. Manpages are so much more immediate and accessible. I don't really get this response. First there's the notion that "webdev" is the discipline where information is so fractured that you need to go googling around to figure out how to do everything. All the other disciplines have a magic thing called a man page that just gives you the answers. This is obviously not true, right? The second thing is the idea that a man page for any one component, or even a set of components, could possibly contain enough information to allow you to build a complex system without consulting the experience of peers, colleagues and past practitioners, which is at least what we intend to do when we search google.

tenaciousDaniel 7y ago
Also the "manpage" does exist - it's the spec. But I've never met a single person who has ever directly read it.
- RussianCow 7y ago
  MDN does a pretty good job of distilling the web spec into readable documentation: https://developer.mozilla.org/en-US/ https://developer.mozilla.org/en-US/
  - mgkimsal 7y ago
    it's so 'readable' that a friend of mine is... reading it. Out loud. In to Soundcloud. (well, JS stuff anyway). https://soundcloud.com/user-956222694 https://soundcloud.com/user-956222694
- err4nt 7y ago
  I'm in the HTML specs and CSS specs every day :D - https://html.spec.whatwg.org/multipage/ https://html.spec.whatwg.org/multipage/ - https://drafts.csswg.org/ https://drafts.csswg.org/
- Retric 7y ago
  Reading web specs at least once will save you a lot of time. You don’t need to memorize the things, but it helps learning about capabilities that are easy to miss and keywords that’s make searching far more efficient.

MaxBarraclough 7y ago

> I'm hoping that the community will mature alongside its technology. Which technology? Web development frameworks seem to have a half-life of about 12 months. 'Mature' and 'obsolete' are near synonymous.

jhoh 7y ago
> Web development frameworks seem to have a half-life of about 12 months. Initial realeases of the most popular JS-frameworks: Angular – 2010 React – 2013 Vue – 2014
- MaxBarraclough 7y ago
  Polymer 0.5 - circa 2014 Polymer 1 - 2015 Polymer 2 - 2017 Polymer 3 - 2018 LitElement - 2019 (I'm aware that Polymer insists it isn't a 'framework'. But it is. If their breaking changes cause incompatibilities between components using different Polymer versions, that's what I call a 'framework'.)
  - MaxBarraclough 7y ago
    *also the ~recent deprecation of Bower
- Pxtl 7y ago
  Angular doesn't count as 2010 because they did massive compatibility breaking change to Angular2 such that it was basically a new framework.
deiznof 7y ago
This really just isn't true about the javascript scene anymore, and hasn't been for a little while now. React and Angular alone make up the vast majority of framework usage and they've been out for years. Honestly, a lot of javascript criticism I see nowadays is a little outdated.
- MaxBarraclough 7y ago

DonHopkins 7y ago

I hope you're not advocating writing documentation in troff instead of html!

hiccuphippo 7y ago

It would be very nice if the whole MDN could be downloaded as man pages or even just html pages with some form of local search.

kyriakos 7y ago

the worst kind is youtube tutorials disguised as blog posts. you open the link, there's 5 lines of intro and then an embedded video. and I hate videos cause usually skimming through text you can get to the part you want to read quickly but with videos you need to go through it

onion2k 7y ago

You can access MDN as man pages - https://github.com/rafaelrinaldi/mdn https://github.com/rafaelrinaldi/mdn

jimmaswell 7y ago

Man page: find the man page, search for terms you hope might be related to what you want, read through a lot of dense paragraphs to maybe find something relevant. Google: just type in a quick description of your issue and get a stackoverflow post with an answer as the first result. I don't get how anyone could prefer the man page.

umanwizard 7y ago
For me the issue is not really whether I access the docs through `man` or through the browser. It’s comprehensive, accurate docs provided in one place by the vendor of the tool I’m using, versus wading through a crowdsourced resource like SO which might be incomplete, out of date, or inaccurate. If a library vendor provides good docs on their website, that’s just as good as man pages, but in my experience they usually don’t. There is a staggering amount of misinformation or non-existent information on Stack Overflow. For one simple example: try to figure out how to use the GPS on iPhone. It’s simply impossible. 99% of people on SO think “GPS” is synonymous with “Location APIs” in general. Of the 1% of people who understand the several different data sources used by CoreLocation, nobody can tell you which accuracy settings will cause it to use GPS specifically. If you bother asking, you’ll get a bunch of “middle-brow dismissals” asking why you want to know such a thing, telling you to just use whatever accuracy setting you semantically need, smugly claiming you’re guilty of posing an A-B question, and so on. This is the type of dead simple basic information I would have expected to be present in Apple’s documentation, instead of having to crowdsource it from internet trolls.
- Theodores 7y ago
  Stack Overflow has a problem of outdated answers written ten years ago by people wanting to collect experience points. Technology moves on and those early answers are simply no good. Recently I decided to learn a few things from first principles - reading the specs. If I then try to put a half decent answer on SO then it will be answer 97, 3563 upvotes behind the 'right answer'. New person who comes along isn't going to get to my detailed answer on page 5, the one that points out how technology has moved on and why the winning answers are not what you needed. They just need to deliver the deliverables and the first answer will suffice. They will take it and add another plus to the upvotes. You can't win, the odds are stacked in favour of the mediocre. This wasn't always the way with Stack Overflow, in fact it replaced forums where the same problem existed but only to stall the nonsense for a few years, we are back to peak nonsense again. I think time is ripe for Stack Overflow to be usurped, nothing against the site which I have so loved over the years, but even mySpace had to be replaced by Facebook.

baroffoos 7y ago

I find manpages to be mostly useless because they ignore the common case to explain every single possible function. For example I use the tar command 99% of the time for extracting files and 1% of the time compressing files. When I open the manual I want to be able to quickly work out how to extract a file but the first bit of non intro text on the man page is >Options to GNU tar can be given in three different styles. In traditional style, the first argument is a cluster of option letters and all subsequent arguments supply arguments to those options that require them. The arguments are read in the same order as the option letters. Any command line words that remain after all options has been processed are treated as non-optional arguments: file or archive member names. For example, the c option requires creating the archive, the v option requests the verbose operation, and the f option takes an argument that sets the name of the archive to operate upon. The following command, written in the traditional style, instructs tar to store all files from the directory /etc into the archive file etc.tar verbosely listing the files being archived: Scanning through the manpage a fair way down and I can't see the one bit info that covers almost all of my use cases for tar. And for anything more complex than a tiny cli tool the manpage is far too large to use usefully.

detaro 7y ago
For the specific example of tar, the EXAMPLES section of the man page covers what I typically need, but that's not true for all man pages.
- baroffoos 7y ago
  For some reason my copy of the tar manpage on fedora has no examples section
your-nanny 7y ago
one of the very first thing in tar's man page is an example of how to extract a file: https://linux.die.net/man/1/tar https://linux.die.net/man/1/tar but what evs. sometimes the man page is the thing, sometimes not.
em-bee 7y ago