Echo JS 0.11.0

Yeah, but many/most posts don't even get comments... I usually look at anything with comments anyways.  And I do agree on it being expensive.

2. Gotcha... there's just so many new takes on this, with what at a glance are very minimal changes to existing options it's hard to gauge.

3. Very cool that you've been able to get that level of involvement.  I tend to be skeptical when I see that many upvotes and no comments, and only a very thin readme.

1. out of order on this.  It would be a good idea to spell out some of the differences like that.  Inferno[1], iirc is a about 8k min+gz, it's also one of the fastest frameworks out there for react-like use.  MobX[2] is a pretty decent state machine built around E6X proxies and is a pattern not too dissimilar from your own.  I'm more of a Redux fan, but can see the appeal.

I didn't mean to come off as a condescending ass.  I just see so many me too frameworks that support JSX and minimal state machines that don't really provide much over what's out there and relatively popular already.

Overall, would just suggest expanding the README.md to include a bit more on the reasoning, and a multi-layer example in addition to the minimal one and maybe a canonical todo-mvc[3] example and an implementation of the benchmarks inferno.js[4] covers.

[1] https://www.infernojs.org/
[2] https://mobx.js.org/
[3] http://todomvc.com/
[4] https://www.infernojs.org/benchmarks

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.