Echo JS 0.11.0

While this is wholly off topic for the site, want to comment here.  I don't think a lot of the conclusions are correct.  I think the problem is a failure to have ground rules in terms of work cycles and communication workflow.

If this project actually used a scrum process, where at the beginning of a work cycle the work was written in terms of user requirements as well as small enough chunks to ensure success of the sprint, then each sprint could/should have been successful.  Once the work cycle is agreed on, there should have been no changes in workflow or in-progress requirements mid sprint.

It is entirely on the project manager / client to establish the next top priorities/stories.  It is on the developers to give reasonable story points and to push back on those stories that are too big to take on in a given work cycle.  It is on the company to have enough operations resources to lay groundwork for necessary platform services and integrations to happen.

If this were Kanban, it would potentially be a tighter lifecycle.  But this is most often a breakdown of where the boundaries and responsibilities lay.  If the project is too big for 1-2 people to work on very closely with a clear communication and understanding of project requirements then it is on those involved.  This is where pre-panning and understanding of requirements, establishing common terms for things within the project and just understanding wholistically by the PM/Client, Architect and Developer Leads at the very least is required.

The fact that the platform in the example had to be rewritten multiple times is either a very good or very bad thing and probably some of both.  Either the underlying system was loosely coupled enough to have that flexibility while being small enough to do so easily or it was so inflexible to begin with that it needed to be scrapped multiple times.

It seems to me, that in this specific case that leadership was broken.  That there was no clear boundary of responsibilities established.  That there was no communication of real costs in terms of estimations and how changes in direction would affect those estimations and timelines.  That the project manager didn't know how to manage a development project, and that one should have been assigned by the stakeholder/client or the developer team's leadership.  Scrum, Kanban, XP and other processes are meant as a starting point and the key to continuing development is communication.  It is evident that this didn't happen at the start, and that the actual process itself was never adapted or reevaluated.  As the experienced consultants, it is up to you to guide and ensure that happens.

This article itself gives very little in terms of advise as to where these things broke down, or for that matter what should/could have been done to change things.  Laying it all at the feet of the client is disingenuous.  I've worked in grueling environments with so many shifting priorities and the organization so small everyone wears multiple hats.  That said, it's up to developers to estimate against unknown risk, if you don't know enough give crazy large estimates and ask for smaller units of work until you can give better ones.  Developer leads and architects should ensure that platform work like CI/CD, overall technology choices and direction are established as guides and that work that is too big isn't being taken on in a work cycle.  Project managers are responsible for coordinating the discussion between developer's assigned work and the stakeholders.  This includes allowing guided questions in terms of how the work can be broken down better, establishing common domain terms within the project and reducing confusion.  It's up to the clients to look at and establish "next" priorities in terms of deliverables.  If one piece is blocked/broken, it is up to the Project Manager to deliberate and/or communicate those broken/blocked pieces and negotiate a mitigation strategy.

I'm not sure how/why this is significantly better than current tools around applications and state management.  Is this really better than Inferno+MobX, or any other react-like JSX supporting engine and a flexible state machine for that matter?

I'm also not seeing how this approach is any more OOP than so many other frameworks I've seen in the past 5 years.  I'm not even talking about framework fatigue, I'm talking about not being sold on why this is any better, let alone why there are more upvotes than the vast majority of posts from this site.

Yet another advertorial for bit.  Is anyone else really tired of these?  Is bit really that much of a value add over npm?

Interesting... though I really don't see Blazor gaining much in terms of real traction.  Also the "material" demo seems to be a material skin over Bootstrap, the actual behaviors and interactions are not Material Design and the date input is broken/borked.

Not sure why tty's readstream is used instead of stream's

Good luck, nice to see more efforts in this area... would suggest working towards implementing the features in the material-ui and bootstrap projects at the very least.

Suggestion: If you aren't already, when you render if there are missing ARIA properties, writing to console.warn.  I wish more projects did this as a matter of course.  Wrappers for common img (Image), svg (SvgImage) and similar would also be recommended so the error messages can be outputted as well.

Aside: didn't have time to dig into the source, I have with material-ui and like their approach a lot.  There have been a handful of gotchas wrt accessibility there, but overall not so bad.

There are already a few packages that do this, my suggestion is `fclone` package... I wrote `safe-clone-deep`, which inspired fclone, at this point fclone is more mature and thorough.

NOTE: if you're using babel/webpack for building and using fclone, you may want to make sure the Buffer shim isn't loaded by using the webpack null loader or otherwise specifying it.  There is a test for Buffer for the clone operation(s).

On "Separation of Concerns": HTML, CSS and JS aren't separate concerns, the component is the concern.  With material-ui, you can bring in the theme, which is the separate concern with jss/style binding.

On ImmutableJS, I don't use it... I generally stick to shallow clones for use with Redux.

Aside... I *REALLY HATE* that every other word is STRONG bold type.  It's annoying as sin and only really for SEO, not for people actually reading.  Using it in an unstructured way that many times should really be a negative for SEO.

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/