build with purpose

Logic Eludes Javascript Frameworks

I’ve recently been unfortunate enough to work on the impending migration away from AngularJS toward the new Angular. Eventually AngularJS will be officially deprecated by the Angular team once Angular 2+ overtakes its predecessor. When that happens, security vulnerabilities may keep AngularJS from being used in production apps. This means now is the time to get out!

I’ve recently been learning Angular with TypeScript and just want to say I really hate every single build system I’ve seen thus far. Nothing is simple and there are so many damn dependencies. I would like to warn you away from their introductory tutorial’s build system as it is inconsistent with how most Angular apps seem to be built and it’s very inflexible based on my findings. I’ll be sure to write a post if I manage to find a flexible custom build system that fits my needs.

This big push to migrate and update to the most recent version means that a lot of code is going to need to change. Fortunately most vanilla JavaScript code seems to work across all frameworks and can be coppied directly to the updated project, but a lot of logic can’t be. I’ve identified some areas where I think problems exist when migrating:

Template Language Logic

Every framework worth it’s download size seems to think about templating and provide some solution. We seem more than happy to shove as much logic as possible right into whatever they make available to us. One place to go for everything involved in the creation of that view! Awesome! (or is it?)

Controller/State/Component Functions Logic

Another thing frameworks offer is a handy component or controller function to help you deal with your UI. This is needed and has been done in the early days of JavaScript with jQuery. Since this is part of our history it makes sense that our natural reaction would be to tie a lot of logic and functionality right to it. Eventually all of our logic can wind up here since it’s where everything in the view is happening anyway, right?

STOP

Coupling too tightly to any front end is why it’s difficult to switch frameworks, versions of frameworks, or even import new libraries. Templating languages should only be used to display data and receive events. Controllers should only be used to process events and pipe processed data into the UI. Neither templating languages nor controllers should be used directly to manipulate data in a meaningful way. Anything else produces too tight of a bind.

The counterpoint makes sense if you look back a couple years to Pre-ES6 land. In those dark days we didn’t have a concept of modules and you had little guidance on where to put JavaScript code when working within a framework. AngularJS, for example, actually created its own module system so that users didn’t have to figure it out on their own. Other frameworks followed suit and it makes sense that we’re so tightly bound to our frameworks.

Recovery

Modules with import and export make it a lot easier for us to control our own code. We should start to move much of our logic away from these imposing frameworks into trusty vanilla JavaScript modules that can be injected into controllers and components. If we realize that this is a problem and we work to fix it, I think our code can be much more maintainable and easier to reason about.

If you’re interested in learning more about modules checkout the “You Don’t Know JS” Organization chapter about modules.

Make my day and share this post:

Other posts to peak your interest:

  • Understanding Visual Testing
  • The Redux Saga Black Box
  • What my college degree gave me
  • Technical Leaders Enabling Stronger Teams
  • Finding Your Gateway to Learning Vue
  • Why Write Server Rendered Frontend Apps
  • comments powered by Disqus
    © 2019. All rights reserved.