Is Stencil a Better React? | Hacker News Reader

Is Stencil a Better React?

wix.engineering

82 pointsyoava63 comments

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.

Post Author here. I think you are underestimating your own creation. Stencil is a delight to work with, and very well done.

We at Wix are a huge React shop. We know all the best and worst of React, both OO and Functional styles.

For us, while Stencil is super interesting and is better compared to React, we will not move to Stencil.

Had we started now, it would have been a hard choice React or Stencil

I think the main message here is that

>started now

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?

Your last sentence reads like it never ended? What is the main message?

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!

This exchange is why HN is great. :)

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.

He probably means FunctionComponents (as opposed to Classes)

Thank you giving a very responsible response.

> 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.

1. https://reactjs.org/docs/faq-functions.html

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."

See: https://github.com/facebook/jest/issues/6065

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.

Still exists in the docs[0] but I definitely wouldn't say React is "promoting" binding... I certainly haven't used it in years either.

[0] - https://reactjs.org/docs/faq-functions.html

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.

How is that a fair comparison?

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.

> class based components

I don’t think those are a great example. Class based components are still very much used in 2020.

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.

As said above, we have used the Todo mvc React example as is. There are still a lot of projects who are using the "obsolete".

Given a Todo mvc functional component example, will try to use the stencil functional component syntax to build an equivalent

>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.

I am confused.

In the react docs - here specifically, https://reactjs.org/docs/state-and-lifecycle.html

The first action item when talking about state is to concert a function to a class.

Are you saying that the official react docs, when introducing state, promote using an obsolete API?

Yes.

"We recommend trying Hooks in new code" [0]

"..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.

[0] https://reactjs.org/docs/hooks-faq.html

Considering that hooks are recommended in the hooks-faq, yet the React 1,2,3 Main Concepts talks OO -

I find the statement that OO is obsolete. Maybe that is the intention of the React team, but it is not reflected in their main documentation yet.

As for the style of the React example - I have taken the React example from todoMVC "as is".

I invite you to write any other React implementation of TodoMVC, and will do my best to create the equivalent with Stencil.

Stencil the framework - perhaps not.

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.

This is why I use Svelte.

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.

Ah, c'mon, I just recently became an expert in React.

Don't worry. React isn't going anywhere.

That's what they said about Angular.

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.

During my last interviewing spree I met a person who was convinced that React = the frontend ecosystem in its entirety.

It's as if all those large companies with enormous Angular codebases didn't even exist.

Based on my experiences, angular may be nr 2, but nr 1 React covers 90% of the market.

1.25%: https://trends.builtwith.com/framework/Angular

7%: https://trends.builtwith.com/javascript/React

70%: https://trends.builtwith.com/javascript/jQuery

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.

Same thing as PHP - most websites today are using JQuery and PHP (like over 50%) compared to modern JS libraries (at most 5% all together)

It only means that we, as the JS community, are continuing to fail with presenting an alternative to PHP and JS.

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’d say 90% of the startup market.

No one ever said that about Angular.

Ang-u-what now?

it is great to be an expert in React.

1. a lot of companies use it - we as well and not planning to move anywhere.

2. if you know React, moving to Stencil is super simple.

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.

I've been keeping an eye on Solid for my next project. It seems small, fast and ergonomic.

Link? Will live to take a look

https://github.com/ryansolid/solid

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.

I can't wait to save the article's screenshots of code blocks to my Pinterest account!

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.

It’s not solving enough problems or different enough for me to consider it seriously.

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.

13 years ago...

Is Mootools a better jQuery?

Any headline that ends in a question mark can be answered by the word "no". -- Ian Betteridge

Fun fact: in academic studies of yes/no headlined articles, the articles more often answer yes than no

https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

Yes, It enables creating web components, static site generation, server-side rendering with client side dehydration. It even has documentation generation for Stencil components.

I really hope the client will not be dehydrated, it might run out of breath. :D

Reply on news.ycombinator.com