alexey2020

That's cool and definitely the future of HTML streaming,

it simplifies things a lot: js enabled out-of-order streaming leads to SEO problems and frameworks usually need to come up with workarounds - detect bots and turn of streaming for that case.

With such technique no workaround is needed, less things to worry about.

Excellent!

came here to write a similar comment. Totally agree!

Focusing on a particular metric for the sake of the metric - what's the point?

Let's spend a couple months, refactor an app to generate less js just to look cool in the eyes of dev community?

>But in the article, you wrote:

I also wrote a bit below: "be transparent to components and not affect their logic in any way (make components think they communicate to Backend directly)"

I met people trying to use ReactQuery with the mindset that it's a Store. The result was that they were greatly frustrated with the outcome. That mindset led them to use ReactQuery in a way it's not supposed to be used. Every now and then they wanted to directly manipulate with the Cache (the "Store" underneath ReactQuery).

That's why I find that Store-mindset very dangerous when working with such Libraries.

Better come with a mindset that there is no Store at all. Better think that "useBookQuery" is just a simple hook to fetch data. NO STORE.

>To me, “directly communicating with the backend” implies that I have to have REST calls in my components, and handle all that comes with that

This is exactly what I meant :)

I'm glad that you found the article useful. Thanks again for providing your feedback!

Thank you for the valuable feedback!

Very good question about the difference between `getFromStore` and `useBookQuery`.

When using `getFromStore` you have the expectation that the value is already in the Store. Someone should have already put the value there somehow.

You have also the expectation that `getFromStore` is synchronous and simply gives you nothing if the value is not there.

With `useBookQuery` you expect the value to be fetched from Server. There is no 3rd party to care about putting the value in the Store. `useBookQuery` is simply like `fetch('...')` from a Component perspective.

With libs like ReactQuery every component "simply" fetches what it needs, sort of directly communicating to the Backend. No intermediary party (like a Store)

>React is doing a lot of work with Suspense ...

Yeah, I heard about React team collaboration with libs like ReactQuery on making Suspense work with those, also on server side. But I'm not much into that Suspense topic, so decided to not mention anything about it.

>I suggest emphasizing the loading/error mechanics more strongly at the end of the article.

Thanks for the suggestion. I will think about it.

>the quality and intent Marin fowler’s of writing is actually respectable.

Sorry, didn't want to be picky, but the article you mentioned is not written by MarTin Fowler. And I also didn't find there many "citations" you were looking for in my article.

I'm sorry that you found my article of a little quality.

I did my best trying to analyze different approaches to Data Management, How we came to those and their problems. I illustrated those with the my own diagrams to help readers better understand the concepts.

The article is based on my 10+ years experience in the industry.

It went through many iterations of reviews and corrections.

There nothing unique in the approach I described. It builds on what libraries like ReactQuery allows to do.

I basically just tried to formalise why I see this approach as the next logical step in how we approach building UI apps.

I'm not a native English speaker and not a professional blogger. Most probably there are ways to write such an article better. I do my best learning how write better.

Having said that, I think you are not fair comparing it with your "expert-junior-evangelical" phase.

"the small cognitive load" - true that!

Thanks for the link to the podcast. Will definitely check this out

>Whether the action goes and fetches data from the server doesn't matter

I tried to explain in the article why it matters.

If you are comfortable with putting all the data in a single Store and this works fine to you, then you may disregard the article.

>Let's say you want to add a button somewhere that hides/shows another widget.

That's a good case. This is purely UI state, right? (we don't store it on the server).

For UI state we still need to depend on prop-drilling or State Management solutions.

In the article I'm mainly talking about the Data which exist on Backend (as you can also see from all the pictures). In my experience such Server data is 90-95% of all data in most UI applications and that data contributes the most to the complexity.

Pure UI state is often just a fraction of the the whole State and is's often synchronous, so managing it should not be complex. So this kind of coupling will still exist.

To clarify, I do not say Widgets should be 100% independent. We do not achieve complete decoupling. But moving Server Data under control of Widgets gives us closer to this.

Agree. There are applications where widgets approach would not bring much benefits.

