Angelos Chalaris

It is quite different actually. While the approach here is a counter, you could key your elements based on a hash or some complex mathimatical formula or pretty much anything you want, using this technique.

Whoops! That is probably the case. I did not consider that the render function will re-key everything on every render, which defeats the purpose of the generator in the first place. Memoization and some more complex logic could fix this, but then again it’s probably not worthwhile for simple key generation.

In all honesty, for a lot of smaller projects and tiny use-cases, framework-less might be the way to go, especially if your state doesn’t change around that much. However, the only issue I have with vanilla JS is that, once you get up to a pretty decent-sized app and decide to use a framework for whatever reason, it’s a bit time-consuming and…

While the React constructor is not necessary, I think there’s value in showing it off, as it is very often used. Although, in all honesty, it’s overkill for the example provided.

Component composition and reusability is something I didn’t feel that confident analyzing in this article, as it has a whole lot of aspects one has…

Generalizing about the majority of JS developers doesn’t really help get your point across and is a straight-up insult to many people that work hard to learn the language and its tools and develop software in it.

If you plan to maintain a project for over 2 years… Well, first off, good luck to you maintaining 2-year old code…

Vue allows for a lot of flexibility on how you write code, which I think I have stated in a few places in this article. However, I wanted to provide an even field to test all three frameworks, which is why I went with this kind of code. Plus, it’s gonna feel a little more familiar to people working with React, so that they can decide if Vue is for…

You raise some very worthwhile arguments here. First off, the coupling of reducers and action creators can be somewhat mitigated, but I see where the problem lies for larger projects.

As far as the whole state management and spaghetti code argument is concerned, I would say that this might be valid, but carefully designing…

The code image was generated using Carbon with the Solarized (Dark) theme. I’m pretty sure a similar theme is available in both Atom and Sublime (probably goes by the same name on both) and it might be avaible on other editors as well.

Sure, Hyperapp is limited and supports fewer patterns that might be an issue for some people. To me, a lower level framework that I can understand to its core, which also aligns with my coding style and is easy to understand is way better as a tool for a beginner developer working on a smaller project than something as complex and powerful as React.

TypeScript is one of the few things in the JS ecosystem I will never really get used to, frankly because I’m so used to all the quirks of JS and circumventing them that they barely feel like a burden anymore.

Your point about finding good patterns for React and Redux is a very valid one. What really sold Hyperapp for me is…