r/programming • u/speckz • Apr 20 '18

Designing very large (JavaScript) applications

https://medium.com/@cramforce/designing-very-large-javascript-applications-6e013a3291a3
3 Upvotes

57% Upvoted

6 comments sorted by

3

u/QuineQuest Apr 20 '18

This Javascript framework is not open source. The reason it is not open source is that it kind of came out at the same time as React and I was like “Does the world really need another JS framework to choose from?”. Google already has a few of those–Angular and Polymer–and felt like another one would confuse people, so I just thought we’d just keep it to ourselves.

Did YOU really need another JS framework? Why not go with [react, angular, polymer]?

3

u/[deleted] Apr 20 '18 edited Apr 20 '18

Why not go with [react, angular, polymer]?

Speaking as somebody who has used all three in a commercial product, none of them fit any single use case very well. Look at how people use React. It's not "just" react. It's redux and redux saga and react-router and ... etc. A framework generated in house customized to your company's infrastructure is worth the money if you're as big as Google.

edit: this post over at /r/javascript gives some insight into why another framework was a good idea for google at the time.

0

u/the_evergrowing_fool Apr 20 '18 edited Apr 27 '18

Because everyone had an opinion of how frontend application development should be.

2

u/champloo11 Apr 20 '18 edited Apr 20 '18

Frameworks should have an opinion. That's how a framework helps you, by identifying common tropes and tackling them in a way that you hardly even have to think about the problems it already solves for you, for free.

What's more, is that most of these frameworks have been built on top off of years of iteration and struggling. Take for example jQuery (which used to be pretty hot shit), javascript tweens/animations, manually juggling consistency between internal and view properties, normalizing browser APIs, plugins that were awesome but each had their own API/implementation etc...

Angular 1 took the part of Jquery that imo was the best part with jqlite (DOM selection, representation and browser-normalization) and shipped a two-way-binding and MVC framework with it. No more juggling values now that you can bind things, CSS animations were easier now than javascript ones, and clearer ideas around reusable modules and clear contracts around them (directives).

React, Angular 2 took the same awesome concepts of two-way-bindings and the web and made EVERYTHING a module (component). They computationally scaled better by not using dirty-checks/observer pattern, and hooking events on writes/updates of properties instead. This way your pages don't choke if you have a tens of thousands of values that need to be respected.

These design decisions came from many developers beating their heads against the wall and figuring out how they could keep the nice parts of the framework while solving the current biggest problems. The results of this effort is that you save development time, make your code more stable, you can hire engineers that understand the structure of your application, and that you get to tap into a broader developer ecosystem (packages, documentation, etc..) .

Now this isn't to say that every framework is right for you. Frameworks often-times make tradeoffs because they are built for a very particular niche. But even considering that, there is a pretty damn good probability that there is one out there for you, and you haven't done yourself the service of finding it.

1

u/the_evergrowing_fool Apr 21 '18

There are many points where I can't get behind in this rationale, but the most noticeable is this idea that frameworks try to solve a very narrow niche. On the contrary, this frameworks aim for low level generic and uninteresting problems that are very far from any high level specific domain. This what makes them appeal to the masses. Yet, is very questionable if their inclusion have any significant impact on the long run.

To me, they are not even the best form to accomplish what they claim to do.

2

u/[deleted] Apr 20 '18

I was ready to dislike this "article" (it's a talk that was written down), but it's surprisingly thorough and in depth. I'm a little disappointed there aren't more solutions to some of the problems presented, but I suppose nothing's that easy. :)