12 ms·

No more JavaScript frameworks

241 points by hit8run 12y ago

pedalpete 12y ago
I have a very different perspective than the author. 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).
- Bahamut 12y ago
  I disagreed with the author as well when I read this - libraries are a hodge podge of piecing stuff together, and when developers are left to their own devices, they often create an unreusable monster. Onboarding new developers also becomes harder due to it taking longer to understand the fundamental structure - there is not too much prior experience that can be drawn on to understand lower level logic.
- colin_jack 12y ago
  You have a point, from my perspective though the difference between a light-weight framework like Backbone and one like Ember is almost as big as the difference between say Backbone and jQuery.
- dmethvin 12y ago
  I think yours is the traditional take on frameworks vs. libraries, so you're not alone. We have a lot of frameworks in JavaScript because we're still expanding and exploring the space where they can work. Eventually I think we'll settle on a smaller number of frameworks, but even so I doubt we'll see the level of consolidation that happened with libraries and jQuery.
- fadzlan 12y ago
  I concur. I remember the days when there was explosion of Java framework last time, though the Java community at the time doesn't seemed to mind (they seemed to like choices) :-). There are some voices that complains of too many choices, but I think people generally agree there can be no One True Stack (TM). 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.
debaserab2 12y ago
It's not just about a framework featureset, frameworks also provide convention and structure. Convention and structure are a problem whether or not you choose to use a framework. 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.
- markuz 12y ago
  I couldn't agree more. I was thinking the same thing while reading it.
- progx 12y ago
  Theoretically you are right, but in practice you spent more time with the framework and how the "best practices" work, as with you application. 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.
  - debaserab2 12y ago
    I see that as a positive. The knowledge you gain working with the framework immediately transfers to the next project using the framework. 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.
ragecore 12y ago
So the author wants to use Javascript more for hacky stuff rather than a proper set of conventions?
- crdoconnor 12y ago
  It is kind of a hacky language. Weakly typed, inconsistent runtimes and all that. Server side code in strongly typed languages is generally more predictable.
  - pswilson14 12y ago
    JavaScript is only unpredictable if written by a poor developer. It's just a language, and it is as powerful as you are. Weakly typed languages are not hacky - merely different.
    - crdoconnor 12y ago
      Weak typing is fine, and even beneficial for small scripts - what javascript was originally meant for. It does not scale though. It leads to large projects becoming unpredictable, unwieldy and mired in technical debt.
      - colin_jack 12y ago
        Yeah the lack of any successful JS rich Web apps proves this point. Wait, what....
        crdoconnor 12y ago
        A poor programming language does not entirely preclude the possibility of a successful app, it just makes it a lot more difficult to release a stable one. 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.
    - pluma 12y ago
dasil003 12y ago
Don't throw the baby out with the bathwater. Sure JS frameworks are often unnecessary, that doesn't mean they aren't solving real problems. 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.
- forrestthewoods 12y ago
  I've been seeing the term "web app" a lot lately. Not exactly sure why. Is a web app different from a website? I guess so probably maybe? I'm not really sure.
  - jfaucett 12y ago
    In my understanding, a webapp is essentially a "desktop-like" application for the browser, i.e. something like gmail or an online paint program, something that is interaction driven, will probably use websockets for giving a realtime feeling, etc. A website is the traditional static content, like a blog or a news site. Obviously, these are just relative and its a scale so there cross-over and sometimes its hard to define in exactly which category an app/site falls.
  - gsands 12y ago
    quite different-- Web app, think Google Docs/Sheets. 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.
    - growse 12y ago
