JavaScript Meetup

5 min read

05 November, 2022 | Meetups

On the 27th of October 2022 I attended a Frontend Developer Meetup in Amsterdam. The night consisted of 4 talks and some networking, organised by Passionate People and hosted in the ING office space. These are my takeaways from the night.

Rendering Strategies – Tim van Bergenhenegouwen

The talk started off with a nice history of trends around web rendering, showing the ping-pong of doing more work on the frontend, and then doing more work on the backend. We have a lot of options to choose from because of this, and there is no one-size fits all solution. It is better to choose a strategy based on your needs:

  • SEO

  • Performance

  • Speed

  • Dynamic content

  • Global Users

  • etc

There is a lot of information on these strategies as well as many choices you can make within these strategies, such as framework or what combinations you want to use. Here are some I took note of during the talk, many of them often referred to by their acronyms:

  • SSR: Server side rendering

  • SSG: Server side generation

  • SPA: Single page application

  • PWA: Progressive web app

  • Offline first

Things mentioned in the talk that I would like to look into further


I’ve heard about it but never tried it, unlike all the other big web frameworks.

Angular Universal

Angular’s own SSR implementation.

Web components/Custom elements.

Don’t remember hearing about this before, but looks very cool to do framework-like reactive rendering/component based building using all vanilla JS/HTML DOM and browser functionality.


Framework built on top of Web components, seems like most people use this rather than plain web components. After talking to a developer, I found out that ING uses it for the web banking site.


Similar to SSR, but avoids hydration through only downloading the JS that needs to be executed.


A Webpack replacement written in rust.

Is this the end of E2E – Tobias Kuppens Groot

Tobias covered a brief summary of what E2E testing is, why we use it, and why it might not be the most valuable use of a developer's resources. We use E2E testing to validate communication; communication between frontend and backend services, between separate backend services, external integrations, and communication between user and UI, all at once.

Because of this, tests need to be run monolithically. Everything is deployed and tested together. If any one of these pieces of the monolith change, then the results of the test becomes stale and the next tests will (should) fail. This is flaky, makes tests hard to refactor and slow to fix and debug. On top of this, it relies on the relevant test data to be present in the environment you are testing.

Their suggestion is to add another layer to the bottom of Martin Fowler's Testing Pyramid: the type-safety system. You use it to confirm that you have valid code and provide confidence that the code will work. It is extremely quick because you get feedback as you're writing the code, whether as an IDE integration or in compile errors when building the code.

In order to use this new pyramid layer to validate communication between the frontend and backend, you can use type generators for API specs. This tends to work better with an API-first design, as you can be sure that both frontend and backend are holding up their end of the contract. With these API generations, you can also rely on a live service layer, allowing you to concentrate on the UI without worrying about the details of the network requests. Another advantage of this is that it can be mocked out in tests using something like Mock Service Worker.

Things mentioned in the talk that I would like to look into further


No bundle based frontend tool, using native ESM.

A new technique similar to microservices for backend, but separating responsibility and creating domains for the front end (heavily favouring web components as it makes a lot of the ideals easier to implement).

Event-driven Dependency Injection - Matius Fernandez Martinez

This talk was about creating a solution for dependency injection (resolution) when working with web components, since with most modern frameworks you get it out of the box. Dependency injection helps with inversion of control, where a framework will call your custom code and provide services rather than you calling the framework methods to get services.

The solution is smart in its simplicity. Since you’re using DOM elements, you can use the event system to bubble up events to ‘provider’ custom elements further up in the tree. It also all works synchronously, so dependencies are resolved without waiting. You can see the full repo with this implemented here: It utilises mixins to avoid boilerplate with setting up the event listeners and dispatchers.

Effortless full-stack type-safety with pure TypeScript – Jasper Haggenburg

This talk was by the creators of a new frontend/backend framework called Phero. Similar to the 2nd talk, this framework utilises type generation from backend APIs to provide better confidence and developer experience when integrating frontend with backend. The twist here is that you don't need to spec out the backend services, instead Phero utilises the typescript compiler to generate the interfaces from the types used in your backend functions. On top of this, it also generates errors for custom errors you use in your backend functions. I hadn't heard of RPC (remote procedure calling) until this talk, but it makes a lot of sense when writing web applications.

Lots of questions from the audience revealed there is much still in planning, as the framework is quite young still. Things like API versioning when making breaking changes between interfaces, automatic documentation generation and custom HTTP status codes are all things that they are looking to work on moving forward.

Things mentioned in the talk that I would like to look into further


Similar concept to Phero, much more mature, and you don't quite get the same functionality out of the box.


Typescript schema validation that you use with TRPC to get the API input/output validation that is also a feature of Phero.

Last thing

This was the first meetup/tech talk I had been to in a while, and it was fun to get back into the swing of things. I got to chat to some very friendly, like-minded developers, and I came away with a lot of new things to try. Not to mention, it inspired me to start this blog!