Johan Broddfelt
/* Comments on code */

Why I avoid frameworks

I started coding websites when Netscape introduced javascript. It was clear to me that this was the future of the web, but as everybody else, I only used it as inline triggers.

<div onClick="alert('You clicked this button');">My button</div>

Moving the javascript into the script-tag and even out into a separat file was a big step. But it helped to make the code easier to read, as the complexity in the functions grew. But the downside was that the code for the action had to be looked up in a separate file than the button were created. If that was not enough, the implementations of javascript differed from browser to browser. Enter prototype.js, the solution to all your browser issues. Still coding javascript, but if you learn a few new methods you will be eliviated from some of the weard syntax of regular javascript. Before I even got the idea of Prototype and learned the benefits of the framework, John Resig had the idea to use css tags to handle the html elements in javascript as well. That got my attention, as I was still very much focused on trying to learn how to style the web using css.

$('#my_button').click(funtion() { alert('You clicked this button'); });

At first it was great to churn out functionallity and jQuery grew with the extention jQueryUI with pre factured advanced components that could be used as plug and play. This became my goto tool for creating interactive web applications. But then a new version came out and even though most of the code still worked, I did not dare update to the latest version. All of a suden I was not able to benefit from the upgraded plugins. I was basically locked with my old code. Then came EXT.js, the complete framework for building web applications using javascript. It contained even richer plugins then jQuery and ment that you basically buidt your entire application using javascript and webservices. But the code was bulky and split up into many different javascript files with different purpouses which made it confusing and even harder to develop applications with. Even worse, at some point they released a new version and almost none of the old code worked. After a few attempts I decided to stick with regular html forms and instead of cheating with jQuery, I decided to take the time to learn to write real javascript. One positive thing was that browsers by now was more aligned in their javascript implementations and the iregularities could easily be managed by a few simple functions. That was all I needed as a framework and I have been sticking to that since then.

var addListener = function (element, eventType, handler, capture) {
    if (capture === undefined) {
        capture = false;
    if (element.addEventListener) {
        element.addEventListener(eventType, handler, capture);
    } else if (element.attachEvent) {
        element.attachEvent("on" + eventType, handler);

var myBtn = document.getElementById('my_button');
addListener(myBtn, 'click', function() { alert('You clicked this button'); });

This is the time that node.js enters the scene and alowes you to even write the backend in javasript. I did experiment a bit with it, building a chat plugin. But never realy got sold on the idea. Yes, web sockets are great and if that is what you need I'm all for it. But for building applications on the web, not so much. Instead we got an explotion of new ways to manage our javascript and css using bootstrap, material design, angular, react, vue and many more. They came so fast I only had the chanse to try them out in small projects. I will admit that I never spent enough time to be fluent in any of them, I did implement a few applications using these techniques and I never got convinced that this was the way forward. I still appreciate the clean version of vanilla html with pure css and the old fasion regular javascript. It might not be plug and play, just adding a class to an element, but it is not impossible to setup quite a complex ui with a few lines of code. Though the thing that I appreciate most of writing the code my self is that I do not have to read a ton of documentation and even hack the framework to get a component to behave as I want it to. I can just go in and change the code, and since I have written the code I know exactly where I need to make the change. I also try to write small components of my own that behave as I want them to. Which enables me to reuse them in other parts of the application and even in other applications.
Yes, there is a ton of smart code out there, that is ready to download and use. But if you are going to spend time to tweak it to fit your project anyway, why not make it your own.

The main reason I do not want to use frameworks though, is that they come in flavours of the day. There are many good ideas that are beneficial to learn and understand. But it all boils down to taste and trust that the team behind the framework will make sure your code is still working.

If you on the other hand couldn't care less about javascript and would like to use the same language for all your software needs, and want to work with a platform that has been around for over 40 years continouly supporting it's community of developers from DOS application, through windows and now taking on the web. While still allowing the developers to work with the same code that they know and love. Regardless of where it runs and even more important, the functionallity of your components are neatly package together with their functionallity without a single line of html, css or javascript. Then you should check out DataFlex and the learning center where you can get a complete overview of what the platform has to offer.

- JavaScript, DataFlex, Frameworks

Follow using RSS

<< Adding Google maps to your application


Mail (Not public)
Send mail uppdates on new comments
0 comment