Giving Medium a Go

Hi guys,

I just wanted to let you know that I'm giving Medium a go, writing stuff there and checking out the platform, which currently looks very promising.
You can find the post I've already published there under my profile under Medium:

• “What JS Framework?” is not the question
• 10 Mistakes Coders Think They’re Being Smart in Doing

And be sure to follow me on medium to get notifications on future stuff :)

Cheers and enjoy reading!

"What JS Framework?" is not the question

whud'up?

I'm hearing a lot of talk about JS framework lately and by "lately" I mean the past 4 years. I have to admit that I took a rather active part in this debate.
It will seem that once all aspects of live-streamer latest features have been covered, the modern JS developer dives into that old debate of "What JS framework should we use?", but nowadays you can count me out on this one for I think I've seen the light and have the answer which suites my questions.

To be clear, you're not going to leave this post with an answer to that question, since I believe the question has become irrelevant (at least for me). Hopefully I will be able to make you see where I'm coming from and perhaps change your perspective over this matter (or at least, get your opinions on it).

You see - I think we're asking the wrong question.
Lets start from a simpler question which is "What do we seek in frameworks?"
There are several requirements from a framework which you probably all aware of (simple impl., easy learning curve, functionality, etc...), but I've narrowed it down to this:

A safe path for solving complex application problems and provide an easy maintenance

Wait, let me get the stick out of my arse and explain what I mean in simple words.
You basically want some guidelines to take you from the requirements the product team has sent into a realization of what the code you need to write should look like. These guidelines will also ensure you that the end result will do what it should in the best way possible (considering performance among other) and also give us a clear path for modifying it easily and enhance it with little effort.
Are you sensing where I'm going with this? not yet? keep reading.

So say I found a JS Framework which does answer these requirements I've mentioned above for a specific feature I'm about to implement, and you know what, it seems that this framework can also fit other features that are on the pipe, but wait... it doesn't quite fit that last feature and not this one and oh man... not again.
This probably the reason new frameworks are released every second. It is because none of these frameworks solve ALL the complexities the rich web application presents. I never encountered one which does, but I will be happy to be proven wrong.

If we get back to the thing we seek in a framework the more experienced developers among you might smell something familiar. Isn't this what Design Patterns are all about?
Very early on the software development history some smart people (4 in particular) realized that there are many problems in software development, and that these problems may appear in many different forms and formats but most (dare I say all) fit into these patterns and can be solved by them. It is also important to notice that it was also realized back then that there are more then a single pattern for there are more then a single type of problem.
Now you are probably saying "well duh!", but hey - weren't we arguing about that single framework which answer all a minute ago... ?

So if I was to use Vanilla JS, I would probably go and use the design pattern which fits the problem I have at hand. Maybe a "Singleton" fits here, but there the "Command" design pattern fits better, every feature, or sub-feature, demands it's most suitable solution.
This is great, but I don't want to re-invent the wheel for each of these patterns and re-implement it, so I will look under the frameworks at hand. Sadly these frameworks have their own way of solving problem which sometimes, due to their overall inner implementation and agenda, sail far-far away from the design pattern which is the most suitable, for instance some frameworks strongly believe in Singletons but neglecting the Command design pattern altogether.

ok, ok hold on.
I'm not saying that there isn't any room for JS Frameworks and I'm definitely not saying that you shouldn't use libraries. All I'm saying is that you can't argue that the tool you've happened to choose, say a hammer, is also a great screwdriver. It's just not, and if you'll try to force it into becoming a screwdriver you either break the screw or your hand.
Even a Letherman multi-tool has it's limitation. There isn't a framework which answer all software problems, so for the love of god, stopping arguing over it.

but wait there for a sec, what about these Design Patterns? can we take advantage of them?
sure! why the hell not?
They are out there and do not enforce any language or syntax for they are mere concepts. So if you still want to pick a JS framework, pick the one which allows you to incorporate your chosen design pattern without risking the entire structure of the application.

I think that in today's world we are starting to realize that frameworks not only masks us from understanding the JS under-the-hood but they mask us from the design patterns we need to learn and understand. The same as I want modularity when coding, I also want it in my tools, libraries, and frameworks. This is, BTW, the reason I believe ReactJS caught up with the developers community for it offered a solution for the "V" in MVC. Forget the whole "Flux", "Redux" and other shit that is popping out now, I'm talking about ReactJS alone - it doesn't tie your hands in any way to use whatever design pattern you want (and even then some might argue that it does).

So what's the bottom line?
Learn about Design Patterns. See which one fit your problem and seek to implement the best solution. If your JS Framework holds you from doing that, you have the wrong framework. The more skinny the framework you use, the better. If you can reduce into a library, like say Backbone, that will even give you more freedom.