Touche 12y ago
This is completely wrong. The reason frameworks are still popular is Modules. Modules are not solved in the browser and until they are there will continue to be frameworks to ease that problem.
- albertoleal 12y ago
  Except it sorta is. Look at browserify/webpack + npm + etc.
  - taurath 12y ago
    Absolutely. Even if I wasn't using node I'd be using browserify for its modules, its one of the best features of Node and it makes building non-framework apps about as easy. Piecemeal isn't a bad thing if each element is easily replaceable - I tend to prefer specialist libraries which get the feature correct for the project rather than having to do everything the "react/angular/%framework%" way. One size fits all is great when you need to quickly on-board lots of people, but it does reduce your flexibility, and ties you directly to that stack. Things are moving very fast in Web Dev land, and I prefer to not be locked in.
  - Touche 12y ago
    That's not an answer if you are a library author. You can't ship only for browserify users. Which leads to frameworks because to reach everyone (including people who don't use a modular loader at all) you have to have 0 dependencies.
deleted 12y ago
[deleted]
aikah 12y ago
Well,with the release of ES6,the author should expect an EXPLOSION of frameworks,especially class based,IoC driven ones. ES6 brings loads of features to the language,some features will lead to complex codebases (proxies,modules,loaders,realms,quasis...). 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.
bstrom 12y ago
None of the upgrades in ES6/ES7 obviate the need for frameworks. Maybe some libraries are made redundant, but frameworks address more interesting abstractions that a general language probably shouldn't cover anyway. Frameworks seem to adopt more opinions about implementation, and help unite a team over a set of ideas, and enable them to move faster and reason about similar problems in similar ways. Hopefully that team has picked a framework that is also well-suited towards the problem they're solving.
pothibo 12y ago
I agree with you wholeheartedly. I just recently started blogging exclusively on how to build dynamic without javascript framework @ http://pothibo.com http://pothibo.com 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.
bitwize 12y ago
How I wish this were a Scarlet Witch declaration like in the House of M storyline.
Osiris 12y ago
I've found that even if you start with the "basics", like the author describes, that you'll end up finding that you repeat the same types of tasks repeated. So, you refactor and make functions that simplify common actions. After a while, I guarantee you that your code will look a lot like a framework. 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.
- kyllo 12y ago
  Alternatively, it could look like a library. 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.
arenaninja 12y ago
In some ways, browsers are as fragmented as ever. Everyone loves to forget IE, but the last I checked IE8 was #3 in sales in our shop. Throw in a little jQuery and we never have to worry about a lot of things. Polyfills are nice, except that browsers are still experimenting, and plenty of people aren't mindful of that fact and it's not uncommon to visit sites that don't work properly on a browser other than Chrome. A sad state of affairs, but a reality nonetheless
- jmnicolas 12y ago
  > it's not uncommon to visit sites that don't work properly on a browser other than Chrome 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.
  - girvo 12y ago
    And I have a counter datapoint where that's exactly what my girlfriend has to do sometimes, because IE11 isn't supported correctly by some modern sites. However, both of our anecdotes mean diddly-squat in terms of working out whether the parent is exaggerating.
    - Turing_Machine 12y ago
      I wouldn't phrase it as as "not supported correctly" but rather "Microsoft has had 20 years to fix their broken code, and it's still broken". 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.
      - girvo 12y ago
        No, I specifically meant "not supported correctly" -- as in, because of UA sniffing, you're given an old obsolete interface despite IE11 supporting the features that site needs.
duaneb 12y ago
People also said this when HTML5 was on the rise—pure JS, no runtime but the browser! Of course, it turns out engineering DOM-manipulating applications in a responsive way is really hard. 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.
- tkubacki 12y ago
  Looks like Dartlang + Polymer is what you are looking for
  - duaneb 12y ago
    Dartlang isn't directly supported, and I'm not interested in digging through compiled javascript to debug. Yes, there are tools to ameliorate this, but it's not worth the technical debt of a new language with support from only a single vendor. Polymer is ridiculously slow in my tests.
    - tkubacki 12y ago
      I'm deving 10K LOC app in Dart/Polymer not a single time had to debug JS directly (dart2js is very high quality IMO). 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.
deleted 12y ago
[deleted]
dustingetz 12y ago
I strongly disagree. Innovation is good, form some opinions about which ideas are good, become good enough to quickly identify good ideas and quickly dismiss bad or obsolete ideas, and all the problems go away.
barnaby 12y ago
I remember when people used to make these arguments with Java and PHP. "You don't need a framework, just write your JSP templates to have database calls with SQL and tons of Java code". BLEH! I'm glad Struts, then Spring, the Play, came out and made life more sane. 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.
caetan 12y ago
Research, development, ... evolution is an iterative (if not recursive) process. We need to experiment with Backbone to create Angular to create the next framework. Angular 2 is already prognosticated as NOT backward compatible aye?
mpoloton 12y ago
"Now let's work together to add the capabilities to HTML 5 that allows ____ to be done w/o a framework" 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.
- mercer 12y ago
  I also don't see how expanding the capabilities obviates the need for a framework. It might make certain libraries less useful, but I don't see the link between a framework and HTML 5..
cnp 12y ago
Frameworks very much define the way we think about problems. React is a good example, taking from many good ideas before it.
frik 12y ago
Modular small libraries are great, I tend to cherry pick just a few. Specific frameworks like React are great too. 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.
- jfaucett 12y ago
  I think it has to do with the way the developer approaches the problem, their background, and their preferences. 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.
- lukeasrodgers 12y ago
  The only js framework I'm aware of that could accurately be described as trying to solve everything and the kitchen sink is ExtJs, which includes a wide widget library, and is very opinionated about how you interact with the DOM. Ember is is not a "kitchen sink" framework, and Backbone is certainly not.
- colin_jack 12y ago
  Yeah that's my attitude too, Ember scared me away because of the kitchen sink approach and the fact it introduced lots of new abstractions that I hadn't seen proven elsewhere, and that didn't really seem to me to be what I would be expecting from a Web framework. 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).
awjr 12y ago
Within a team, a JS framework is critical to making sure people are writing (and even thinking) in a cohesive way that is maintainable 2 years from now.
- NARKOZ 12y ago
  > that is maintainable 2 years from now 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.
jenscow 12y ago
Frameworks aren't specific to Javascript. Almost every mainstream language I know of has a framework of some sort - If you're using a language on its own then I guarantee you'll end up writing (and testing/maintaining) similar code to everyone else. After a few years, you'll have built up a "utilities library" that you copy from project to project. This will need maintaining, and new starters will also have to learn your library.
- colin_jack 12y ago
  I'm not sure they are immediately comparable, the level of change in the JS side has been massive. 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..
  - dkersten 12y ago
    I read jenscow's comment as "if you don't use a framework, you will build a utilities library which effectively becomes your framework".
FallDead 12y ago
I feel the author does not have enough development experience, or maturity to make such an statement. The reason for such frameworks is to clean up the mess and the void left with years of neglect on the web as a platform. To possibly blossom ideas, on how to improve the web, clearly not many people can agree on standards
- colin_jack 12y ago
  What, this guy you mean: http://www.ietf.org/rfc/rfc5023.txt http://www.ietf.org/rfc/rfc5023.txt
  - FallDead 12y ago
    Alright I take that back and stand corrected haha.
p3drosola 12y ago
I agree with some of the points the author makes. Libraries > Frameworks. Don’t create silos, etc. 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.
Rygu 12y ago
* HTML Imports * Object.observe * Promises * HTML Templates Sorry but IE8 support. Nuff said.
- pluma 12y ago
  FWIW, promises can easily be polyfilled. The rest, not so much. 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.
gsands 12y ago
As a user of Angular, Backbone, and React (not all at the same time!), I feel like their largest benefit to me is in providing application structure -- good because as it has been said, if you aren't using a framework, you are writing your own. I don't really see how any of the 3 items under the article's "So what do we need now?" will provide that benefit.
- davedx 12y ago
  Not just structure, they enforce application architecture, something that you often miss until it's too late if you just get busy gluing together lots of npm modules to build your application.
  - colin_jack 12y ago
    This sort of attitude worries me, you don't need to use a framework to get this, you just need developers who have some knowledge of design/architecture, or who are the sort of people who will do research to find out. 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.
    - davedx 12y ago
      Adopting a well designed, thought through and battle tested architecture is definitely not an anti-pattern. Re-inventing your own is worse. 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.
      - mattgreenrocks 12y ago
        This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it." 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.
forgottenacc56 12y ago
The solution proposed here seems similar to react.js
progx 12y ago
Solution: Use the right tools too get the job done. If it are frameworks, use frameworks. If it are libraries, use libraries. If it is plain JS, write in plain JS.
john1108 12y ago
There is actually a tool[1] that will provide the right subset of polyfills to the specific browser. However, you do need to specify the list of polyfills you use in your code. [1] https://github.com/Financial-Times/polyfill-service https://github.com/Financial-Times/polyfill-service
- Bockit 12y ago
  The default included polyfills tend to cover most things in my experience. I haven't had to worry about if a feature exists in IE8 or if we're polyfillng it for a while now, it's great.
hathym 12y ago
The last sentence "there are standalone libraries for that." seems to contradict the entire article
hit8run 12y ago
It is interesting to see so many different opinions on this topic. In my opinion it really depends on the kind of problem you want to solve. For very simple things it can feel stupid to load in a huge js framework. If one wanted to create something like a blog where a little ajax here and there is nice one might completely skip a framework. But does a developer really want to solve standard problems that have been solved countless times? Big web applications can profit from a framework that enforces some coding standards for common problems.
Mimu 12y ago
Current frameworks are made more and more useless with the evolution of standard, browsers and stuff, however what would most likely happen is new frameworks will emerge and the circle will continue.
davorb 12y ago
I think what the author is describing could be looked at as PHP+MySQL, versus something like Rails. The problem with being in one camp or the other, is that one size will not fit everyone. Bot bare-metal js and frameworks are here to stay.
drogus 12y ago
The author of this article completely ignored all of the features that actually make people use Ember.js. Router, naming conventions, project structure, container to manage objects. It's possible that in the future Ember.js will use plain HTML components and JS features like Object.observe, but it won't mean that suddenly its code will shrink to 1kB, because it's not all there is to the framework. My summary of that text: "I don't know how frameworks work, so let's not use them".
- bipin-nag 12y ago
  He didn't ignore frameworks features and he doesn't say don't use them. The title says explicitly "Stop writing Javascript frameworks." Your summary is a bit harsh. He happens to be an experienced engineer at Google.
- lordbusiness 12y ago
  Agreed. The author's argument can be applied to anything from Perl's CPAN to IKEA's furniture to even the very concept of replaceable parts. "Reinvent everything from scratch, all the time."
  - colin_jack 12y ago
    Well no not really, he says: "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.
- deleted 12y ago
  [deleted]
- maxerickson 12y ago
  No, they get it: http://bitworking.org/news/Why_so_many_Python_web_frameworks 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.
bipin-nag 12y ago
I have been also feeling the same way. With HTML imports, templates, Object.observe and promises webdevs have enough tools to do away with frameworks. Early frameworks solved two fundamental problems according to me: firstly provide a design pattern (each framework has its own approach) to solve a problem and second faster development without getting into nitty gritty JS/browser quirks and other details. But with newer standards and a more aware generation of coders, the usefulness of frameworks needs to be questioned.
digitalzombie 12y ago
It's a complete mess right now. 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.
- woah 12y ago
  That's just, like, your opinion man. Clearly it's not the language for you, which is ok. I will agree that it's a mess on the front end right now, but you've got to admit that it's the only widespread frontend technology that does not require heavy tooling. I think as react and the like come of age, it will become much easier to use than bloated oop native dev, and people will have a very different opinion of it. As for the backend, it's probably better there than on the frontend. You've just got to buckle down and use callbacks.
fiatjaf 12y ago
Recommended read: http://futurice.com/blog/reactive-mvc-and-the-virtual-dom http://futurice.com/blog/reactive-mvc-and-the-virtual-dom
fiatjaf 12y ago
A framework that is much like a non-framework: https://github.com/raynos/mercury https://github.com/raynos/mercury (virtual-dom, selective rerenders, faster than light, truly modular)
- k__ 12y ago
  Yes, or http://lhorie.github.io/mithril http://lhorie.github.io/mithril Which is (mostly) monolithic, but rather small. Feels like a simple wrapper.
rapind 12y ago
This post is just pushing web components / polymer with a controversial title right? I don't think it's production ready yet though (slow polyfills), and there's some differing opinions on how web components should be built. Here's an interesting and fairly detailed article about a different approach: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Best of both worlds? https://github.com/PixelsCommander/ReactiveElements https://github.com/PixelsCommander/ReactiveElements
kuni-toko-tachi 12y ago
The combination of technologies the author suggests we settle on is absurd. Look at the Elm language or On in Clojurescript for JS frameworks with solid computer science behind them. 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.
Siecje 12y ago
Frameworks and libraries let you try different ways of doing things, if they work out they make it into the browser, like document.querySelector()
arcosdev 12y ago
JavaScript, among all the languages out there, is the most ripe for "abuse". It can be used in so many ways, I don't know how you don't use a framework.
shripadk 12y ago
"React isn't a framework, it's a library!" There I said it! 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.
- Touche 12y ago
  "React isn't a framework" but nevertheless includes it's own implementation of classes.
  - kuni-toko-tachi 12y ago
    I'm a huge fan of ReactJS, however it isn't a perfect or optimal implementation of it's concepts. Having a purely functional frontend, with immutability is key. ReactJS is leaky in it's mix of imperative and declarative code. FluxJS also suffers from this same issue. ReactJS is the gateway drug to frontend nirvana. For more info: http://computationallyendowed.com/blog/2014/07/20/reactive-mvc.html http://computationallyendowed.com/blog/2014/07/20/reactive-m... (MVC in a Reactive World) http://elm-lang.org http://elm-lang.org (ELM Language) https://github.com/swannodette/om https://github.com/swannodette/om (Om/Clojurescript) These will be _the_ technologies and approaches in 2015. ReactJS/FluxJS are great, but imperfect implementations!
    - nwienert 12y ago
      But you can also get om in javascript with something like omniscient[1]/immutable[2], or fynx[3] for flux with immutable. 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 https://github.com/omniscientjs/omniscient [2] https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js [3] https://github.com/foss-haas/fynx https://github.com/foss-haas/fynx
al2o3cr 12y ago
"The problem is that now you have two systems to learn, HTML+CSS+JS, and the framework." 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.
- colin_jack 12y ago
  I see his argument about being primarily about the future, that as the standards fill in the gaps investing in libraries will become less of an attraction. 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.
glifchits 12y ago
I think the speed of development gained now by leveraging all the good stuff that frameworks offer in the 10% tip of the iceberg is hugely beneficial in the short term. In the long term, thanks to initial productivity, teams will get more resources to invest into rewriting code for new frameworks or even rolling their own JS "paradigm" (be it a framework, lib, or nothing)
emsy 12y ago
It's not only the frameworks. Working with JavaScript has become ridiculously complicated. I remember when I started developing JSF applications. You had to learn about application servers, servlets, Spring, MySql, Maven, Hibernate JSF, JSP and the various JSF extensions before you could even start working. JavaScript now has become almost the same with Bower, NPM, Angular MongoDB Grunt, Compass, Jade and whatnot. Nowadays, when I start a project I try to keep it as simple as possible because a) Todays technology is deprecated tomorrow b) When someone joins I'm the one who'll have to teach them
- Bargs 12y ago
  The number of tools has increased, but I think JS development has actually been simplified in some cases. This is largely due to the rise in popularity of rich clients talking to simple backend APIs. In older web projects JS always felt like an afterthought. Dependencies were managed totally by hand and your scripts were scattered throughout the backend templates. If you needed to do anything at all with your front-end code at build time, you had no choice but to glue some hacky solution onto the existing build process. Client and server were all mixed together, and it was painful. 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.
zak_mc_kracken 12y ago
> So why are we still writing JS frameworks? I think a large part of it is inertia, it's habit. 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.
codingdave 12y ago
I do think that frameworks come out too fast, and too often. But I disagree that we should move past them. They do make coding easier and faster. The real efficiency comes not from using a framework for one project, though. It comes from using one framework for many years, until you are coding features almost as fast as you can think of them. 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.
davvolun 12y ago
> The problem is that now you have two systems to learn, HTML+CSS+JS, and the framework 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.
pooky666 12y ago
jQuery is a library; not a framework.
vhpoet 12y ago
Unless you're coding a hello-world app, if you aren't using a framework, you are writing your own. If you're working on a 50k+ line frontend app, there's no way you're not gonna come up with a structure, standards, conventions which eventually is gonna become something like the frameworks we already have out there. 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.
encoderer 12y ago
I think one of the biggest problems with the morass of client side code in many large code bases is that it's written, by and large, by engineers who are trained and focused on the shared-nothing world of http server side development. The art of managing state, and the goal of a stateless application is lost on you if you've never had to mentally run a program that runs longer than a few seconds. Yes, there are many fad frameworks. But I totally disagree that the answer is "fewer frameworks, more raw js." I think the answer is building tools to help better manage state (eg React), and over time strengthening the skills of your average "full stack" web engineers from 75% server side 25% client side to a more 50/50 split.
unclebucknasty 12y ago
More JS frameworks (databases, back-end frameworks, languages, caches, messaging systems, etc.) equals more specialization, "job security", higher wages, etc. 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.
mixonic 12y ago
This is so, so off base. 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/ 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.
serve_yay 12y ago
I certainly sympathize, but I'm not going to use Angular or some similar pile of goop because people don't want to think about JS frameworks anymore. 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.
madprops 12y ago
Honestly everytime I see a job posting saying it needs angular or some other similar framework they lose me. I've built some fairly complex applications using nothing more than jquery and handlebars. This level of abstraction leaves room and flexibility to build pretty much anything.
theoutlander 12y ago
I'm glad that I've blatantly ignored all the frameworks that have come and gone over the years. I still know what these frameworks are and their capabilities. 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.
sdotty 12y ago
My thoughts precisely! Down to web components and polymer! Thank you, now I have to something to reference when talking to my colleagues. Well I didn't consider HTML-imports, x-tag, Bosonic, but thank you for that information. The author could also have mentioned the last round of crazy javascript framework flowering ... about 2005-2006 ... Prototype, YUI, Sarissa (the most basic one), Dojo, Mootools, Scriptalicious, jQuery... jQuery seemed to have won that round and for a few years most people seemed to be using jQuery. Until AngularJs, Backbone, React and Ember came along :) As for tools to compile and crush the CSS and JS, consider https://developers.google.com/closure/ https://developers.google.com/closure/

241 points by hit8run 12y ago

I have a very different perspective than the author. 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).

