6 ms·

This site is a real gem. Clean, simple, and minus the excessive complexity and obfuscation caused by frameworks. Doing & Learning things in plain JS we can lea

This site is a real gem. Clean, simple, and minus the excessive complexity and obfuscation caused by frameworks. Doing & Learning things in plain JS we can learn fundamentals.

deleted 7y ago
[deleted]
dgb23 7y ago
I agree! The MDN docs are from my experience the best browser frontend reference available. This site however covers a different need: guide/howto oriented documentation, which is often what you want. > Doing & Learning things in plain JS we can learn fundamentals. To this I have to add that I often do write plain JS supported by only a few, small libraries such as is.js, axios, json-schema and so on. This is regarding small to medium sized projects and/or features. This can easily save time, setup and mental energy, as long as one follows a consistent, simple structure. And on top of that, the fewer dependencies you have, the less friction. But it also means that one has to have a bit of a deeper knowledge of the available frameworks and tools, which can manage complexity with growing features, because you add them incrementally and only when needed and so on.
- Kwantuum 7y ago
  Honestly, while axios is nice to have on the server side, the websocket API in the browser is very simple to use. Which IMO is a consistent theme with modern browser APIs.
  - girvo 7y ago
    Agreed: on our current front end project at work I’m having a lot of fun teaching the team the amazing browser APIs that subsume the need for a lot of the third party dependencies we used to reach for
    - orange8 7y ago
      How do you deal with IE 11?
      - IggleSniggle 7y ago
        Many of us do not need to deal with IE. I haven't even needed to deal with mobile in years. Depends on requirements and use case.
        orange8 7y ago
        Agreed. But the reason I asked because I am assuming they are making changes to a long-standing project that previously relied on third-party libraries (for browser compat?). I'm interested in that specific situation, not all projects in general.
      - girvo 7y ago
        In this project, simple: we don't have to. Despite being a decade old application, it was entirely AJAX-driven and front-end focused even back in 2010, and IE support was dropped entirely a few years ago by the business. Works in Edge just fine, as to be expected
        orange8 7y ago
        Makes sense. I think the two options are just dropping IE support entirely or using (usually third-party) polyfills.
- duxup 7y ago
  MDN is great as if you're reading the manual with all the details and etc. But like a lot of raw manuals sometimes you read it and wonder "Wait.. why would I want to do this again? Does this even do the thing I started looking for?" Some of their examples have actually evolved to be a bit more akin to more usage based rather than raw specs. I do appreciate the other sites that are more "You want to..." as a complement to MDN and such.
onion2k 7y ago
I don't like it because it's basically wrong, or if I'm being more charitable it's only telling you half the stuff you need to know. Take this page as an example - https://htmldom.dev/select-an-element-or-list-of-elements https://htmldom.dev/select-an-element-or-list-of-elements Firstly, it doesn't tell the reader that every method of selecting elements listed is available on both a Document and an Element. document.getElementsByClassName selects everything in the page with that class name. Element.getElementsByClassName selects every child of an element with that class name. If you're wrangling a huge page using one is better than the other. Chaining calls is really useful eg document.getElementById('users').getElementsByClassName('admin').[1] "Select an element by given ID" using getElementById() does select a single element on the page with that ID, which is right, but browsers don't enforce ID uniqueness so you're only getting the first element with that ID. That's a very common gotcha for devs who are new to this. (React would tell you if you've not got a unique key.) .querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball. Worst of all though, it doesn't mention .querySelector() for picking individual elements. Why would you miss that out? [1] The page that does talk about selecting children (https://htmldom.dev/select-the-children-of-an-element https://htmldom.dev/select-the-children-of-an-element) of an element suggests using an element's childNode array. That's horrible. There could be all manner of strange things in there. Just use an element.querySelector() call.
- eMSF 7y ago
  >.querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball. querySelectorAll does return a list of elements. While technically a NodeList, you can't select non-element nodes with selectors which is why querySelectorAll never returns such. Further, neither NodeList nor HTMLCollection implement methods like map, but both are quite iterable and in a similar fashion (by converting them to Arrays or using Array methods with them, like with other Array-like objects which JavaScript is full of). But if anything, NodeList is a "more" iterable type than HTMLCollection, as it does implement forEach itself, too. I would certainly not recommend using querySelector for accessing an elements first child node or child element.
b0ner_t0ner 7y ago
Too bad this site doesn't remember your scroll position when you go to a page and hit the back button. For a site promoting vanilla Javascript, it didn't really need to be built with React.
- yokohummer7 7y ago
  I was also annoyed by it not remembering the scroll position. The site doesn't live up to its name.
speleding 7y ago
I love the idea, but the very first example on there ("How to add a class to an element") comes with the disclaimer "isn't supported in IE 11". Everyone likes to support only modern browsers, but completely dropping support for IE is unlikely to be acceptable for most users. For my own sites I conditionally include a shim for IE users so I can use vanilla JS and only IE is bothered by the longer load time, using