("Backbone is a library, not a framework, and plays well with others."  Backbone docs)

And... for the love of god, stop asking which JS Framework to use :)

Take care

10 years of blogging

Hi,

December 22nd 2005 was the day the first post under this blog came out.
The post was in Hebrew and back then it took a lot of effort to make Blogger display RTL languages well, which is what I babbled about most of the post.
It's amazing to believe that 10 years have gone by since then, with me shifting between technologies and employers, and even sacrificing my native tongue (and your delicate sense of grammar) so that this "thing" I've created can keep on living.

This blog has served me so well over the years, and keeps on doing so.
It is my stage for ranting and bashing technologies (and sometimes the people behind them). It is the place I use to keep learning and exploring more, sharing anything cool I see on the way or think about, without taking myself nor the industry too seriously.
This place, like a good journal,  reminds me where I came from and where I wanna be. This blog, as the sub-title says, is my individual thought patterns (wink-wink, do you know where this line came from?) and I always find it amazing that you guys are reading this and finding it worth while.

So what's next?
Probably write some more :)
As you know, I don't write shit just for the sake of writing, and sometimes life courses leave me with little time to sit and shape sentences and ideas, but let me tell you this - this blog is still a passion I have that I don't see going away anytime soon. There are a lot of topics running in my mind which I can't wait to put on "paper".
I feel that 2016, and hopefully the years to follow, will be of more technology content, for I returned to my roots of coding and have new insights about the shift the industry is undergoing both technologically and conceptually.

One truth remains - I love making stuff, I love the creation process and this blog is just another brick it that wall.

Stay tuned guys...

Matti

Basic Webpack with ES6, JSX and React

Hi there,

I promised (sort of) on my twitter account that I will look into the integration of Webpack with ES6, JSX and React, you know, just because I read a little about Webpack and it does seems like a very nice solution for bundling JS modules and static assets while slicing them into chucks which can later be loaded on demand.
Before jumping into anything, a series of POC's is probably what you should do, so here is the first one on my behalf.

So how well and easy can Webpack be integrated with the latest out there, which is basically ES6 and React (but it does not have to be React. It can be pretty much anything)?

After playing with it for little less than an hour, I have a nice example which demonstrate how one can bring up a client to life, with ES6 and basic (I mean basic) react view, all this with the benefits of live reload. If that's interesting to you, keep reading:

BTW - All the code can be found on GitHub, so you can reference it along the way.

first off, I've created and empty folder and 'npm init' it.
Now I was able to install Webpack to the project (I generally don't install on the global scope, but you can if you have no fear of backward compatibility mess) along side with webpack-dev-server.
It is this webpack-dev-server which will enable me to listen to any change made on the source files, bundle them on the spot and render the page with the latest changes, no gulp, grunt or what-have-you involved.

Now I need a configuration file for Webpack, which defines which is the entry file, and what loaders participate on this compilation (among others). If you have no idea what those are, please read more about them on the Webpack site.
As you can see from many example on the web, the configuration file is using a CommonJS-like module system which is different than what ES6 is using, so if to be pure, the configuration file should also support the ES6 module system and for that we need to do 3 things:

• Install babel on the project using 'npm install babel --save-dev'
• Change the configuration file to export the module the way ES6 does
• Change the name of the configuration file to be "webpack.config.babel.js"

There you go, you're configuration is now pure ES6.

Now we would like to start coding the actual stuff, which is in my case a simple "Hello React" component and render it to the DOM. I created a file for the component which has JSX for displaying the caption.
At this stage you are probably wondering what takes that lovely ES6 code (not to mention that lovely JSX) and converts it to plain old ES5 - well, for this we have the Babel webpack loader. We install it using npm again, and define it on the webpack configuration (check out the code on GitHub).

The entry file now imports that component I've just made and uses React to render it to the DOM, and that's about it.
Launching the web server using the webpack-dev-server we can now safely browse to localhost:8080/webpack-dev-server and see for our eyes the wonderful caption.

Now... let me see if I forgot anything. No. I think that I have all covered so far.
If you have any comments or questions you can comment below.

Hope this helps you :)

Cheers

ES6, Babel and all between

So...
Keeping pace with the latest JS progress? it's mad, I know.
I would like however to talk about the fundamental staff which is changing under our feet, more precisely - ES6.

ES6 or ECMAScript 2015 (catchy, indeed...) was recently finalized and all the web is swarming about it, though the browsers do not fully support it, which is like showing a candy to a child but behind a glass window.
Thing is, that along side with it came the era of Transpilers with TypeScript and CoffeeScript standing out from the rest and for a long time I was trying to decide which path is more reasonable to follow.