Bahamut 12y ago
I disagreed with the author as well when I read this - libraries are a hodge podge of piecing stuff together, and when developers are left to their own devices, they often create an unreusable monster. Onboarding new developers also becomes harder due to it taking longer to understand the fundamental structure - there is not too much prior experience that can be drawn on to understand lower level logic.
colin_jack 12y ago
You have a point, from my perspective though the difference between a light-weight framework like Backbone and one like Ember is almost as big as the difference between say Backbone and jQuery.
dmethvin 12y ago
I think yours is the traditional take on frameworks vs. libraries, so you're not alone. We have a lot of frameworks in JavaScript because we're still expanding and exploring the space where they can work. Eventually I think we'll settle on a smaller number of frameworks, but even so I doubt we'll see the level of consolidation that happened with libraries and jQuery.
fadzlan 12y ago
I concur. I remember the days when there was explosion of Java framework last time, though the Java community at the time doesn't seemed to mind (they seemed to like choices) :-). There are some voices that complains of too many choices, but I think people generally agree there can be no One True Stack (TM). 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.

debaserab2 12y ago

It's not just about a framework featureset, frameworks also provide convention and structure. Convention and structure are a problem whether or not you choose to use a framework. 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.

markuz 12y ago
I couldn't agree more. I was thinking the same thing while reading it.
progx 12y ago
Theoretically you are right, but in practice you spent more time with the framework and how the "best practices" work, as with you application. 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.
- debaserab2 12y ago
  I see that as a positive. The knowledge you gain working with the framework immediately transfers to the next project using the framework. 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.

