The Battle of Modern Javascript Frameworks | Hacker News Reader

The Battle of Modern Javascript Frameworks

softfinity.com

45 pointsLVB17 comments

I hope that nothing will "win" because "front-end" programming is such a nebulous concept that it's much better for each project to find a niche and cater to an increasingly narrower set of trade-offs and use-cases. The idea that we need such a thing as a "framework" is I think mistaken but understandably so: we've only had viable module systems and package management for a short amount of time and they are still evolving.

But module systems and package managers change everything about how open source ecosystems work! When you've got a package manager that is trivially easy to publish to, you remove pressure on libraries upstream to include extra functionality into their cores because users have too hard of a time fetching the functionality for themselves otherwise. With pervasive package management and a culture modularity, modules can be smaller because they can depend on other modules instead of inlining functionality or otherwise being overly cautious about dependencies. Convergence under this kind of fitness landscape tends toward narrowly-focused single-purpose libraries that do just one thing and do it well.

Popular frameworks have already severely dwindled in size from something extjs, mootools, or yui scale towards something backbone-sized. I sincerely hope that frameworks dwindle away into nothingness so that focused, reusable libraries that take simple inputs and produce simple outputs can fill the gap because the severe orthogonality and opportunities for novel recombination are so much greater!

Thank you.. and even then a lot of things get overlooked in frameworks, or even component toolkits. With the web components you need presentation (html + css) along with core event handling (js). Many tools/frameworks forgo some or all of that. There's also being able to inherit the markup and/or styling of components to build larger tools...

With that in mind, I really want to like TJ's component system, but leave a lot wanting in terms of something more encompassing like Bootstrap, which has a consistent CSS/Style for more than a single component.

I appreciate a lot of the tooling around, but even a basic bootstrap site with jQuery + CSS + addons + module scripts for even the menu tends to come in over 200K in size.. and less than 1% of that is the actual content.

-- aside: really dig fleet/seaport, and your github account really makes me wish github offered a sort by forks/followers/stars, I know you modularize everything but it does make it hard to get the bigger from smaller stuff. ;-)

I disagree that they've gotten smaller.

Ember is 47 kb, they say, but you need jquery + handlebars + ember + ember data in practice, for a total of 370 kb minified but not gzipped, which is huge. Or look at backbone, which requires underscore, zepto and json2 (if you care about ie7) for a total of 60 kb, and to really use it at scale you need marionette which bumps the total to 80 kb. Angular clocks in at 80 kb (with json2). None of these frameworks support splitting te payload, so you pay this loading cost at the worst time possible: on the first pageload.

Now. Let's look at the legacy frameworks you mention. Mootools is 100 kb total, which puts it on equal ground with backbone+marionette and angular. Yui core bootstraps in 30 kb and loads in the rest on-demand so you don't feel it as a user. Even the biggest most bloated framework of all, extjs, can bootstrap a first page in 500 kb ungzipped, which is not that much more than ember.

Your page load performance will not be better with the new frameworks than the old. In fact, if you're not careful and load too many 'focused' libraries your initial page load will be worse. What is the value of orthogonality and focus if it does not improve the developer experience or user experience? Bah humbug, get off my lawn ;)

I honestly don't understand the obsession with js package sizes. Of course, the initial page load is important, you want to minify, gzip and make this as fast as possible. But once it is loaded (and cached), that's all there is to it. It's a one-off cost, which I think is perfectly acceptable for most users using a single-page app.

I personally think ease of development, flexibility, documentation and project long-term viability are far greater concerns when choosing a framework, than whether it weights 100kb less (or more).

Agreed, this seems like some kind of strange competition/point of pride between javascript libraries. The smallest slightest advantage in the quality of your application instantly offsets whatever extra time you spent on loading 100k extra javascript.

The only advantage I see is in moving away the ember style. It's ridiculous how frameworks get a free pass from violating single-resposibility by claiming to be "opinionated".

Amen. Preach it, substack.

For what it's worth, Backbone (as it continues to develop), is attempting to be polished down into a small library that provides the basic primitives for binding rich models and views together with events. Nothing more, and hopefully nothing less. Ideally, it shouldn't feel like a "framework", despite frequently being lumped in among them.

To the extent that frameworks start growing framework-specific plugins, instead of generally reusable JS libraries, for simple tasks such as enforcing schemas, validating forms, implementing undo/redo, configuration, serialization, state machines, DOM building, and so on ... is a tragedy. In the same way that the jQuery-plugin-ification craze of several years back is a tragedy, or the only-works-in-Node.js trend might be today.

The thing I love about Backbone is it gives you true freedom of how to think about your application. I think everyone should build at least one rich client web app with Backbone before making any decision about using Angular or Ember or whatever. The reason being that those frameworks are written by very smart people who have chosen particular approaches based on their experience. If you are a bit inexperienced it's easy to be indoctrinated into their worldview and begin to think of it as the one true way when in reality you are just cargo-culting on decisions that are not applicable everywhere.