Let say, applications with lots of UI state (state that doesn't exist on Server).

Also not sure how it would work with realtime apps.

It's the same with every approach, the are always exceptions from the rule.

That said, I see the benefit of this approach for the majority of UI apps, which heavily rely on Server data.

>Seems like it could create a lot more code with less re-usage, since every widget has to manage this themselves.

It might create a bit more code in components, agree. I think this is a fair price for the all benefits it brings.

That said, the total amount of code might be even less (no action-creators, reducers, etc.).

Also declarative nature of the libraries makes the added code very easy to follow.

With pure Redux approach the mutation flow is more complex: - send mutation request to Backend - fetch updated data - put the updated data in the Store - see the updated data propagated in components

The suggested approach: - send mutation request to Backend - see the updated data being fetched and displayed by components

To me the second is much cleaner and easier to reason about

The report is split into 6 parts. Each part is dedicated to one of the 6 major categories in Frontend Development:

Frontend Frameworks https://moiva.io/blog/2021-q1-state-of-js-frameworks/

State Management Libraries https://moiva.io/blog/2021-q1-report-state-management/

Testing Libraries and Frameworks https://moiva.io/blog/2021-q1-report-js-testing-libraries/

Build Tools and Module Bundlers https://moiva.io/blog/2021-q1-report-js-build-tools-bundlers...

JAMStack Frameworks + Static Site Generators https://moiva.io/blog/2021-q1-report-js-jamstack/

End-to-End testing frameworks https://moiva.io/blog/2021-q1-report-end-to-end-testing-fram...

So much enjoyed the reading! I like that kind of stuff - nothing serious and lots of fun. Well done!

If there is no cached data, then it doesn't matter.

With Vercel it doesn't matter even in case there is valid cached data, because Vercel doesn't execute the function in that case.

Cloudflare always executes the Function regardless of the existence of cache and it's Function's responsibility to respond with Cached data. Hence, distributed Cloudflare functions is a necessity.

Wow, thanks for the insight and ideas! Agree, having native running runtime at edge can can give a start to some interesting projects

if it's a real issue and you have to issue lots of subrequests, then you don't really get advantage from all Cloudflare micro-optimisations. In such situation I would suggest to look for other Serverless providers, or maybe traditional approach works better in such case

Serverless are not all the same. Cloudflare uses V8 and you can't require npm packages, right. Vercel and many other implementations use NodeJS and you Can require npm packages.

Right. It's not missing. I pointed that out in the "Serverless Functions requests handling" section, also visually

Thanks for feedback! Caching... it took me time to get my head around it. With Vercel it works more or less the way I imagined. It surprised me that Cloudflare has a different approach. But once I got it, it started making sense and I like it :)

Good luck with your project!

> in what situation is it really worth all the added complexity of risk of pushing out functions to the edge

If you are talking about developer point of view, then there is no additional complexity. All the complexity is covered by the underlying platform

> what is the advantage of saving a few ms on a transaction?

one example - if a transaction consists of a few separate sequential transactions, then ms add up and might affect user experience. Also an app might need to issue lots of requests on a page load and taken that there is a limit on parallel requests (6 requests per domain), the advantage might be sensible.

Having said that, I tend to agree that many use cases are not sensible to a few ms advantage

AFAIU all the buzz is about good manners. If you announce smth with pomp, it's good to not forget about those who has contributed to the achievements

Hello! Alexey, the author of Moiva.io, here

The Kraken is out and I'm happy to discuss and answer any questions/suggestions you have

In short, what the article is about.

I rewrote Moiva completely, I put GitHub in the center of the Moiva Universe and made NPM its satellite. The architecture is agile enough for adding more satellites like Maven (Java), PIP (Python), and others.

It means that Moiva essentially became a universal tool with the ability to evaluate and compare any Software library!

Well, I see that stats for es-dev-server/@web/dev-server and prisma/prisma-2 are completely different. Bundle size is different, languages is different. I think it's fair enough to treat them as different packages. For example, AngularJS and Angular are also totally different frameworks. And it can be also useful for example to check stats for the old package, because it might be in use for a long time and people might be interested in tracking its stats.

>maybe “trendiness” is a nice metric Good suggestion, thanks! I will look into it

Thanks for valuable feedback! I'm always glad and eager to hear such meaningful comments.

> - I think Contributors per year and Releases per year, could be monthly or quarterly as it's more granular and yearly change doesn't say much for libraries that are only there for 1-2 years. I need to give it another thought, might be it makes sense to change it the way you suggest

> - Also the history-back makes the url change but doesn't get reflected in the page Yes, I know about that problem, haven't had time yet to fix it - there were more important things to implement. But it's on my agenda. BTW you are first who comments about it )

> - A "clear all" button would be nice Agree. It'll be there soon.

> - It would be nice to merge some libraries, because sometimes a library changes it's name and it would be nice to merge the statistics. In the mentioned case the packages point to 2 different GitHub repositories with different owners. So I don't see what could be merged there and why it needs to be merged. Maybe you have a better example to understand the problem?

React or Vue? Angular or Svelte? MomentJS alternatives? We've all been there.

It's usually a daunting and time-consuming activity to find a better library and decide on a Tech Stack for your next project. Usually we developers skim through a countless number of resources in a search for a meaningful information. Every developer has its own favourite list of resources to look up in.

I want to change that and that's why I created Moiva.io My goal was to gather, aggregate and present valuable information in an easy and digestible way - one chart per a meaningful metric. If possible and makes sense - show a trend.

I don't want to clutter the page with useless information and useless metrics. I don't want to present any scientifically calculated information which is hard to digest and understand.

Evaluation and comparison should be dead simple.

I have big plans for that project and lots of ideas. I want to create something really useful for developers.

That's why your feedback is critical on that road.

- does the project bring any value to you? Do you think it makes sense?

- suggestions for new charts?

- suggestions for existing charts and information?