5 ms·

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

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!

tracker1 13y ago
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. ;-)
Joeri 13y ago
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 ;)
- gingerlime 13y ago
  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).
  - alipang 13y ago
    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".
jashkenas 13y ago
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.
- dasil003 13y ago
  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.

tracker1 13y ago

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. ;-)

Joeri 13y ago

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 ;)

gingerlime 13y ago
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).
- alipang 13y ago
  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".

jashkenas 13y ago

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.

dasil003 13y ago
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.