#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model.
Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype.
#4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices.
On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with.
#6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior.
#9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first.
I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level.
#10 kind of a sloppy definition, but mostly correct in the context of node and the browser.
While I love JS... I'm not sure it's the best language for beginners. The only real advantage it has is accessibility, you can play in a browser without additional tools, since pretty much any desktop computer, and even example websites are easy to use from pretty much anywhere.
That said, I'm unsure that other languages wouldn't be better to start with. JavaScript is incredibly flexible, and conceptually that's a benefit, for a beginner it's a massive hindrance. It's way too easy to muddle concepts in JS, and without the experience to know when one approach may be better than others, you wind up in a weird path.
Of course, I've also seen this with experienced developers, who are new to JS, so I could be entirely wrong on this.
Duomly is pretty much spammy content... they've been blocked on as many independent sources as I can do... dev.to, medium and github I can't reasonably block because there's too much relevant content.
Edited original title to match repository/npm name.
--- original title:
Made something useful. It's a simple utility package to help deal with arrays and an array of objects. Do use it and leave a star if you like it. Any feedback is appreciated. I would really love to hear your thoughts on how I could improve the package.
Selenium is in general painfully slow, cumbersome, error prone, difficult to setup correctly and automate.
The lambdatest articles have been receiving more upvotes than typical and while not inherently bad, I'm just suspicious of the upvote activity.
Playwright is also worth a look. It's similar to puppeteer, and a few of the main developers were hired by MS (also puppeteer devs) to work on playwright.
https://github.com/microsoft/playwright
Interesting... a made a couple issues around supporting etags and if-modified-since requests as well as pre-compressed static content.
Should probably prefer streaming file responses for static instead of reading the file entirely and returning it from in-memory.
Considering every modern browser supports async functions, would definitely use that syntax over the death tree of thenables for the code samples... the logic is difficult to follow.
Also, posting a more complete set of examples in a github or gist would be beneficial.
#3 is not quite correct... all inheritance in JS is prototype based, even if using the class syntax, it's sugar over the prototype model. Prototype based inheritance in JS is kind of like a search path... is property X on the object, on it's prototype, and so on down the chain. You can also use Object.create({...}, null) to inherit from null instead of Object as a base prototype. #4 somewhat disagree on the FP cons... even before I understood what FP was, I leaned into that style far more early in my career... prefering utility functions and composition over class methods. I didn't come at this with a formal education, and even then tended towards FP practices. On the flip side, class syntax/structure is useful when you need to bind state and behavior. This can be useful in certain types of components, though I prefer React + Redux, with other libraries using class syntax is easier to reason with. #6 I'd add that when using the prototype the properties aren't serialized by default (Object.keys/entries) and this can be beneficial if you want utility properties/methods but don't want them serialized. There are other ways to do this, but the prototype is a relatively clean break for this behavior. #9 While I appreciate micro-services, the orchestration can often be more work than the application development itself. If you don't have dedicated resources to this operation design and overhead it's usually not a good idea. If you're leaning on a cloud platform and they offer things like lambda (aws) or functions (azure) then it might be worth leveraging these things earlier. Otherwise stick closer to the monolith model and then break off pieces that tend to bottleneck or can be parallelized or separated out via a queue system first. I'm also in general a fan of a dedicated server api for the ui, even if there's a more formal set of APIs behind it... this can allow more edge-line utility on a server before the internet latency becomes a thing. GraphQL is another similar example of this approach. I find that node/js is a very good fit here as you can leverage the same mindset/language without the disconnect at this level. #10 kind of a sloppy definition, but mostly correct in the context of node and the browser.May as well get rid of the prototype chain... Object.assign(Object.create(null), original)