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?

I mean there are 2 npm packages now - synergy and Synergy https://www.npmjs.com/package/Synergy Moiva.io shows names of npm packages

))) How about SynergySuperior? ;)

Just noticed there is already existing another Synergy framework and "Synergy" package. Probably better to rename the library to avoid confusion.

By the way, in terms of bundle sizes React is smaller and Preact is almost the same. But I think the reason is that react-dom is not included into calculation https://moiva.io/?compare=Synergy+preact+react+synergy+vue

Thanks for sharing you thoughts!

Your approach sounds very reasonable, especially when you start a new project and you are in charge to pick the tools.

In my experience things usually get more complicated for different reasons.

For example, you need to convince your upper management that your chosen tech stack is reasonable enough and visual comparison would help here.

Or you are in the process of migration a big application say from AngularJS to Vue and you can't use Vuex for state-management, because your data should be accessible from both frameworks at the same time. So you need to make a choice from a number of framework agnostic libs.

Or you'd like to switch a library (say from Enzyme to React testing library) and you need to convince other developers. In that case latest ThoughWorks Techradar could help if they put the already used library on Hold.

What also matters to me personally, among other things, is that the considered library should be actively maintained, preferably with a good number of contributors and frequent commits

Comparing JS frameworks and libraries was always a hurdle to me - its hard to find an unbiased up-to-date side by side comparison of the libraries one needs. Tons of blog posts and surveys come out every year trying to answer questions like "What framework to use in 2021", "Redux vs Recoil", etc. But all of them tend to have the same shortcomings: - biased - limited number of metrics and data sources - become outdated very fast - usually consider only 2-3 libraries

I wanted to create a tool that solves that problem

I quickly realised I need to solve the following problems/questions: 1. Moderated list of libraries vs automatic non-moderated (e.g. from Github, NPM). I didn't want to limit users in what libraries they can compare. At the same time I wanted to provide data from different platforms (npm, Github, Google Trends, etc.), the more different data sources the better. I couldn't come up with a solution how, for example, to map every npm package to every data source. Therefore I decided to have a moderated list of libraries and configure data sources for every library manually.

2. Scale nicely in both directions - horizontally (supported libraries) and vertically (charts and data sources). It was a pure technical problem and quite easy to solve - I created a configuration file where I configure charts and data sources for every library

3. Shareable comparisons. Selected apps are saved as url query parameters.

4. Find the right data sources for charts/diagrams. Sometimes it's easy to find the right api and use it, sometimes not. For example, I wanted to add a "Release frequency" (number of releases per year) chart. I thought it's easy to do and I just need to use Github api for that. Turned out not all js libraries provide release history data via Github api (not sure why). Then I had an idea of using jsdelivr.com data, but they don't have release dates. Finally I found an npm api which probably provides the needed data for all the packages, but it can take ~1Mb per package...

5. Do not abuse data sources and avoid "Service Unavailable" kind of problems. Currently every api call is cached for 24 hours (though it seems to not work the way I expect. Need to dive deeper here)

Ideas for the next charts: - build size (raw/minified/gzipped) - contributors - real usage of libraries (share of sites that use the library) - vacancies per technology - salaries per technology - licenses - use of stateofjs survey

TechStack: Vercel, Vue, Tailwind, Fauna (database)

Request for comments/questions Right now I'm keen to know if https://jsdiff.dev is something that can be interesting to others and worth building. What metrics users need the most. Any questions, comments and suggestions are very welcome and valuable.