When React Hooks arrived in 2019, switching to functional components seemed impractical. But as the ecosystem evolved, new techniques emerged. This article explores key strategies for migrating class-based components to modern React patterns—leveraging composition, useImperativeHandle, and function-based customization. Ready to embrace the future of React?
Ive been working with Backbone for years and it suited me pretty well. I do love its conciseness. It gives the desired abstraction and yet leaves you at the full control of your app. When you need to know what exactly is happening in your app behind your code, its matter of minutes to go though the Backbone annotated sources and figure out the flow. Thats something you hardly can afford with other frameworks such as Angular, React, Vue or Amber. Besides its ridiculously small - its less than 8Kb without dependencies where the dependencies can be dropped if you go with Exoskeleton and Backbone.NativeView. I know that few today care about download size, but I do as it still affects the user response time.
JavaScript applications have been growing in size and complexity increasingly over the past years. That brings new requirements for code maintainability where encapsulation gets crucial. While AMD implementation of modular design in JavaScript is wide-spread, CommonJS Modules/1.1 is are mostly used for server-side JavaScript only. Nonetheless this standard can be applied beneficially in-browser a well. Precompiled CJS has its advantages. Besides cleaner syntax comparing to AMD approach it may boost the performance of ones application by reducing the number of HTTP requests while the code stays well-grained. Here we are going to talk on how to achieve an efficient JavaScript code design by using CommonJS compiler.
JavaScript frameworks have been proliferating recently with a frightening rate. Just take a look at TodoMVC that provides dozens of MV* framework-specific implementation for a single task. It gives a felling how must be confused a developer making a choice for a framework.
Some time ago I even ran into a manifesto (bitworking.org/news/2014/05/zero_framework_manifesto) against JavaScript frameworks. I do not completely agree with the author, yet he has a point – it’s too many of them, too many of meta-languages to study that you as a web-developer may not need at all. Most of the frameworks contain plenty of code (AngularJS - 22K LOC, Ember.js – 43K LOC) and if you hope to know what is really going on in your application you have to study every line of this code. Let’s assume 3-5 of the trending frameworks are thoroughly tested by the communities, but what about others? Are you ready to spare days and weeks digging in someone’s code looking for traps and leaks in there?
JavaScript was designed as a script language that is easy to embed in a larger host system and meant to manipulate the objects of the host system. With the advance of HTML5 formerly mostly static web-pages are turning into sophisticated web-applications. Now we expect JavaScript code to be scalable and modular. But how when JavaScript has no built-in facilities to combine distinct scripts?
A substantial web application doesn't need to wait until all the required JavaScript libraries loaded. Usually most of them can load asynchronously and start acting whenever they are ready. Most commonly used approach here would be AMD. That's a sophisticated and time-proved solution. However to use it with libraries, you must have them converted to modules. I don't appreciate the idea to interfere with 3-rd party library code. At the same time I still need non-blocking loading and dependency being resolved in my code. Thus, I worked out a very simple, but yet working solution.
Not so long ago Microsoft announced a new language, targeting on front-end developers. Everybodys first reaction was like Why on Earth?! Is it just Microsoft darting back to Google? Is that a trick to promote their Visual Studio?
But anyway, whats wrong with JavaScript? Why everybody is so keen to replace it? JavaScript for a language designed in only 2 weeks is freakishly powerful and flexible. But JavaScript still has its bad parts.
After Microsoft released TypeScript I took a look at their examples and found the idea pretty promising. I do love JavaScript. However, it has its bad parts. JavaScript doesn’t provide any built-in facilities to declare interfaces or object abstraction. There is no explicit way to have type annotations and type checking. Well, even class-based OOP is not a part of the language. Flexibility of JavaScript is incredible. So, there are tons of libraries meant to work-around these inconveniences. It hardly helps with code readability. At the same time TypeScript is a separate consistent language, which is, nonetheless, first and foremost a superset of JavaScript. You can use regular JavaScript within TypeScript and TypeScript is being transformed to JavaScript by TypeScript compiler.
I went through the specification and started writing design pattern examples on TypeScript to get a feel on the language.
Any diligent developer is constantly working on improving his or her code. There are plenty of books telling how to make your code better. However most of them use the language of class-based OOP. Reader must have enough of experience to reflect those classical design patterns on JavaScript. Thus, many and many developers give up on the language before mastering its true power. On the other hand, JavaScript is an incredible impressive language. I wonder if JavaScript was originally designed as a foundation on which you build your own language.
About 2 years ago I had worked out a solution which developed by now into a light-weight library which brings into JavaScript everything I miss in the language as a follower of class-based OOP
The classical design of object in JavaScript may look pretty clumsy. So I prefer the module design propagated so indefatigably by Addy Osmani (addyosmani.com/largescalejavascript/). We keep all the declarations within the function body. Public members placed in the object, which the constructor function returns. It looks much nicer. But, here shows up a problem. Common implementation for inheritance doesnt work on such objects. Lets study how exactly JavaScript instantiates objects and come up with a solution for our requirements.
Design by contract (DbC) is an approach in application design, which originally came from Eiffel, but now widely used on different languages (particularly in Java). In real world one party (supplier) makes an offer for an agreement (business contract) and another one (client) accepts. The same way can be described relations between objects in software engineering. As a declared agreement is accepted by the client object, the last one is expected to keep its rules.
I’ve already described an approach of using MVC in Drupal . It wasn’t bad for the beginning I hope. Though in real life you face requirements which hardly can be fulfilled with such a simplicity. In, more or less, complex application you ain’t going to be satisfied by the only controller (page controller) to serve the whole bunch of components presented on the page. So, let’s assume we have a page full of components and each of them can behave differently. It means we need controllers and views for them. Reminds of Java portlets, doesn’t it? Such components are often referred as modules in IA, but I don’t dare to call them so in this context to avoid any confusion because of Drupal modules. So, let’s go with widgets.
If you work with Zend Framework, you likely tried ZF Console (Zend_Tool on command line). But have you tried to extend it? Why? To have common interface for all your Cli-scripts related to ZF-base project. How do you find the idea to program Cli-scripts in MVC? Zend Framework provides us with the tool to do it.
Web projects have grown far more complex. Teams are larger, backlogs shift throughout development, and time-based estimates often fall apart. Feature Driven Development (FDD) is an Agile methodology built for exactly this environment. This article walks through its four stages: Develop Overall Model, Build Feature List, Plan By Feature, and Design and Build By Feature.
Aspect Oriented Software Development (AOSD) is a methodology meant to implement new aspects in software component using external components, but without altering the code that implements the core functionality.
The AOSD concept was applied originally by Java developers. They developed a compiler that implements the AOP (Aspect-Oriented Programming, an implementation of AOSD) white box approach, i.e. the compiler the merges the code that implements the software components core functionality with the necessary code alterations to implement the new aspects where necessary.
This paper provides an introduction into the paradigm of aspect-oriented software development (AOSD). It includes a multitude of practical examples, provided with a view to objectify such abstract approach as AOSD, as well as to help the reader easily grasp its essence and advantages. The paper is primarily intended for programmers working with PHP. Its aim is to demonstrate a way of applying AOSD in PHP-based projects already today.