ragecore 12y ago

So the author wants to use Javascript more for hacky stuff rather than a proper set of conventions?

crdoconnor 12y ago
It is kind of a hacky language. Weakly typed, inconsistent runtimes and all that. Server side code in strongly typed languages is generally more predictable.
- pswilson14 12y ago
  JavaScript is only unpredictable if written by a poor developer. It's just a language, and it is as powerful as you are. Weakly typed languages are not hacky - merely different.
  - crdoconnor 12y ago
    Weak typing is fine, and even beneficial for small scripts - what javascript was originally meant for. It does not scale though. It leads to large projects becoming unpredictable, unwieldy and mired in technical debt.
    - colin_jack 12y ago
      Yeah the lack of any successful JS rich Web apps proves this point. Wait, what....
      - crdoconnor 12y ago
        A poor programming language does not entirely preclude the possibility of a successful app, it just makes it a lot more difficult to release a stable one. 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.
  - pluma 12y ago

dasil003 12y ago

Don't throw the baby out with the bathwater. Sure JS frameworks are often unnecessary, that doesn't mean they aren't solving real problems. 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.

forrestthewoods 12y ago
I've been seeing the term "web app" a lot lately. Not exactly sure why. Is a web app different from a website? I guess so probably maybe? I'm not really sure.
- jfaucett 12y ago
  In my understanding, a webapp is essentially a "desktop-like" application for the browser, i.e. something like gmail or an online paint program, something that is interaction driven, will probably use websockets for giving a realtime feeling, etc. A website is the traditional static content, like a blog or a news site. Obviously, these are just relative and its a scale so there cross-over and sometimes its hard to define in exactly which category an app/site falls.
