Whenever people question the new ways of doing things, I am reminded of one of the greatest quotes by the Sanskrit poet Kalidasa (4th century CE).
“Just because its old, something cannot be assumed right. Just because its new, something can’t be brushed away. The smart ones analyze and adapt, the fools are swayed by others’ opinions”.
Many retweets, faves, dislikes, epics, savages later, the question still remains: What is the right language or framework?
The separation of technologies then, say 15 years ago, was not intentional. It was a necessity of times. CSS, HTML, JS were advancing independently, performance in browsers were so poor and finding an engineer who could do all was almost impossible. But now, we still have specialists designers and developers, but in general they have a good idea about the other technologies. I still remember back in my IBM days, pointing out to JSP structures to our designer, on where to make style changes. But now these frameworks and their idiosyncrasies are not strange to designers.
Here is a fundamental question: Have we got anything right at all in the programming industry at the first stab? Or is 50 years too short to judge? The real limit of the problem is that physiologically, human brains can only process a limited amount of information, so it has to break complex into simple pieces. Eventually the simple pieces evolve to become complex enough, or perhaps our brains shrink so it perceives simple things as complex. So they have to be broken again. But the broken simple pieces have something in common with previously broken simpler pieces that they have to re-integrated. Thus we swing into an eternal pendulum of centralization and distribution.
Here is an illustration with evolution of Java, but you can substitute it with any starter technology:
- Java and JVM were originally built for small devices
- But once it entered application server space, EJBs were added to tackle distributed environments.
- EJBs became so complex, it was abandoned and broken into smaller pieces
- Smaller pieces were dependency-injected to form a bigger solution, but eventually they grouped into micro services
- Micro-services combined with distributed systems to facilitate container architectures, like Docker
- Container architectures are becoming complex and are yielding to orchestration solutions like Swarm and Kubernetes
- Predictably, By induction, orchestration solutions will become complex and will yield to Local Clouds
- Predictably, commodity local clouds will be broken into Fogs, Cirrus, Altostratus, Cumulus … and delivered by drones.
- Predictably, Drones functionality will super-evolve, so they will eventually need a new programming language specifically written for small devices… well…
Much like a fractal, as we dissolve complex problems into simple solutions, they just take a new shape of complexity, due to external influences (mobile, bandwidth for eg). The point is – This cycle will never end.
Working as a Web + Network application engineer (on the SDN controller OpenDaylight) I am seeing two ends (philosophically speaking, they are the ends and the means respectively) of a spectrum. Both UI and Network are always evolving in interesting ways, yet we can analyze these two into a fundamental problem statement:
Network: Deliver content (a packet) from one place to another place, efficiently.
UI: Deliver content (html) from one place to another place, for a user friendly read.
(Of course I am intentionally oversimplifying, but as an end user, when your bandwidth drops below 1Mbps, you call up the customer service to negotiate a discount, not enquire the complexity of the network protocols).
But just to solve the packet delivery problem, think about myriads of protocols and schemes created – TCP/IP, VLAN, MPLS, BGP, VXLAN, OpenFlow, NETCONF and many combinations of these. Similarly in the UI world, all we have to do is deliver readable content, but there are so many aspects and choose-your-noun libraries CSS, SASS, WebPack, D3, Material, visualization, accessibility, modularity, layouts and the most subjective of all – Colors!
So why do front-end developers keep seeking and preferring newer frameworks? There are many reasons and not all are technical. The fundamental reason is: Boredom. Human mind always seeks something new. Not because its useful, but it has to be something just different. And perhaps have a personality.
For any framework in general, to be popular and become sustaining, it should satisfy ALL these conditions:
- A very nice familiar sounding easy-to-pronounce name
- Should NOT be one person driven
- Code should be easy to change and testable
- Good documentation
- Not do too much magic
- Ability to teach it easily to others
The golden rule of framework success is this: It takes a few smart developers to create an idea. It takes a few hundred average developers to sustain it, because the smart developers have moved on to a new idea.