I suppose one could make the argument about any framework or library at any level of abstraction, but it seems particularly important in the javascript world because the problems just aren't understood all that well yet, and churn is very high.

I think there will be some natural gravity wells that form around JS frameworks/toolkits. We have the incumbents jQueryUI, extjs, etc... along with the upstarts: AngularJS, Knockout, Backbone, even Bootstrap, etc. Each offer specific advantages over others.

Another consideration, which imho is even bigger than toolkits and frameworks will be packaging and distribution... Bower, and even npm are pretty popular... you have CommonJS vs. AMD vs ES6 Modules ... It's an interesting time, with a lot of options, and no clear leaders (other than those with large corporations behind them).

I'm starting to see the likes of Bootstrap and jQueryUI as pretty heavy/bulky.. and re-thinking how/what I really need and want. I have a pretty big addiction to jQuery's features, and not sure if I want to start doing custom builds with fewer features for newer/mobile browsers, and 1.9.x for ieold.

The uptake of mobile browsers (my last job saw mobile expand from 0 to 20% of its' users in the past two years, which is huge), the amount of data used is a big deal, and monolithic toolsets are a burden there.

-----

And for the love of god to anyone reading this... stop specifying "Helvetica" or "Arial" in your stylesheets and just use the "sans-serif" fallback, which is the most similar/appropriate font for the platform 99.999% of the time.

Looks like very biaised towards knockout to me.

Yeah.. the couple projects I've done with Knockout seemed to be very easy to get your JS and html muddled, and even harder to make modular. It was probably the easiest to get started with, but more complex tasks were really complicated. It really seems to be patterned after XAML in a lot of ways. I do like it's observable models though... not sure if the 2-way binding is worth the level of overhead it introduces though.

Backbone is interesting, and I have yet to use it all in a project, I've used bits and pieces in a couple things so can't comment. It does seem to be the most flexible from those I've talked to about it.

AngularJS just seems like a big undertaking, and not sure I'm willing to do it unless I have to.

I think a more interesting compare/contrast would be with regards to project packaging, how to handle modules and even building processes. I know RequireJS/AMD has a big lead here, but is it really worth it over say Browserify, or other patterns. Also as build tools go, is Grunt the best and what other options are there?

I'd love to see how others structure their projects... I tend to have a /client/(less|images|scripts|fonts) set of directories as a source then optimize/merge/push into /pub/(img|js|css|font) directories. I know that Ruby and Python have mature frameworks, but it looks like NodeJS is growing and taking over a lot of these roles, separately from even other server-side frameworks.

My last 3 .Net projects have used Grunt for building client-side tools. I haven't settled on a popular module framework (yet) though... I generally just include the tools I want, and namespace my own code out, which comes out lighter, but less reusable/modular than newer approaches.

Let me recommend Yeoman plus Angular. Yeoman is that extra step above and beyond basic Grunt. Integrates Bower so your common components stay separate, then builds out your stylesheets and JS like they should be for deployment. It's a nice way to develop client-side apps.

Then give Angular a shot. I'm not a JavaScript superstar, but it was pretty easy to pick up Angular and run with it. I love how they've organized directives and services. Really lends itself to building reusable components for your apps. Just wish the docs, particularly around testing, were a bit better.

Weird. I found Knockout to be very easy to be modular. It supports RequireJS and you can have as many view modals as you like.

It's biggest problem is that it still feels like a bit of a hack at times as you have to constantly have to battle between what is a JS object and what is a function.

I wanted to dislike it for that reason alone, but alas, the editing was so terrible, I didn't even get to that.

Javascript, is a legacy technology, with browser folks pushing the envelope into backend and front end solutions.

It should be clear to anybody working with whatever.js that this is not technology that is here to stay.

This is still a browser patch. And everything underneath anything.js is a patch or a port or a hook, or a kludge.

There is no memory management, no threading, no accurate concept of parallelism and no support for anything but what the browser makers want to support.

Javascript is not a real language. It encompasses no real technology. And it will be replaced.

Javascript is the new applet.

Replaced with what? I think you're wrong.

I think zed shaw's talk/rant pretty much says the same thing, perhaps with some more details and insights (as well as more F words)

http://vimeo.com/43380467

I think the gist of it is some kind of an ecosystem with browsers running a form of a Virtual Machine runtime, so people can write different languages that compile to the VM bytecode.

I disagree that Javascript is not a real language. But I do agree that the entire way we build web apps surely can't be sustained. It's incredibly cumbersome to do the simplest things and you are right that parallelism that is intrinsic to responsiveness in desktop/mobile apps is inadequate.

But the real question is what the stack of the future should/will look like.

Reply on news.ycombinator.com