- gsands 12y ago
  quite different-- Web app, think Google Docs/Sheets. 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.
  - growse 12y ago

Touche 12y ago

This is completely wrong. The reason frameworks are still popular is Modules. Modules are not solved in the browser and until they are there will continue to be frameworks to ease that problem.

albertoleal 12y ago
Except it sorta is. Look at browserify/webpack + npm + etc.
- taurath 12y ago
  Absolutely. Even if I wasn't using node I'd be using browserify for its modules, its one of the best features of Node and it makes building non-framework apps about as easy. Piecemeal isn't a bad thing if each element is easily replaceable - I tend to prefer specialist libraries which get the feature correct for the project rather than having to do everything the "react/angular/%framework%" way. One size fits all is great when you need to quickly on-board lots of people, but it does reduce your flexibility, and ties you directly to that stack. Things are moving very fast in Web Dev land, and I prefer to not be locked in.
- Touche 12y ago
  That's not an answer if you are a library author. You can't ship only for browserify users. Which leads to frameworks because to reach everyone (including people who don't use a modular loader at all) you have to have 0 dependencies.

deleted 12y ago

[deleted]

aikah 12y ago

Well,with the release of ES6,the author should expect an EXPLOSION of frameworks,especially class based,IoC driven ones. ES6 brings loads of features to the language,some features will lead to complex codebases (proxies,modules,loaders,realms,quasis...). 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.

bstrom 12y ago

None of the upgrades in ES6/ES7 obviate the need for frameworks. Maybe some libraries are made redundant, but frameworks address more interesting abstractions that a general language probably shouldn't cover anyway. Frameworks seem to adopt more opinions about implementation, and help unite a team over a set of ideas, and enable them to move faster and reason about similar problems in similar ways. Hopefully that team has picked a framework that is also well-suited towards the problem they're solving.

pothibo 12y ago

I agree with you wholeheartedly. I just recently started blogging exclusively on how to build dynamic without javascript framework @ http://pothibo.com http://pothibo.com 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.

bitwize 12y ago

How I wish this were a Scarlet Witch declaration like in the House of M storyline.

Osiris 12y ago

I've found that even if you start with the "basics", like the author describes, that you'll end up finding that you repeat the same types of tasks repeated. So, you refactor and make functions that simplify common actions. After a while, I guarantee you that your code will look a lot like a framework. 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.

kyllo 12y ago
Alternatively, it could look like a library. 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.

arenaninja 12y ago

In some ways, browsers are as fragmented as ever. Everyone loves to forget IE, but the last I checked IE8 was #3 in sales in our shop. Throw in a little jQuery and we never have to worry about a lot of things. Polyfills are nice, except that browsers are still experimenting, and plenty of people aren't mindful of that fact and it's not uncommon to visit sites that don't work properly on a browser other than Chrome. A sad state of affairs, but a reality nonetheless

jmnicolas 12y ago
> it's not uncommon to visit sites that don't work properly on a browser other than Chrome 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.
- girvo 12y ago
  And I have a counter datapoint where that's exactly what my girlfriend has to do sometimes, because IE11 isn't supported correctly by some modern sites. However, both of our anecdotes mean diddly-squat in terms of working out whether the parent is exaggerating.
  - Turing_Machine 12y ago
    I wouldn't phrase it as as "not supported correctly" but rather "Microsoft has had 20 years to fix their broken code, and it's still broken". 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.
    - girvo 12y ago
      No, I specifically meant "not supported correctly" -- as in, because of UA sniffing, you're given an old obsolete interface despite IE11 supporting the features that site needs.

duaneb 12y ago

People also said this when HTML5 was on the rise—pure JS, no runtime but the browser! Of course, it turns out engineering DOM-manipulating applications in a responsive way is really hard. 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.

tkubacki 12y ago
Looks like Dartlang + Polymer is what you are looking for
- duaneb 12y ago
  Dartlang isn't directly supported, and I'm not interested in digging through compiled javascript to debug. Yes, there are tools to ameliorate this, but it's not worth the technical debt of a new language with support from only a single vendor. Polymer is ridiculously slow in my tests.
  - tkubacki 12y ago
    I'm deving 10K LOC app in Dart/Polymer not a single time had to debug JS directly (dart2js is very high quality IMO). 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.

deleted 12y ago

[deleted]

dustingetz 12y ago

I strongly disagree. Innovation is good, form some opinions about which ideas are good, become good enough to quickly identify good ideas and quickly dismiss bad or obsolete ideas, and all the problems go away.

barnaby 12y ago

I remember when people used to make these arguments with Java and PHP. "You don't need a framework, just write your JSP templates to have database calls with SQL and tons of Java code". BLEH! I'm glad Struts, then Spring, the Play, came out and made life more sane. 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.

caetan 12y ago

Research, development, ... evolution is an iterative (if not recursive) process. We need to experiment with Backbone to create Angular to create the next framework. Angular 2 is already prognosticated as NOT backward compatible aye?

mpoloton 12y ago

"Now let's work together to add the capabilities to HTML 5 that allows ____ to be done w/o a framework" 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.

mercer 12y ago
I also don't see how expanding the capabilities obviates the need for a framework. It might make certain libraries less useful, but I don't see the link between a framework and HTML 5..

cnp 12y ago

Frameworks very much define the way we think about problems. React is a good example, taking from many good ideas before it.

frik 12y ago

Modular small libraries are great, I tend to cherry pick just a few. Specific frameworks like React are great too. 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.

jfaucett 12y ago
I think it has to do with the way the developer approaches the problem, their background, and their preferences. 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.
lukeasrodgers 12y ago
The only js framework I'm aware of that could accurately be described as trying to solve everything and the kitchen sink is ExtJs, which includes a wide widget library, and is very opinionated about how you interact with the DOM. Ember is is not a "kitchen sink" framework, and Backbone is certainly not.
colin_jack 12y ago
Yeah that's my attitude too, Ember scared me away because of the kitchen sink approach and the fact it introduced lots of new abstractions that I hadn't seen proven elsewhere, and that didn't really seem to me to be what I would be expecting from a Web framework. 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).

awjr 12y ago

Within a team, a JS framework is critical to making sure people are writing (and even thinking) in a cohesive way that is maintainable 2 years from now.

NARKOZ 12y ago
> that is maintainable 2 years from now 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.

jenscow 12y ago

Frameworks aren't specific to Javascript. Almost every mainstream language I know of has a framework of some sort - If you're using a language on its own then I guarantee you'll end up writing (and testing/maintaining) similar code to everyone else. After a few years, you'll have built up a "utilities library" that you copy from project to project. This will need maintaining, and new starters will also have to learn your library.

colin_jack 12y ago
I'm not sure they are immediately comparable, the level of change in the JS side has been massive. 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..
- dkersten 12y ago
  I read jenscow's comment as "if you don't use a framework, you will build a utilities library which effectively becomes your framework".

FallDead 12y ago

I feel the author does not have enough development experience, or maturity to make such an statement. The reason for such frameworks is to clean up the mess and the void left with years of neglect on the web as a platform. To possibly blossom ideas, on how to improve the web, clearly not many people can agree on standards

colin_jack 12y ago
What, this guy you mean: http://www.ietf.org/rfc/rfc5023.txt http://www.ietf.org/rfc/rfc5023.txt
- FallDead 12y ago
  Alright I take that back and stand corrected haha.

p3drosola 12y ago

I agree with some of the points the author makes. Libraries > Frameworks. Don’t create silos, etc. 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.

Rygu 12y ago

* HTML Imports * Object.observe * Promises * HTML Templates Sorry but IE8 support. Nuff said.

pluma 12y ago
FWIW, promises can easily be polyfilled. The rest, not so much. 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.

gsands 12y ago

As a user of Angular, Backbone, and React (not all at the same time!), I feel like their largest benefit to me is in providing application structure -- good because as it has been said, if you aren't using a framework, you are writing your own. I don't really see how any of the 3 items under the article's "So what do we need now?" will provide that benefit.

davedx 12y ago
Not just structure, they enforce application architecture, something that you often miss until it's too late if you just get busy gluing together lots of npm modules to build your application.
- colin_jack 12y ago
  This sort of attitude worries me, you don't need to use a framework to get this, you just need developers who have some knowledge of design/architecture, or who are the sort of people who will do research to find out. 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.
  - davedx 12y ago
    Adopting a well designed, thought through and battle tested architecture is definitely not an anti-pattern. Re-inventing your own is worse. 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.
    - mattgreenrocks 12y ago
      This is anti-intellectualism: "architecture is hard, so let the smart people at Google handle it." 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.

forgottenacc56 12y ago

The solution proposed here seems similar to react.js

progx 12y ago

Solution: Use the right tools too get the job done. If it are frameworks, use frameworks. If it are libraries, use libraries. If it is plain JS, write in plain JS.

john1108 12y ago

There is actually a tool[1] that will provide the right subset of polyfills to the specific browser. However, you do need to specify the list of polyfills you use in your code. [1] https://github.com/Financial-Times/polyfill-service https://github.com/Financial-Times/polyfill-service

Bockit 12y ago
The default included polyfills tend to cover most things in my experience. I haven't had to worry about if a feature exists in IE8 or if we're polyfillng it for a while now, it's great.

hathym 12y ago

The last sentence "there are standalone libraries for that." seems to contradict the entire article

hit8run 12y ago

It is interesting to see so many different opinions on this topic. In my opinion it really depends on the kind of problem you want to solve. For very simple things it can feel stupid to load in a huge js framework. If one wanted to create something like a blog where a little ajax here and there is nice one might completely skip a framework. But does a developer really want to solve standard problems that have been solved countless times? Big web applications can profit from a framework that enforces some coding standards for common problems.

Mimu 12y ago

Current frameworks are made more and more useless with the evolution of standard, browsers and stuff, however what would most likely happen is new frameworks will emerge and the circle will continue.

davorb 12y ago

I think what the author is describing could be looked at as PHP+MySQL, versus something like Rails. The problem with being in one camp or the other, is that one size will not fit everyone. Bot bare-metal js and frameworks are here to stay.

drogus 12y ago

The author of this article completely ignored all of the features that actually make people use Ember.js. Router, naming conventions, project structure, container to manage objects. It's possible that in the future Ember.js will use plain HTML components and JS features like Object.observe, but it won't mean that suddenly its code will shrink to 1kB, because it's not all there is to the framework. My summary of that text: "I don't know how frameworks work, so let's not use them".

bipin-nag 12y ago
He didn't ignore frameworks features and he doesn't say don't use them. The title says explicitly "Stop writing Javascript frameworks." Your summary is a bit harsh. He happens to be an experienced engineer at Google.
lordbusiness 12y ago
Agreed. The author's argument can be applied to anything from Perl's CPAN to IKEA's furniture to even the very concept of replaceable parts. "Reinvent everything from scratch, all the time."
- colin_jack 12y ago
  Well no not really, he says: "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.
deleted 12y ago
[deleted]
maxerickson 12y ago
No, they get it: http://bitworking.org/news/Why_so_many_Python_web_frameworks 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.

bipin-nag 12y ago

I have been also feeling the same way. With HTML imports, templates, Object.observe and promises webdevs have enough tools to do away with frameworks. Early frameworks solved two fundamental problems according to me: firstly provide a design pattern (each framework has its own approach) to solve a problem and second faster development without getting into nitty gritty JS/browser quirks and other details. But with newer standards and a more aware generation of coders, the usefulness of frameworks needs to be questioned.

digitalzombie 12y ago

It's a complete mess right now. 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.

woah 12y ago
That's just, like, your opinion man. Clearly it's not the language for you, which is ok. I will agree that it's a mess on the front end right now, but you've got to admit that it's the only widespread frontend technology that does not require heavy tooling. I think as react and the like come of age, it will become much easier to use than bloated oop native dev, and people will have a very different opinion of it. As for the backend, it's probably better there than on the frontend. You've just got to buckle down and use callbacks.

fiatjaf 12y ago

Recommended read: http://futurice.com/blog/reactive-mvc-and-the-virtual-dom http://futurice.com/blog/reactive-mvc-and-the-virtual-dom

fiatjaf 12y ago

A framework that is much like a non-framework: https://github.com/raynos/mercury https://github.com/raynos/mercury (virtual-dom, selective rerenders, faster than light, truly modular)

k__ 12y ago
Yes, or http://lhorie.github.io/mithril http://lhorie.github.io/mithril Which is (mostly) monolithic, but rather small. Feels like a simple wrapper.

rapind 12y ago

This post is just pushing web components / polymer with a controversial title right? I don't think it's production ready yet though (slow polyfills), and there's some differing opinions on how web components should be built. Here's an interesting and fairly detailed article about a different approach: http://jlongster.com/Removing-User-Interface-Complexity,-or-Why-React-is-Awesome http://jlongster.com/Removing-User-Interface-Complexity,-or-... Best of both worlds? https://github.com/PixelsCommander/ReactiveElements https://github.com/PixelsCommander/ReactiveElements

kuni-toko-tachi 12y ago

The combination of technologies the author suggests we settle on is absurd. Look at the Elm language or On in Clojurescript for JS frameworks with solid computer science behind them. 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.

Siecje 12y ago

Frameworks and libraries let you try different ways of doing things, if they work out they make it into the browser, like document.querySelector()

arcosdev 12y ago

JavaScript, among all the languages out there, is the most ripe for "abuse". It can be used in so many ways, I don't know how you don't use a framework.

shripadk 12y ago

"React isn't a framework, it's a library!" There I said it! 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.

Touche 12y ago
"React isn't a framework" but nevertheless includes it's own implementation of classes.
- kuni-toko-tachi 12y ago
  I'm a huge fan of ReactJS, however it isn't a perfect or optimal implementation of it's concepts. Having a purely functional frontend, with immutability is key. ReactJS is leaky in it's mix of imperative and declarative code. FluxJS also suffers from this same issue. ReactJS is the gateway drug to frontend nirvana. For more info: http://computationallyendowed.com/blog/2014/07/20/reactive-mvc.html http://computationallyendowed.com/blog/2014/07/20/reactive-m... (MVC in a Reactive World) http://elm-lang.org http://elm-lang.org (ELM Language) https://github.com/swannodette/om https://github.com/swannodette/om (Om/Clojurescript) These will be _the_ technologies and approaches in 2015. ReactJS/FluxJS are great, but imperfect implementations!
  - nwienert 12y ago
    But you can also get om in javascript with something like omniscient[1]/immutable[2], or fynx[3] for flux with immutable. 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 https://github.com/omniscientjs/omniscient [2] https://github.com/facebook/immutable-js https://github.com/facebook/immutable-js [3] https://github.com/foss-haas/fynx https://github.com/foss-haas/fynx

al2o3cr 12y ago

"The problem is that now you have two systems to learn, HTML+CSS+JS, and the framework." 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.

colin_jack 12y ago
I see his argument about being primarily about the future, that as the standards fill in the gaps investing in libraries will become less of an attraction. 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.

glifchits 12y ago

I think the speed of development gained now by leveraging all the good stuff that frameworks offer in the 10% tip of the iceberg is hugely beneficial in the short term. In the long term, thanks to initial productivity, teams will get more resources to invest into rewriting code for new frameworks or even rolling their own JS "paradigm" (be it a framework, lib, or nothing)

emsy 12y ago

It's not only the frameworks. Working with JavaScript has become ridiculously complicated. I remember when I started developing JSF applications. You had to learn about application servers, servlets, Spring, MySql, Maven, Hibernate JSF, JSP and the various JSF extensions before you could even start working. JavaScript now has become almost the same with Bower, NPM, Angular MongoDB Grunt, Compass, Jade and whatnot. Nowadays, when I start a project I try to keep it as simple as possible because a) Todays technology is deprecated tomorrow b) When someone joins I'm the one who'll have to teach them

Bargs 12y ago
The number of tools has increased, but I think JS development has actually been simplified in some cases. This is largely due to the rise in popularity of rich clients talking to simple backend APIs. In older web projects JS always felt like an afterthought. Dependencies were managed totally by hand and your scripts were scattered throughout the backend templates. If you needed to do anything at all with your front-end code at build time, you had no choice but to glue some hacky solution onto the existing build process. Client and server were all mixed together, and it was painful. 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.

zak_mc_kracken 12y ago

> So why are we still writing JS frameworks? I think a large part of it is inertia, it's habit. 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.

codingdave 12y ago

I do think that frameworks come out too fast, and too often. But I disagree that we should move past them. They do make coding easier and faster. The real efficiency comes not from using a framework for one project, though. It comes from using one framework for many years, until you are coding features almost as fast as you can think of them. 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.

davvolun 12y ago

> The problem is that now you have two systems to learn, HTML+CSS+JS, and the framework 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.

pooky666 12y ago

jQuery is a library; not a framework.

vhpoet 12y ago

Unless you're coding a hello-world app, if you aren't using a framework, you are writing your own. If you're working on a 50k+ line frontend app, there's no way you're not gonna come up with a structure, standards, conventions which eventually is gonna become something like the frameworks we already have out there. 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.

encoderer 12y ago

I think one of the biggest problems with the morass of client side code in many large code bases is that it's written, by and large, by engineers who are trained and focused on the shared-nothing world of http server side development. The art of managing state, and the goal of a stateless application is lost on you if you've never had to mentally run a program that runs longer than a few seconds. Yes, there are many fad frameworks. But I totally disagree that the answer is "fewer frameworks, more raw js." I think the answer is building tools to help better manage state (eg React), and over time strengthening the skills of your average "full stack" web engineers from 75% server side 25% client side to a more 50/50 split.

unclebucknasty 12y ago

More JS frameworks (databases, back-end frameworks, languages, caches, messaging systems, etc.) equals more specialization, "job security", higher wages, etc. 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.

mixonic 12y ago

This is so, so off base. 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/ 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.

serve_yay 12y ago

I certainly sympathize, but I'm not going to use Angular or some similar pile of goop because people don't want to think about JS frameworks anymore. 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.

madprops 12y ago

Honestly everytime I see a job posting saying it needs angular or some other similar framework they lose me. I've built some fairly complex applications using nothing more than jquery and handlebars. This level of abstraction leaves room and flexibility to build pretty much anything.

theoutlander 12y ago

I'm glad that I've blatantly ignored all the frameworks that have come and gone over the years. I still know what these frameworks are and their capabilities. 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.

sdotty 12y ago

My thoughts precisely! Down to web components and polymer! Thank you, now I have to something to reference when talking to my colleagues. Well I didn't consider HTML-imports, x-tag, Bosonic, but thank you for that information. The author could also have mentioned the last round of crazy javascript framework flowering ... about 2005-2006 ... Prototype, YUI, Sarissa (the most basic one), Dojo, Mootools, Scriptalicious, jQuery... jQuery seemed to have won that round and for a few years most people seemed to be using jQuery. Until AngularJs, Backbone, React and Ember came along :) As for tools to compile and crush the CSS and JS, consider https://developers.google.com/closure/ https://developers.google.com/closure/