Echo JS 0.11.0

WEbsite seems to be down, hopefully I remember to come back to this.  Just from my own understanding, I would assume that Flutter probably has slightly better performance where there is heavy interaction between state and the UI itself, where React-Native would work better in terms of some initial/raw interactions where state is cleanly separated.  I would also suspect that anything more compute intensive is also better performing under Flutter.

I've not really worked with Dart, and currently working more on learning Rust.  I'm also not sure how well the Dart Code and Flutter Code modules work under VS Code, it seems that Android Studio is the preferred tooling for Flutter.  It's definitely interesting, although learning yet another language and toolset for developing applications is a bit of a turn off.  I really do appreciate the tooling around JS extending to a native ui that React gives.

React Native's advantage is that you can go a *long* way with just JS, and the ecosystem is pretty flushed out.  Sharing between platforms is a little more complicated, however.  With anything, you may well need to dig into the native development environment for your targeted platform(s).  Flutter has a build to web option too, as does React proper.

Again, looking forward to the actual article.

This is definitely stuff that developers should be aware of.  I do hope that the future articles in the series give some more specific segments to look out for.  This article is mostly some links to standards and guidelines which can be overwhelming to say the least.

There are a few browser extensions that can help with the lower hanging fruit.  First is Lighthouse[0], you can get to this in chrome dev tools under Audits and select Accessibility.  The second is "axe"[1] by Deque.  The third is WAVE[2].  While they do have some overlapping functionality they have varying levels of interaction and advice.  WAVE is probably the most thorough, but IMHO also the least hand holding or advising.  I'd suggest giving all three a try as well as using all three when developing for accessibility.

Generally speaking, if you're building sites/apps for a company with over 500 employees, iirc, you need to be following these guidelines.  If you are targeting public clients (government users), you need to comply with these guidelines.  eLearning, etc... same.  You should at least be a little familiar with the tools and comfortable with making suggested changes.

If you're using a toolkit, it should already be mostly baked in.  Some UI toolkits do not have some of the bits needed, but isn't hard to make upstream issues and/or pull requests to correct.  Often it's just additional annotation/attributes.  For example, with material-ui input controls and their associated labels, you need to ensure a unique ID per control so the labels are linked to the control as far as accessibility.  Color contrast is another issue that comes up a LOT.

[0] https://developers.google.com/web/tools/lighthouse/
[1] https://www.deque.com/axe/
[2] https://wave.webaim.org/extension/

Pretty nice... if you're using Mongo/Mongoose for your application's models, this is definitely the fast path to an administrative UI/UX for data management.

Very thorough UI styling library.  A bit more and less than say Bootstrap, but pretty full-featured in terms of examples for most use cases in a typical website.  It isn't a reusable component structure, mostly CSS based.

Definitely interesting, and if you're developing mostly web content and not applications this is particularly useful.  If you're developing web applications, this may not be the best approach.

No idea... tbh, I find a lot of the politicizing in the dev community, more so around npm than any other I've worked in/with, I kind of hope that GH gains a lot of ground.  The last thing I really want from a package repo is a bunch of grief over things I cannot change (when/how/who I was born).

Almost none of the companie mentioned are using Angular (more about 2mc pushing their sales).  Many are using Node on the backend, which is fine.  It seems like 2mc only writes very poor articles to push their tech stack (Angular and Node), not about actually being informative.

I usually just delete the 2mc articles that are spamvertorials, but wanted to comment here...  Going back to my reading/vacation now.

Didn't dig into streams... also the new async generators with for-await syntax looks really cool... though wouldn't mind seeing a synchronous generator interface as well...

Of course it will take a while before a lot of the libraries around I/O with streams are updated to the newer model.

http://2ality.com/2018/04/async-iter-nodejs.html

I really do like the frameworks that take Bootstrap's CSS library and re-wraps component libraries around it.  It's been done a couple times with React, Angular, etc, and a valuable approach.  It's a very nice approach as a baseline.

About my only criticism, is the SCSS is separated from the components.  I also tend to favor Material Design libraries these days, but will often use Bootstrap when under a time crunch.

There are also a few wrappers around cluster to make orchestration and mgt easier[1].

It's also worth looking at the new Worker Threads API[2] for node.  If you're spinning off for compute intensive things, wrapping worker threads in a pool is a pretty good option.

NOTE: If you are using Kubernetes, do *NOT* use clustering in node.  You're better off using the external management of k8s and launching multiple instances that way.  It'll simplify your management and communications interfaces.

[1] https://www.npmjs.com/package/cluster-service
[2] https://nodejs.org/api/worker_threads.html

There's really not enough in the article to recreate the solution... It discusses a potential client api for a queue, and that it can be backed by redis.

This is kind of a solved problem repeatedly...  There are also dedicated queue servers and services and libraries available.

If you want a Message Queue style interface, backed by redis, I'd suggest you look at Kue[1], which is widely used and has a pretty rich ecosystem around it.

If you need more complex queuing, then I'd look at RabbitMQ specifically as an AMQP compatible queue server, or if you're already using a cloud provider, there's usually the option of a simple queue system and a more complex workflow system as other options.

Also, as an adjacent issue, there are RPC systems you can look at behind MQ systems (like kue or rabbit), or orchestration options behind Function as a Service (FaaS) hosting such as AWS Lambda or Azure Functions.  This area is really interesting for micro-service orchestration behind compute heavy operations.

[1] - https://www.npmjs.com/package/kue