I know that the comparison is not exactly symmetric, but you have to admit that ES6 can sometimes be seen as a mere transpiler especially when using Babel, though it is not... and TypeScript is gaining more and more popularity now that Angular decided to embrace it on their 2nd version, added to that VSCode which support TypeScript so nicely and you have a nice debate inside your head.

Having said all the above, I would like to share my reasons of why I think on going with ES6.

ES6 is not a Transpiler Syntax

Setting Babel aside for a minute, ES6 is the new standard of writing JS soon to be embraced with it's full capabilities by every browser which respects itself. This will not be a ES5 under the hood, but rather a JS engine which knows to read and execute the new syntax, with optimizations which come along. This is an important thing to understand, for most transpilers convert their syntax to plain ES5.
Now TypeScript can transpile their content into ES6, with features that keep on adding to the supported stack, but you need to realize that the process today will probably look like this -

TypeScript >> ES6 >> ES5

Since we said that browsers do not support the full spec and so we have to transpile ES6 to ES5, which does not make much sense to me.

TypeScript is a proprietary Transpiler

Yes, you know it.
Microsoft is the proud parent of TypeScript. Not that there is anything wrong with it, but it kinda makes you think of it's future, whereas ES6 is the De-facto ECMA standard which does not belong to anyone.
Don't know about you, but I remember some time ago that one Steve Jobs (and many top industry personas followed) said that having a proprietary technology is bad and this is one of the reasons Flash should be banned from the web. So why treat TypeScript any different?
This can mean that Microsoft might cease to support it, or go in a direction which fits it's own interests but not the common web development agenda.
You can look at GWT as Google's sort-of proprietary transpiler. Where the hell is it now?

Babel is cool

Damn it's cool.
If you don't know what Babel is please go and check it out. There is nothing too complex about it, just a simple tool which takes your ES6 and spits out ES5 on the other end. There are other tools which do that, but Babel seem to be the one growing on the community these days.
BTW - It's also very interesting to see how it implements the new ES6 capabilities into an old ES5 implementation.
One more thing - you can also run node on ES6 mode, with babel-node, which is cool cause you can start writing the backend in ES6 as well.
But please note - this is ES5 in the end, so what you're getting from it is just the chance to experience with ES6 and perhaps you will lose some performance over what Babel does with the code in order to convert it to ES5.


So basically, what I'm saying is this:
Soon all new JS code will be ES6 and browsers will support it to the fullest.
ES6 does not belong to any cooperation and you can start using it now, to the fullest, with tools like Babel, and later on, you will simply drop Babel from the stack and stay with the JS engine of your chosen platform.
You simply prepare for the future, with basically no risks... why not go there?

Do you feel I'm missing something here?
Do you have a reason not to start coding in ES6?
Please share...

Cheers

Check it out - You Can't Be Great without Technical Excellence

Hi,

I wondered and bumped into this great presentation which again states what many of us already know but still wonder how come this is not common knowledge and practice.
This presentation is given by James Grenning, which I had no idea who he was prior to watching it, but it makes no difference...

The presentation can be found here.

James, after bubbling a little bit about agile, makes some strong points which even the thickest mind can grasp and relate to. To be honest, one's head should be really stuck in his rear bottom in order not to see the light James is talking about.

The mathematics of thinking before doing, TDD and code-quality is so evident it seems that this talk is redundant, but sadly it's not.

If you're impatient, allow me to point you to certain parts of the presentation which sums it nicely:

• 17:35m -  WTF is a "hardening" period (which some of you may know as "stabilization" period)?
• 23:15m - Not doing TDD is like...
• 30:30m - What happens when practicing Development followed by Testing
• 55:55m - Yes, you are special but it does not matter.
• 1:01:10 - Motivating and De-motivation

 Enjoy

Stop and Resume Binding in AngularJS

Hi,

There comes a time when you need to tweak the native behavior of a framework.
For me it was pretty straight forward desire to stop and resume binding for DOM elements.

The reason behind it was that sometimes I have several elements on the DOM which listen to the same data, but not all of them are viewable. Only one of them is viewable and this is the one I would like the binding to keep updating, while the rest shut the hell up and do nothing over the data changes.

AngularJs is not too kind when it comes to tempering with it's biding mechanism and I guess they have they reasons. The binding mechanism is something that can dramatically affect the performance of an application.

If you go little bit deeper (really, no too deep) you find that binding is all about the digest cycle which in turn invoke watchers, which are functions set to watch for changes and invoke callback accordingly. It is these $$watchers which you would like to remove and retrieve in order to connect and disconnect to the digest cycle.

I've made a simple POC where I created DOM with 2 identical directive bound to the same data on their parent scope. I also added buttons to toggle their binding - pressing it once cuts off the binding for a specific directive while the other keeps on updating. Another click resumes the binding.

Simple - you can find the code here on Plunker

Take care.