Stencil creators here. We love the title, but that is not our goal. We built Stencil for a very specific use case: building out a bunch of Web Components for our Ionic Framework project so they could run in any frontend stack. Stencil will generate React, Angular, and Vue bindings from a standard Web Component base, so developers in each of those frameworks get the native experience they expect, and any issues using Web Components (in React, for example) are smoothed out and fixed.
Stencil is really focused on building design systems and reusable component sets, like the kind we needed for Ionic Framework.
If the context of the article is a comparison of which to "start with", what was the purpose of using outdated syntax (var, class components) instead of current best practices for the React example?
I think it may have been meant as a declarative, where 'that' is 'the preceding message - that were we starting now it would be hard to choose between them"
We absolutely know it can be used well as a replacement for React. One thing we don't want to do is position it solely as a React replacement because then the unique capabilities of it get lost and we get into pointless flamewars about frameworks!
What is functional react? It certainly isn't using `useState` etc as arguably all those `useXXX` functions are not remotely pure. They do different things the first time they are called vs the second.
> The third difference is event binding, where in Stencil they promote using arrow functions while React promotes explicit binding using the .bind() function.
Does React really? I haven't used `.bind` in years, even before moving to mostly hooks-based components.
In this React doc [1] it describes .bind as being for ES2015, and recommends arrow functions for ES6, except if it causes optimization issues.
It's impossible to mock functions when testing class-based components if you utilize ES6 arrow functions.
"Jest can only mock the structure of objects that are present at require time. It does it by reflection (not by analysis), which means that properties that get added by the constructor cannot be mocked. It's important to understand though that a fat-arrow assignment in a class in JS is not a class method; it's a class property holding a reference to a function.
My suggestion to that would be that you change the fat arrow assignments to standard methods and bind them in the constructor. That way they will be Jest aware. Otherwise I'm afraid there's not much we can do here."
This is just automocking, though. If you need to mock out a component class method you can still provide a manual mock without too much trouble.
I might be thinking too narrowly here but if you're needing to mock a component class method in the first place, it might be good to do it explicitly anyway.
In their side-by-side, they use syntax conventions from 4 years ago for React (class based components and even using var to declare variables) while using the latest syntax conventions for Stencil.
Overuse of still-not-standardized decorators seems like "4 years ago", too. Just recently MobX moved away from them for that reason.
Also "let main, footer" vs "var footer; var main;" doesn't make it look good for either side.
And in the end being better than React isn't that hard. There have been plenty of frameworks that had better performance and/or better DX, without even getting into holy-war differences (e.g. JSX vs. templates). But you hardly work with a view library alone, and so you have to consider the infrastructure and the developer pool (which shouldn't matter for technical reasons, but matters for CV reasons).
I have taken the Todo mvc React example. While old, it is still valid, and a syntax that is used in quite a few projects.
If you believe it is obsolete, please do a Todo mvc React example with functional components and I commit to try and use stencil functional component syntax to create a valid comparison.
This article highlights Stencil's performance, which is great.
As a dev, I think Stencil's superpower is that it can future proof your components. You can write a Stencil component and you can later use it in Angular or Vue or React or Elm or whatever. Or maybe even no framework at all -- just a templated server generated page with some Stencil components.
That's pretty nice for a team that's transitioning between one framework and another or uses two different frameworks on two different sites but would like to share components between the two.
If they're going to compare the two, at least use the React functional hooks pattern. They're comparing Stencil to the (basically) obsolete OO components pattern.
>There are still a lot of projects who are using the "obsolete"
What relevance is this though? There's always going to be legacy code somewhere, but you made the comparison article in 2020, not years ago.
There's new established patterns, quoting out of date examples thus provides little value to your reader. Also your other comment suggests your intention was guidance on greenfield projects, in which case 4 years old syntax makes 0 sense.
"..we’d encourage you to start trying Hooks in new components you write"
"In the longer term, we expect Hooks to be the primary way people write React components."
You made a conscious choice to use code with "var" and class components in a side-by-side comparison of an article titled "IS Stencil Better than React" which implies right now, not "is this old example of TodoMVC better than Stencil's example".
My overarching point is this choice was a bad choice, if your purpose was to inform.
But the idea of compiling to an (asymptotically) optimal vanilla JS application is a breath of fresh air in a world of Virtual DOM, Reactive Programming, Hooks etc.
My favourite thing about this approach is that the end result is even half-readable, so with some practice it's possible to understand what's going on in your stack trace.
Indeed, I just removed StencilJS from my web component, now using native browser JS, everything is smaller, faster, my build step is gone and have 10% less SLOCs to maintain. That said, I think StencilJS is awesome and definitely worth trying out.
You mean the 2nd most popular framework in the world used by 10's of thousands of companies? Hasn't gone anywhere. People like to think that unless things are constantly mentioned on HN they have disappeared.
jQuery isn't really in the same market as the other two. jQuery is typically used on websites whereas React and Angular are used for webapps. Very few people are building complex webapps on top of jQuery these days.
You say that as if we ought to present an alternative to jQuery and PHP, but they are perfectly good tools for what they do. You wouldn't want to use React for a simple informational website and neither should you want to.
I would like to see a backend framework similar to Laravel (/Rails/Django). I'm not quite sure why there isn't one in JS but it would be a big productivity boost. 90% of PHP development will be either Laravel/Symphony, Wordpress or Drupal.
I've been using Stencil to create a share component library for different projects/teams where I work. I've been pretty impressed. Soon our library will be used in React, Aurelia, and possibly Ember projects!
This doesn’t strike me as a benefit. Soon you’ll have a multitude of apps and libraries instead of one framework to maintain, upgrade, refactor etc. The same goes for the idea of micro front ends being a collection of apps all in different frameworks. As a architect/cto I wouldn’t want to have so much “diversity” in that sense in my organisation. It reduces efficiency in knowledge sharing, tooling, architecture etc.
How is it not a benefit? Currently we have several frameworks across different teams, all with different variations of a few different design systems. All use different CSS frameworks, and all have their own home baked components for each framework.
Consolidating that not only helps the design team have a proper standard to design against, it helps the developers who no longer have to figure out what components to use. It simplifies it all around.
Stencil is the best way to write Web Components if not a better React. If you like you can also write entire apps and Ionic library is perfect component library for it. It is fun to use and also uses TypeScript and it's simple and easy to understand.
I tried Stencil a couple of years back in order to move away from vanilla web components which can get pretty complicated fast with any level complexity. Unfortunately, I found the build tools messy and far too opinionated, so had to abandon it. Ended up going with lit-element and the work being done at https://open-wc.org/, which I found is a nice middle ground.
"server-side rendering with client side dehydration"
lol wtf "dehydration" haha (also "Rolloup")
Still don't really get what Stencil is. Is it a actual single framework or a standard syntax that compiles to React, vue, .. component syntax? This talks about compiling JSX to bindings avoiding vdom diffing but as far as I know that is near impossible to do due to the variable nature of JSX..?
And just a wall of unhighlighted fixed with code is very difficult to compare the differences. And would rather see bundle size comparisons rather than 6 lighthouse screenshots.
IMO TodoMVC is not a good way to compare front-end libraries/frameworks because the necessary complexity is too low to demonstrate how issues that would happen in a larger code base would be solved.
Or to push the point further, you literally need 3-6 months minimum on an evolving crud app to assess any of these frameworks - on actual team
of a minimum of three people.
There's a couple performance issues opened on the Stencil repo, as well as documented developer experience requests (e.g, Source Maps). With additional investment, I think Stencil has further potential to be an influential evolution in the front-end stack.
We ended up not using it because of it's lack of ecosystem which is pretty ironic for an interoperable framework.
E.g no documented mobx support, no competitive router.
I tried Stencil a year ago and I didn't see anything too novel to warrant further investigation.
One nitpick for the OP: the side-by-side code examples are screenshots without syntax highlighting. For an article comparing two frontend frameworks, that's quite an oversight.
Yes, It enables creating web components, static site generation, server-side rendering with client side dehydration. It even has documentation generation for Stencil components.
Stencil is really focused on building design systems and reusable component sets, like the kind we needed for Ionic Framework.