From Framework To Native

Daniel Dekel
5 min readJun 2, 2021

It’s said that shortcuts can be expensive.

Photo from PhotoMIX Company in Pexels

Can we say that a Framework is also a shortcut?

It is definitely a shortcut because the alternative is to write it yourself.
So now the question is — “Is it really worth doing it by yourself?
It depends on many factors. I’ll tell you about my experience.

A bit of my background…

I work in a small to medium company and we are various web development teams, most of them focusing on the same product in different areas.

As in most companies, you have people with different expertise, some people better in backend and some in the front end. Some are great in UI but weaker in programming. My challenge 10 years ago was to choose a framework that will be simple enough for all types of developers but at the same time be robust and efficient for the type of product we tried to develop.

The result was building a new framework something similar to Adobe Flex if you remember. XML files that would describe a web page. That could guarantee a similar user experience for the end-user as the UI was generated from kind of components and all the lazy loading and technical challenges put behind a nice interface.

It was great, worked like a charm, but after some time my team ended up spending too much time supporting that framework instead of adding new features. Also, the developers needed to spend too much time learning that new XML language.

After a few years, a new type of frameworks came to life and after some research, we’ve decided to switch to Angular JS. The challenge there was to move 2 years if development code into a new one. So all the development teams stopped all their projects and spent months migrating to the new framework.

Once it was all done, we started making very good progress in new features. What can go wrong here, right?

Well, as you probably know Angular JS Is no longer in development and we ended up facing the same challenge, only this time we had much, much more code to migrate.

Now what?

The first logical move was to switch to Angular 2, but there is no easy way of just switching. Also, the coding is very different and even though I’ve done some projects in TypeScript, I’m not convinced this is the way to go forward.

I knew that any other framework will require re-building everything from scratch and just the thought that in 2–3 years we will have to go through that process again didn’t convince me that it was the right way.

I was trying to think out of the box, reading different strategies. In the end, I came with a solution that instead of switching all at once, will allow us to start with new code and still keep it compatible with whatever framework we have in the future.

The solution… JavaScript ;-)

The idea is to start in small areas; an area of our code that is usually reusable like a component and convert it into pure JavaScript, without dependencies apart from small ones like JQuery.

The next step was to start prototyping a new platform and add the pure JS component. Now we have two different clients sharing parts of the code.

The idea is that any new component will be created only once using pure JS.

From my experience, a framework can have a life expectancy of 3–5 years, after that you are on your own. JavaScript, however, will have a much higher life expectancy, there is less gambling in this case.

What about libraries?

Another thing that came out as a result of this transformation was that I’ve forgotten how easy is to write things in JS. The language evolved in a way that there is not even a need to use JQuery.

Now you might say — “but is still quite complicated to do things without JQuery”
That’s true, but, I also think that “complexity” makes you write better code.
For example, if you need to attach an event to an element in JQuery, you just do:

$(“.my-element”).on(“click”, theEventHandler);

Even if that element does not exist, the “on” method will not fail.
But if you think about it, it is actually failing silently without you knowing about it and therefore have unexpected results in the logic.
So in JavaScript, you will need to assign the element to a variable, check if it is not undefined and then attach the event.

Like it or not, I think it is a much better way to write your code.

I would love these components to be based on Web Components, but unfortunately, we need to support the old Internet Explorer, so for now, we can’t use the new cool technology except some specific areas we know it will only be used by new browsers like PWA for example.

Libraries have a very important role in the development of the JavaScript language. Thanks to many of these the language evolved and much of the functionality has been adopted. Take Mustache and Template literals. Lodash and many of its functions and of course JQuery.
I will probably talk about this subject in a later post.

So, I still think is OK to use libraries but I would wrap these with my own functions (and interface). That will create less dependency on libraries all around your code.
If you would like to upgrade or change a 3rd party library all you have to do is update your wrappers but not your code. Also, a very nice way is to use polyfills.

…and UI Libraries?

Some of the libraries are great and give you a very quick starting point without much effort.
The problem comes with time. Similar to JS libraries, you build dependencies between the HTML and the CSS classes and sometimes even to JS code you make and 3rd party components. Now, imagine you want to upgrade to a new or different UI library. Replacing that chain can be very painful and sometimes impossible unless you re-write.
Remember, same as JavaScript, CSS evolved so much that many times you don’t need complex Grid implementations because you already have that implemented in CSS.
Remember, the solution might be simpler than you think!

Conclusion

Frameworks are good if you want to build a small and short term project. If your project is the root of your product and you want it to live for a long period of time, is better to go the longer path and use your own code. That way you will have full control of everything as long as you design it properly of course.

If you are not so experienced in architecture, the frameworks will give you a very clear path to how to build the application.

I suggest taking some time and read about architecture and design patterns and with that, you will be able to create your own framework.

Thank you and good luck!

I would love to read your comments questions and suggestions!

--

--

Daniel Dekel

Passionate about UI, UX, and Accessibility. Love dealing with the code in the front and back-end.