This site is a real gem. Clean, simple, and minus the excessive complexity and obfuscation caused by frameworks. Doing & Learning things in plain JS we can learn fundamentals.

deleted 7y ago

[deleted]

dgb23 7y ago

I agree! The MDN docs are from my experience the best browser frontend reference available. This site however covers a different need: guide/howto oriented documentation, which is often what you want. > Doing & Learning things in plain JS we can learn fundamentals. To this I have to add that I often do write plain JS supported by only a few, small libraries such as is.js, axios, json-schema and so on. This is regarding small to medium sized projects and/or features. This can easily save time, setup and mental energy, as long as one follows a consistent, simple structure. And on top of that, the fewer dependencies you have, the less friction. But it also means that one has to have a bit of a deeper knowledge of the available frameworks and tools, which can manage complexity with growing features, because you add them incrementally and only when needed and so on.

Kwantuum 7y ago
Honestly, while axios is nice to have on the server side, the websocket API in the browser is very simple to use. Which IMO is a consistent theme with modern browser APIs.
- girvo 7y ago
  Agreed: on our current front end project at work I’m having a lot of fun teaching the team the amazing browser APIs that subsume the need for a lot of the third party dependencies we used to reach for
  - orange8 7y ago
    How do you deal with IE 11?
    - IggleSniggle 7y ago
      Many of us do not need to deal with IE. I haven't even needed to deal with mobile in years. Depends on requirements and use case.
      - orange8 7y ago
        Agreed. But the reason I asked because I am assuming they are making changes to a long-standing project that previously relied on third-party libraries (for browser compat?). I'm interested in that specific situation, not all projects in general.
    - girvo 7y ago
      In this project, simple: we don't have to. Despite being a decade old application, it was entirely AJAX-driven and front-end focused even back in 2010, and IE support was dropped entirely a few years ago by the business. Works in Edge just fine, as to be expected
      - orange8 7y ago
        Makes sense. I think the two options are just dropping IE support entirely or using (usually third-party) polyfills.
duxup 7y ago
MDN is great as if you're reading the manual with all the details and etc. But like a lot of raw manuals sometimes you read it and wonder "Wait.. why would I want to do this again? Does this even do the thing I started looking for?" Some of their examples have actually evolved to be a bit more akin to more usage based rather than raw specs. I do appreciate the other sites that are more "You want to..." as a complement to MDN and such.

onion2k 7y ago

I don't like it because it's basically wrong, or if I'm being more charitable it's only telling you half the stuff you need to know. Take this page as an example - https://htmldom.dev/select-an-element-or-list-of-elements https://htmldom.dev/select-an-element-or-list-of-elements Firstly, it doesn't tell the reader that every method of selecting elements listed is available on both a Document and an Element. document.getElementsByClassName selects everything in the page with that class name. Element.getElementsByClassName selects every child of an element with that class name. If you're wrangling a huge page using one is better than the other. Chaining calls is really useful eg document.getElementById('users').getElementsByClassName('admin').[1] "Select an element by given ID" using getElementById() does select a single element on the page with that ID, which is right, but browsers don't enforce ID uniqueness so you're only getting the first element with that ID. That's a very common gotcha for devs who are new to this. (React would tell you if you've not got a unique key.) .querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball. Worst of all though, it doesn't mention .querySelector() for picking individual elements. Why would you miss that out? [1] The page that does talk about selecting children (https://htmldom.dev/select-the-children-of-an-element https://htmldom.dev/select-the-children-of-an-element) of an element suggests using an element's childNode array. That's horrible. There could be all manner of strange things in there. Just use an element.querySelector() call.

eMSF 7y ago
>.querySelectorAll() does not return a list of elements. It returns a NodeList, which is different to the HTMLCollection that the other methods return. For a start, NodeLists aren't iterable in the same way as HTMLCollections. You can use forEach but you can't use map. That's going to throw a lot of devs a curve ball. querySelectorAll does return a list of elements. While technically a NodeList, you can't select non-element nodes with selectors which is why querySelectorAll never returns such. Further, neither NodeList nor HTMLCollection implement methods like map, but both are quite iterable and in a similar fashion (by converting them to Arrays or using Array methods with them, like with other Array-like objects which JavaScript is full of). But if anything, NodeList is a "more" iterable type than HTMLCollection, as it does implement forEach itself, too. I would certainly not recommend using querySelector for accessing an elements first child node or child element.

b0ner_t0ner 7y ago

Too bad this site doesn't remember your scroll position when you go to a page and hit the back button. For a site promoting vanilla Javascript, it didn't really need to be built with React.

yokohummer7 7y ago
I was also annoyed by it not remembering the scroll position. The site doesn't live up to its name.

speleding 7y ago

I love the idea, but the very first example on there ("How to add a class to an element") comes with the disclaimer "isn't supported in IE 11". Everyone likes to support only modern browsers, but completely dropping support for IE is unlikely to be acceptable for most users. For my own sites I conditionally include a shim for IE users so I can use vanilla JS and only IE is bothered by the longer load time, using