Echo JS 0.11.0

Material UI is a component library, but it's not coming from google, it is an implementation of Google's Material Design (I don't know why this bugs me that people get it wrong so often).

Also, the other UI kit mentioned, I'm not even sure how it made the list.  It's woefully incomplete.  react-bootstrap[1] or reactstrap[2] would both be better options.

[1] https://react-bootstrap.github.io/
[2] https://reactstrap.github.io/

That works... though, probably my favorite datepicker (excluding the lack of sizing for phone/touch) is probably the UX for the Microsoft Ajax Toolkit (hate the toolkit, UX for dates is really good).  When you click on the month/year title, you get a panel with each month in the year with prev/next, click on the title again, and you get a decade of years with prev/next.

https://ajaxcontroltoolkit.devexpress.com/Calendar/Calendar.aspx

About the only thing I'd do is tweak the styling a bit larger, and display it full screen for small/mobile devices (phone).  I always thought it was a very intuative interface.

I made this one a few years ago... don't like it as much as the one above, but it's good for mobile use.  The demo only shows 3 years, but it's in a scrolling field like the months.  I should really break it up, and make it compatible with the material-ui library... as it is, it works standalone.  Next time I need a date picker beyond the browser's date input, I'll probably revise it.  Right now, I mostly just use <input type="date" /> and defer to the browser's UI.

https://github.com/tracker1/md-datepicker/
http://tracker1.github.io/md-datepicker/

Two of my biggest complaints with date pickers are that they often don't align correctly for mobile, and a bigger issue is the inability to jump to a given month/year...  About half the examples are unusable for something like a Date of Birth field.

Added an Issue with working code using the `sha1` module without the babel polyfills, axios etc... too much overhead.  Can polyfill fetch and Promise for IE support all modern browsers covered and the payload won't be the 138kb it currently is.

Most modern browsers support async, and have fetch. It would be better to convert to commonjs imports, without the use of corejs or regenerator... also, may be best for a specific browser version to only polyfill sha1 and another using crypto for node.

Alternatively: https://www.npmjs.com/package/sha1

Didn't delete, but noted this is a non-free UI library, and the license fee is relatively steep.  I'm also specifically not a fan of most commercial UI libraries as they generally have limited value, poor code quality, and with web facing libraries, excessively large payloads.

Alternatively, I'd suggest material-ui[1] or one of the react bootstrap wrapper libraries.

[1] https://material-ui.com/

I reject some of the assertions the article makes.  Devices aren't really that diversified compared to even a decade ago.  There have always been a number of devices with a range of display sizes.  Bootstrap started in 2011 (about 8 years ago) to deal with common break points.  Component systems like react can make it even easier to deal with in-between for core components.  Flexbox and other CSS additions also help significantly.

And while I agree Components are the way to go, some frameworks are easier than others, and it doesn't mean you don't need to know how to code.  About 1/3-1/2 the developers I know simply turn their noses up towards anything web or JS.  There's simply a snobbishness a lot of developers have to the front end and specifically web.  The fact is we need more skills from front end developers than we have gotten in the past.  Designers tend not to do well with application development.  However, component libraries like material-ui bridge the gap significantly, and material design and other common design guidelines reduce the constraints enough to be able to use component libraries for most interactions.

I'm also still not sure I even understand the value that Bit actually offers over npm itself, or its' place in a broader ecosystem, or where it plans on getting resources from.

In the end, the world will carry forward.  As to developer shortages, as a developer it's a good thing.  This will keep salaries up, and limit the number of stupid ideas getting funding.

Why you shouldn't use Angular for your next web app...

* Overtly complicated
* Excessive boilerplate
* Locks you in
* Leads to spaghetti code
* Weird DI framework
* Component decorators are complex and difficult to memorize.
* State management patterns become exponentially more complicated as features are added.

You'd probably be happier in the end using Next.js[1] (React) or Nuxt.js[2] (Vue) if you want a framework to start from.

[1] https://nextjs.org/
[2] https://nuxtjs.org/

Just not a fan of outsourcing user account storage and authentication.

Looks like a wrapper around worker_threads[1], may be a little easier to use than the direct API.

https://nodejs.org/api/worker_threads.html