In my free time I have been working on a few standalone libraries for personal use, and had quite some boilerplate to setup the object dependency tree that I needed within the scope of the library.
There are varying opinions on whether Javascript needs dependency injection. Instead of arguing about it, I decided to write a small but powerful enough ioc npm module that provides simple ioc for my needs. If you’re using Typescript, then InversifyJS already offers what you need, but in my case I‘m just using JS.
The npm library can be installed through:
npm i -S es-ioc
Everybody who works in the industry knows that there is an overload of client-side programming languages and frameworks which poses a problem for programmers and recruiters alike:
Programmers are getting vendor locked-in, recruiters must be pulling their hair trying to fill all those gaps.
I’ve had this itch for a long time, but just happened to…
This article describes a simple setup that I have made for hot reloading my isomorphic webapp that is capable of auto-refreshing the browser. It is not perfect, but can easily be modified and adapted as desired.
If you disagree, have proposals for improvement, or a better idea on how you would build your setup, don’t hesitate to share it in the comments.
Head over to the github repo that I prepared: https://github.com/kimgysen/isomorphic-react-setup
There are 2 branches:
Installing and starting either develop or production builds…
Although these optimization patterns have been popularized by bundling tools like Webpack, the idea is not library specific. The intention of this article is to clarify the patterns and their use cases; then the implementation is simply a matter of syntax.
In the default case without splitting anything, the entire Javascript app is generated and downloaded as a single bundle. The standard procedure looks in general something like this:
The bundling process is usually performed based on a defined entry, which is a single file from where the dependency tree is walked to see which files need to be included…
This is a short blog post in with I want to express my personal point of view on when and why configuration over code matters, especially in the Javascript world.
This may again be a somewhat controversial topic, and don’t hesitate to share you own opinion and disagreements in the comment section.
There are 3 main schools of thought on coding style regarding the topic:
The general opinion is that you can choose which ever style that you prefer. I respectfully disagree with this, as it is not really a choice…
I am currently working as a frontend (Javascript) developer consultant, but originally started as a Java developer. I will not bore you further with my background, as the message that I would like to share is more important.
In this article I want to discuss the reasons why I believe that most Javascript (but not only Javascript) code bases will not be able to survive over time.
But this is not intended to be a rant; rather would I like to offer some insight.
This article is a bit philosophical and I believe that it may be a bit of…