No more JavaScript frameworks
bitworking.org
bitworking.org
I've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).
As for preferring library over frameworks, sure why not. There are tons of reason to be able to do things other than the way that is described by a framework, but when you start to have teams bigger than 20, of different time zones, with varying skill level (important point here), having a prescribed way to do things may not be such a bad thing. There will be time to break the rules of the framework, but hopefully your choice of framework is good enough that it should only be less than 10% of the case.
To this, I can say that despite the failing of AngularJS, some teams just cannot live without it. Its very prescriptive to the point that people who a very good at Javascript may find it repulsive. But those prescription are just too robust for some team to abandon it and go for a more performant framework.
And there is a lot of companies that can't hire Google level developers. These people may not know Javascript enough, but are okay as long as there are good prescriptive example of how to do things. They should still aspire to be good at Javascript (or any language at that...), but sometimes that seems to be too much to expect for the portion of them. Sure, this is not ideal, but you have to remember, there are a lot of places in the world that IT is a cost center.
The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago. The amount of experience and expertise that is being codified in (for example) Ember.js is fantastic and will allow you write much richer web apps in far less code than trying to achieve the same functionality with it.
Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
Web site, think blog, information landing page, or even web store product page(s).
Web app is highly interactive (may or may not be an SPA single page app), relying heavily on javascript for UI events, saving/fetching application state, remote datasets, and sometimes making use of modern HTML5 browser features.
Web site is displaying information and is just augmented with some javascript mostly for improving the UX or attaching analytics/social plugins etc.
In other words as someone else noted, it is a sandboxed application with
sandbox execution environment == browser IO == REST UI = HTML5 DOM manipulation of the same page
A website (or server app) is a series of HTML5 web apps or HTML5 static pages (JS-less web apps) with navigation logic and inter-app state living in a server app.
Thus I am a complex website engineer. It sounds ridiculous. The webapp developer is domain knowledge wise closer to traditional "application development" than to traditional "website development".
Web App are application like website.
So instead of traditional application/program such as Quicken we got Mint.com now. It makes application OS agnostic now too.
Web sites are bunch of pages that are hot link or connected via URL. Think of the old days of geocities, xoom, tripod, etc..
web sites are content centric and made for consuming it.
web apps are interaction centric and made to "do" something.
Note that this definition means that certain pieces of software could be considered either "sites" or "apps", depending on how they're being used.
For instance, blog software like Wordpress would be a "site" for the readers, but an "app" for the person who writes the posts.
One part is an editing software/gui and one part is a reading software/gui. Both working on the same data.
Since both are used by different kind of users, I would design them as different programs (one a site and one an app).
I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.
It's only recently that graphics / audio / video / networking in javascript is almost as good as flash/java was 15 years ago!
Sometimes it's easy to think we're on the cutting edge. But we're really not.
Yeah people did some amazing work on those proprietary platform when they were the only game in town, but it really doesn't hold a candle to what we have today in terms of a fully open and native web tech stack. If you want to be reductionist why not just say we haven't been on the bleeding edge since Lisp was invented and declare everything else derivative tripe.
The "open and native web tech stack" is something that evolved messily over a long period of time in a piecemeal fashion with little overall design vision. It's hardly something to be proud of.
Maybe design snobbery isn't as important as designers think it is.
And yes, the web is definitely something to be proud of.
That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.
Jokes aside, React provides a Virtual DOM which isn't available natively. I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore. Until then, React is the best way forward. There are plenty of thin VDOM libraries (some even more efficient than React) out there but the joy of working with code written as composable Components outweighs efficiency (I'm sure those libraries would fare far worse in benchmarks if composability is put into the equation). Couple this with a library like Om/Reagent and you get FP (code as data)+immutability handed to you on a silver platter.
Without the "right" libraries you introduce a lot of incidental complexity into your application development lifecycle.
ReactJS is the gateway drug to frontend nirvana. For more info:
http://computationallyendowed.com/blog/2014/07/20/reactive-m... (MVC in a Reactive World) http://elm-lang.org (ELM Language) https://github.com/swannodette/om (Om/Clojurescript)
These will be _the_ technologies and approaches in 2015. ReactJS/FluxJS are great, but imperfect implementations!
Though I agree both clojurescript and elm look nice, I'd bet you a lot of money they won't be _the_ technologies in 2015.
[1] https://github.com/omniscientjs/omniscient [2] https://github.com/facebook/immutable-js [3] https://github.com/foss-haas/fynx
React is a framework though, for the most part it calls you(r components), you don't call it outside of the original binding. It's not a huge one, but it's still one.
> I'm sure sometime in the future browser's DOM tree estimation and computation would be so efficient that you wouldn't need a Virtual DOM anymore.
Browsers already batch changes and defer recomputations as much as they can. They can't significantly improve the model because it requires a different abstraction which is not available under the existing DOM.
Also, you can use a VDOM without using React and its component, several VDOM-only pure=js libraries have sprouted up e.g. https://github.com/Matt-Esch/virtual-dom (the basis for elm-html, and the Mercury react-like framework)
I honestly think the framework enforcing architecture idea is more of an anti-pattern, even if you do use a framework you need to keep in mind that it wasn't built directly to fit your needs and that you may want/need to move in 6 months or a year.
I often find myself referring to e.g. Ruby on Rails for architecture decisions, as opposed to trying to roll my own. Architecture is hard.
If it's hard, you learn it so it isn't so scary. You build one to throw it away, as Brooks recommends in The Mythical Man Month.
I want nothing to do with an industry so obsessed with maintaining its own passivity and ignorance of practices. The truth is: a good architecture is highly liberating. It segregates responsibilities, enabling developers to spin up quickly. It makes it easy to spread work among devs of varying skill and experience. It makes maintenance a pleasure or a complete grind.
You have the ability to make working in your code base an enjoyable process of exploring a particular problem domain. But to get there, you need to think deeply about how data flows from inputs to outputs. It's fine to skip these steps via a framework, but you're also trading off how good future maintenance.
There is nothing special about the web that requires frameworks. They're a modern preoccupation, just like OOP was, or components were. In the end, good engineering is what's required, not blind faith in commoditized tooling.
Learn the fundamentals of software design.
I had a case where we had our own internal framework. Its okay. But the team turnover is quite bad to an already tight deadline that I had to re-explain everything every time a new dev comes in. That framework has no routing(its basically for multipage app) and guess what, if someone decide that they need routing, that guy is going to create his own, and there might be two of these guys, so then we have two ways of doing routing then.
And given the fact that this team has high turn over and tight deadline, I don't think you can say that it'd make a cohesive team, and the communication channel that everyone has is already overloaded (loads of meetings).
Sure, that may be a bad project to begin with, but that would be a different story.
In this case, at least for me, using a standard framework would be no brainer.
Great developers know their limits and when it's appropriate to choose third party tools and when to roll their own.
Chances are, if you think it's time to roll your own, you just think you're better than you are.
I said "great developers spend the time to learn what they don't know and design a system that fits their problem". That can very well include pre-existing systems or frameworks.
If the code is built on a custom in-house framework, you are putting the burden on everybody to learn it and understand it and hope they can see it the way that you can. No one will really be as invested as you in understanding the ins and outs of the framework, or the special features you added that they won't even think is available, and won't care to discover or ask about.
With a well known popular framework, not only is it likely to have more documentation available online, there will be more resources from other people blogging about solutions, workarounds, tips and tricks. There will be additional libraries built on top of the framework for common problems. There is the incentive that getting good with the framework can help them in their next project or their next job interview. Lastly, it also reduces the friction of adding new team members.
You are misunderstanding. I and others don't say its hard therefore we will get all our answers from one prophet.
We can look at lots of options (including rolling your own) then make a choice. Once I made a choice for a project its smart to comply with the architecture and principles provided by that choice.
I do the same thing on the web I do everywhere else. I dont write my own gui librarys or databases. I look at databases, evaluate them based on my needs and pick one or more. If I choice SQLDB I will not use it like a key value store, thus the database from now on forces me into a pattern, but that is alright because I have voluntarily made that choice.
If I have other needs I have to evaluate if I would rather bend SQLDB or add another database.
Knowing architecture is required for your choice but its a skill that you should not apply every day. Once you have to make your product happen in that architecture. It does no good to constantly rethink your hole stack.
No, it's not intellectualism, it's pragmatism.
It's important to recognize what you are good at and what others are better at than you are. Just because something is hard doesn't mean you should dedicate time to learn it or you'll be called an anti-intellectual.
I don't fix my car myself nor stitch my dog myself.
Same goes for computer science. It's a very, very wide field and you can't possibly expect everyone to know everything about it. I'm comfortable in my ability to write decent, well architected Javascript (and Haskell, and Scala and Java) but when it comes to creating a Javascript data binding framework that's efficient and follows good conventions, it's just not worth my time to learn how to do it properly versus using a framework written by experts who've spent years thinking about the topic.
The best developers I've ever worked with are the ones who know exactly when not to roll their own implementation.
No, it's "I want to get my job done, get paid and go home".
Believe me, I am anything but anti-intellectual! I love thinking about software and how to make things better. I studied Computer Science and love applying theory to practice. But 90% of the time, the correct answer is "use third party libraries or frameworks", not "roll my own".
In the current project I'm working on, I made the decision to use ReactJS instead of building our own frontend library from scratch. The project is almost ready to ship and has been very successful. New people to the project are saying "React was the right choice."
If I had tried to build our own frontend architecture from scratch we'd never have hit our deadlines.
Rails is also a bit of a special case I think, it was a massive ecosystem that dominated the community it was in. That isn't true of any JS client-side framework right now so choosing one isn't necessarily a sensible investment when you look 3+ so years out.
But all these old monolithic frameworks/libraries, that try to solve everything and there citchen sink, are so 2009-ish.
They have its place in the enterprise world. And for performance optimisation you want a more modular approach.
Personally I'm with you, I enjoy a small, isolated, component based approach where each component follows the unix philosophy. I think this lets you write the most performant and resuable code. Also, I think when following this style, it limits the scope of your dependences, which is another big plus. For instance, you might need a library for crypto, but you won't need one for doing your authentication system, and you won't have massive modules for handling auth that would come from a framework getting compiled into your production code.
But when you go this route you do have to make a lot of "right" decisions that are made for you when using a framework. Also, I think a lot has to do with deadlines and developer speed, it initially takes a little longer to write good standalone components that are reusable, and just grabbing some framework will help get shit done in the short term, but might have the same detriments as technical debt in the long run.
Something like React bothers me far less as it smaller, less imposing, and solves real problems I've seen with other frameworks (for example by pushing clear/consistent/simple communication paths).
Except React is a library. The slogan [1] clearly says "A JavaScript library for building user interfaces".
Frameworks are created because they make solving certain types of problems easier and reduce code duplication, whether you use someone else's or your own.
A framework has control of the application by default and gives control to your code at designated points, to perform some computation and then return control to the framework.
A library takes control of the application when/where your code calls it, performs some computation and then returns control to your code.
A library is a way to reuse code; a framework is a way to reuse application structure/design and control flow.
The pain points of frameworks are well known at this point, I guess the question is given a really good set of high-level libraries, could you be as productive as you are using a framework? Maybe not at first, because you have more design choices to make. But later, you have less of other people's design choices restricting you.
Besides that there are 4 things listed there, not to mention how each interacts with the other, this is not a problem. If you shy at learning an additional thing, you should get out now.
That's not to say you shouldn't strive to reduce complexity and dependencies, that's a laudable and useful goal. But it's my personal opinion that every programmer out there should know at least a handful of languages, concepts, paradigms or frameworks that they don't like or have no use for--it's the same basis of learning more from failure than success.
That being said, I sincerely disagree with the assertion of the article, if on nothing more than the abstraction argument. The abstractions of jQuery have saved me so much time over the years with systems that work great in the latest and greatest browser, and work well enough, possibly with minor tweaks, in older browsers. Rewriting browser detection junk and making sure each control mostly works independent of browser and engine would be a much larger waste of my time than learning three or four js frameworks.
As opposed to the non-framework case, where you have HTML+CSS+JS, N libraries, and all your custom glue code... Yup, that's WAY easier.
Don't forget he was part of the REST/ROA group who were belittled when they said that Web standards were an alternative to the ridiculous number of Web Service standards and he was quite right in that case.
Solutions exist outside the scope of JS framework. We only need to take a minute to analyze them. It's not a popular decision to avoid JS frameworks but I believe some criticism of the current solutions available is in order.
Which is (mostly) monolithic, but rather small. Feels like a simple wrapper.
a) Todays technology is deprecated tomorrow
b) When someone joins I'm the one who'll have to teach them
Starting a project today, I can build a client in Javascript, hook it up to an API, and I'm done. NPM and Browserify make dependency management and builds a breeze. There's very little friction in the development workflow because the front-end build process it totally separate from the server. I make a change, save it, reload the page and I see my changes live without even running a server locally. Even PHP's deployment story isn't that simple.
It's true that the initial setup is more complicated than simply downloading jQuery and plopping it into an existing project, but if you have the option of separating your client and server code, it really simplifies things overall.
Frameworks give us a language to speak to each other about the nuts and bolts of our application. This means new developers can get ramped up quickly (provided they understand the framework) and there is a common body of best practices that can be referenced when faced with difficult problems. There's a lot of value in that.
Most problems are simple, but to solve them in a framework, you have much todo.
And when you understand and use everything "the right way", the new Version of the Framework arrive -> see angualar v2. A new Framework with a new underlying language (WTF?)
Best practices work without frameworks too, you have only to define them and communicate them with your co-coders.
Since requirejs with the modularity and different build tools, i feel no need for a huge framework.
I pick the libraries i need and build parts of the application into modules, since the communication run with events it is clean, structured and has a clear defined API.
How hard a problem is to solve depends completely on the framework. Obviously, the better frameworks make that as easy as possible.
Best practices outside of frameworks absolutely exist of course, but in the context of an application it's left up to you to decide what those are. Rather than spending time deciding this myself, I'd rather lean on people who have spent far longer on that decision than I have time for so I can get back to addressing the actual business problems my application is aiming to solve.
Agreed that is an advantage of frameworks, but is it not more of an argument for a mature framework like Rails, rather than the current JS frameworks which appear and become (essentially)obsolete/niche in a year or two?
These are the core benefits of frameworks:
1. Standard code style.
2. There's only one way to do it (ideally).
3. Modularization.
4. Unit testing.
5. A realistic standard library for async/concurrent computation.
Angular, for instance, provides dependency injection and $scope/$digest. It would be pretty ridiculous to attempt to replicate those benefits until AT THE VERY LEAST Object.observe has solidified in terms of support. And even then, you're on your own in terms of mocking, in terms of communication between different modules, in terms of libraries you can drop in without dragging in a framework itself.
I'm appreciative of the attitude, but it's quite simply not a reality for people who don't want to invest in establishing their own patterns—in effect, writing a framework. With a framework, people can sit down and use the engineering techniques they've learned from other areas of CS and write an application without being bogged down in terms of figuring out how to write a high-performance single-threaded web app in a language without modules, integers, futures (or other similar async abstractions), calendar widgets.
Try going without JQuery for a day and see how much duplicate code you write.
Then, multiply yourself times a team of 10.... good luck.
Polymer is ridiculously slow in my tests.
Yes Polyemer/Dart is still not very fast due to:
a) polyfills
b) not having DartVM in Chrome
but things will get better and if you have project you plan to live more than 12 months and you start now - it's worth a try.
Personally I think there's no substitute for peer review. Code reviews and pair programming are both far more powerful tools.
Here's an interesting and fairly detailed article about a different approach: http://jlongster.com/Removing-User-Interface-Complexity,-or-...
Best of both worlds? https://github.com/PixelsCommander/ReactiveElements
My summary of that text: "I don't know how frameworks work, so let's not use them".
"Reinvent everything from scratch, all the time."
"The fundamental idea is that frameworks aren't needed, use the capabilities already built into HTML+CSS+JS to build your widgets. Break apart the monoliths into orthogonal components that can be mixed in any combination"
Also this is a man with a very rich history in terms of the Web and Web standards so writing him off without giving what he is saying any real attention seems silly.
http://bitworking.org/news/Why_so_many_Python_web_frameworks
(That's a post assembling a light framework from libraries...)
They just didn't go through the list of features and explain that each one doesn't necessarily need to be coupled to the others.
I think that the underlying concern is valid, ie. we would all be better of if we all joined forces and push for web standards, which can be used in any framework. The problem is that the conclusion, ie. we shouldn't use any frameworks to achieve that, is wrong.
Framework authors care about standards and I personally think that each framework will try to adopt more and more native JS and HTML features, but it doesn't mean that we won't be needing frameworks anymore.
I think you're exaggerating : I use Firefox for everything and I wouldn't be able to name a website where I had to use Chrome instead.
Seriously, dude. If you're not doing stuff on the extreme bleeding edge, the same code usually works fine on Chrome, Firefox, Safari, Opera... everywhere but IE. If there are any changes needed, they're trivial. Only IE requires extensive effort to "support correctly".
Microsoft is a $180 billion company with 100,000 employees. I'm just a guy. If they want their browser to be "supported correctly" they should make it work correctly.
I'd say it's need.
> Q: You can’t do ____ in HTML5, for that you need a framework. > A: First, that's not a question. Second, thanks for pointing that out. Now let's work together to add the capabilities to HTML 5 that allows ____ to be done w/o a framework.
Great idea, but what do we do in the meantime? It's not like features get added to HTML 5 overnight.
It takes a long time and iterations for standards to be finalized and adopted. It took more than a decade to for the release of HTML5. In addition, adding more and more features to the standard lead to bloats and even longer release cycles. I think this is the role of frameworks/modules to provide higher abstraction and convenience.
Eventually Front end will get it thing together... the closest thing for bare stuff is like yeoman stack, bower, npm, grunt/glup, etc.. Require.JS doesn't play nicely either. I wish Javascript come out with built module system but it feels like you're just dressing up a pig now.
Maybe people do like coding in Javascript but so far the direction that Javascript is going feels like a mess and added complication. Javascript tries to do backend stuff now and deviate from it's original intended domain. Which is fine but it also make it a mess cause it doesn't have the construct and primitive in mind for backend.
What construct? Modules for one, is not built into javascript. It's ok we fixed it. Now we have several module system. How bout concurrency? What's wrong with passing call back and non block? It's ugly and because it's ugly we're going to patch it up with promise in the next language iteration. It goes on. What's wrong with fixing the language? Nothing, you're just fixing it on a shaky foundation while adding more complexity. You're just a debbie downer. Perhaps, or perhaps I'm spoiled by the elegant of other languages...
People are going to chug away and use it as a hammer imo. But seriously it's a very ugly language to write huge lines of code in for anything more than just small scripts.
Frameworks solve some problems but I'm wary of them now especially Angular and Ember. Smaller framework might be better but I'm sick of front end and the constant search for the thing that will save us from this nightmare of SPA. I'm leaving front end.
The problem with this article is that most of the innovations that browsers are now bundling came from the community, in the form of libraries or frameworks. (document.querySelector, js templating, promises, observables, server push, etc)
Libraries & frameworks are the way new paradigms are explored and improved. They are not the future, but they contain the future.
My concern with frameworks is that they become a crutch. People no longer try to code up their features from scratch. I see this the most in jQuery-heavy developer, where people will go seek out a plugin when they could have coded up the same features themselves had they just stopped, took a step back, and thought about it for a while.
At the end of the day, I support picking a framework, sticking with it long-term, while also recognizing its weaknesses and knowing when to just write native JS.
As for tools to compile and crush the CSS and JS, consider https://developers.google.com/closure/
I wrote javascript before there were frameworks when it was just libraries like mootools and dojo and jQuery sitting on server-side templates. Today I write CORS apps with Backbone.js+Marionette.js+require.js+grunt+qunit and it solves all kinds of problems and I love it! I'd never go back to javascript without frameworks. As soon as this project is over I am gonna try AngularJS to see what the hype is about.
Bot bare-metal js and frameworks are here to stay.
Frameworks are not built to deal with browser inconsistencies. At least that's not the main selling point, unless you're talking about the jQuery only. You mentioned Angular and Ember which provide a lot more.
It wont be just about sticking a few js files together.Js dev will get more complicated as times goes.
AngularJs and co are just the beginning of a trend that will accelerate exponentially in the next 3 years. Be ready for endless variations of Angulars and Reacts.
I'm also not sure the utilities libraries will be copied from project to project, for example if you developed a utility library and were using Ember its quite likely the Ember abstractions would have impacted the library design. If you then move to say React..
Something I've noticed: my coworkers who bitch and rant about this the most love Django. So I don't think the problem is the notion of framework as such. It may just be that things are changing really fast and people get stressed out trying to stay on top of it all.
Frameworks like polymer are nice because they will eventually will fade out. I think that was the idea with TypeScript as well, but I think MS deviated.
What we should encourage are unopinionated but comprehensive libraries that simplify tasks just as the author mentioned.
To illustrate, the (extreme) corollary is one stack and one pool of laborers with one skill-set.
Just another vantage point, whatever we think of the tech merits.
I don't build software for 2 year increments. It took us a year to get our last release out. Telling management their shiny new 2 million dollar investment has to be reworked to Angular 2.0 immediately could be career ending.
The implication in this post is that frameworks are standing still. That browsers have evolved and frameworks are built based on some past version of browsers that no longer exists.
In reality frameworks, browsers, and web standards are coupled together in an important triangle that creates the progress Joe calls out.
Frameworks iterate at an incredible pace compared to standards and browsers. The multitude of frameworks and libraries implementing the component pattern directly influence the spec. Members of W3C TAG and TC39 take the lessons learned from JavaScript development and fold it back into specs.
A great example is promises. This is a standard JS pattern, and now native feature, that began life as a library, became several libraries, then an independent spec, then finally a formal ES6 spec (domenic can correct me if I have the history wrong). When we talk about Move the Web Forward this is what we mean: http://movethewebforward.org/. Frameworks represent the shared and negotiated best practices of a development community- from this we can formalize solutions into specs.
To make a second point: Developing for the web means developing for a spectrum of platforms. A framework like Ember (which I work on) provides you known support for a variety of platforms. I don't need to consider if 5 different libraries all have fixed the ARM optimizations errors on iOS8. I can know all the features in Ember have it fixed. In fact I don't even need to think about the error, most likely.
A third and final point: Of course frameworks don't just influence browser features. The conversation is two-way. Unlike a simple scratch-an-itch library, framework authors are constantly looking foward and thinking about how they can better align with upcoming features. Ember has iterated on its Set, Map, and promise APIs to make them match the specs. Sometimes as we align with a feature we discover unexpected architecture problems with the spec (Object.observe, web components) and push the feedback upstream. Sometimes a spec helps us solidify an un-spec'd solution, and we need to expend effort trying to move apps to that new pattern (ES6 classes).
Most developers who buy into SPA architecture and build complex JavaScript applications understand the value of a framework. They are not panaceas (and setting them up as one is making them a straw man), but they absolutely play a very important part in the JavaScript and web ecosystem.
Which is more than I can say about this post's FUD ("Remember all those MochiKit widgets you wrote? Yeah, how much good are they doing you now that you've migrated to Ember, or Angular?" they work just fine thanks) and call to limit your ambitions for a great client-side app.
If it are frameworks, use frameworks.
If it are libraries, use libraries.
If it is plain JS, write in plain JS.
Wait, what....
For companies that can throw huge resources at their apps (e.g. google) the language deficiencies do not matter as much because they can be dealt with with extra work and testing.
Unless you really mean weakly typed (e.g. "1" + 2 = "12" vs "1" + 2 raises TypeError). In which case I'd say that that's one of JavaScript's (pardon the pun) weaker points.
Disclosure: I like JS. Its weak typing can still be annoying (although you can avoid a lot of it by using strict comparisons).
* Object.observe
* Promises
* HTML Templates
Sorry but IE8 support. Nuff said.
If you replace Polymer with React, you can actually live in a world that's not so dissimilar from what the author is advocating. Of course then you're still using libraries, but arguing against libraries (as opposed to frameworks) is insane.
The only JS frameworks that shouldn't exist are ones cooked up by folks that have little or no theoretical backing in firm comp science. And yeah, AngularJS, I'm talking about you.