The path to native web components and how StencilJS can help you
Typically I don’t write a lot about my experience as developer, and if I write something it’s more of a How To than about my personal experience. Today, lying on a sun bed on the Island of Corfu, some memories came to my mind and I decided to share some experiences from the last years in front-end development.
For years we used several approaches to get webcomponent — like behavior in different frameworks. I always had my troubles with the different approaches as I saw the frameworks evolving within a minimal time and the downside of that evolution always was the need to adapt the interface components to the new state of the technology. Often it was just minor modifications to the syntax, sometimes it was a complete rewrite.
When Polymer released I hoped to be able to solve these problems and to be able to write the interface components independent of the logic. I did that at a time when angular 1 was up to date and polymer was in a minor version. There were a lot of issues regarding attribute binding, browser compatibility and the development in HTML and working with HTML imports broke our work flow on multiple occasions. I will not claim that it was the fault of one of the frameworks, but I realized that their combination does not work well in our team or our frameworks.
In our team we then worked with the approaches from the different frameworks and libraries. We did most of the developments in various versions of angular and some with react and the combination of different libraries. For me with react always came with some anxiety about the upgrade process, because I remembered from various JavaScript projects which used a combination of libraries that at some day we always ran into trouble to use up-to-date libraries. I am not sure if this is solvable at all, but to be honest even angular gets problems with upgrades as soon as you use third party libraries in your project ( and you normally do if it’s a larger project ).
I did not like jsx/tsx at first as it was, from my perspective, mixing code with template. I was wrong! If you split your components into the right size it’s unbelievable helpful. This fear came from a time where we had large PHP templates and they still scare the hell out of me :-).
There isn’t only one solution for the plan. That’s one thing my work as a consultant taught me very quickly. The decision for angular, react or whatever framework was also often driven by the teams and business needs like:
- How much time do we have?
- In which framework / library does the team have more experience?
- Which kind of application do we develop?
- Which kind of components do we already have in our company (or do we already work with a component based approach)?
- and many, many more
I really like redux and the separation of the logic from the code. Even when it creates some additional challenges and sometimes a higher learning curve for the developer. The approach of the ngrx — team to use Observables for the ngrx side effects (async calls like http requests) is very nice from my perspective. The same approach is now available for the native redux implementation and is called redux-observable. I appreciate that implementation a lot.
The decision for one framework always came with the downside to never be able to reuse the developed front end components within another framework. Even at Google not everybody is developing with angular. The reality is that in a lot of companies the front end approaches are very fragmented and in larger companies the different teams often don’t know each other.
So am I writing this article to say that everything is bad for a general approach for interface elements? No, I don’t, because there is a great solution.
Since about 7 months I am working with StencilJS and also introduced it in several projects. Stencil is a webcomponent compiler. The benefit over writing vanilla JavaScript components for me is that there are well documented rules for using the components. From my perspective it’s also a plus to use Typescript Decorators to decorate the components and reuse the approach from react with the render function in the component. It combines useful elements from angular and react from the coding perspective, simplifies the development of a single component, provides aspects like plug-ins for SCSS and many many more. Even though it offers all this, in the end it creates just native webcomponents which can be understood by all browsers >= IE 11.
In the last few months we created a lot of components with StencilJS and in every project the components outperformed the previous JS framework implementations. One of the main benefits from my perspective is that the components can be developed in separate projects and easily integrated into the angular project via HTML tags and the binding works the same way as it does with native HTML components. This loose binding and the separation of the applications logic from the interface in combination with the rendering and updating speed of this native approach makes me confident that we found the right solution for our needs.
We already have some examples where we used the same stencil components in a stencil website project, an angular application and a PHP based CMS. The benefit for us and the costumer is getting a component library over different solutions and improving development speed. Additionally, from the end-users perspective the applications often feels more responsive and the initial load times improved a lot. Try out StencilJS and tell me about your opinion and your experiences.
Wishing you all the best from Corfu!
Dominic
INSPIRATIONlabs is a studio for digital solutions and consulting located in Heidelberg, Germany. If you are interested in our work, come visit us, be it physically or digitally at http://www.inspirationlabs.com
