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).
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.
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.
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.
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.
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.
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.
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.
"This means new developers can get ramped up quickly"
Agreed that is an advantage of frameworks, but is it not more of an argument for a mature framework like Rails, rather than the current JS frameworks which appear and become (essentially)obsolete/niche in a year or two?
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.
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.
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.
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.
Unless you really mean weakly typed (e.g. "1" + 2 = "12" vs "1" + 2 raises TypeError). In which case I'd say that that's one of JavaScript's (pardon the pun) weaker points.
Disclosure: I like JS. Its weak typing can still be annoying (although you can avoid a lot of it by using strict comparisons).
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.
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.
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.
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.
Given that this distinction is entirely subjective (no-one will be able agree on what a test that pigeonholes pages as a 'site' or 'app'), how is it a useful distinction?
I totally agree web site and web app are used interchangeably sometimes -- I was just answering the op as to how I and many people I know classify them and their differences as they relate to the topic of the article, javascript.
For me a web app is an HTML5 web page, that has its interaction logic coded in JS and presentation is done by altering HTML5 DOM and where JS uses REST to send/receive data.
In other words as someone else noted, it is a sandboxed application with
sandbox execution environment == browser
IO == REST
UI = HTML5 DOM manipulation of the same page
A website (or server app) is a series of HTML5 web apps or HTML5 static pages (JS-less web apps) with navigation logic and inter-app state living in a server app.
Is a "simple website" and a "complex website" a better distinction in your opinion?
Thus I am a complex website engineer. It sounds ridiculous. The webapp developer is domain knowledge wise closer to traditional "application development" than to traditional "website development".
Are sites like vox or gawker considered websites or web apps? Their custom CMS is quite expansive. How bout NYTimes? Is YouTube a web app or a web site? I'd be curious to know some examples on either side. Preferably several closer to the line but on one side or the other rather than far away.
I don't think anyone is trying to partition projects into disjunct sets. It's more of a continuum. I think the idea of "app-iness" just captures the interactivity and statefullness of an experience. Incidentally, that additional complexity is exactly what the Web technologies were initially ill-suited for and what frameworks were built to help manage.
It may not be a useful distinction, but it's useful to have a sense for where on the continuum the thing you're building sits, in order to make technology and architecture decisions. If you're building something more "website-y", it should probably have an architecture that optimizes for search-ability and static caching, whereas if you're building something more "webapp-y", the architecture should probably optimize interactivity and dynamic updates. Most things end up somewhere in the middle, but leaning one way or the other.
> The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago.
I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.
A few examples would come in handy. The only place I can remember using flash and enjoying it was youtube. (And then only because there wasn't a better/standard way of playing videos.)
There were some pretty good multi-user flash games around 1999/2000, when things were just getting going. I can't remember the names though at the moment.
It's only recently that graphics / audio / video / networking in javascript is almost as good as flash/java was 15 years ago!
Sometimes it's easy to think we're on the cutting edge. But we're really not.
I'm sorry but the UX on Flash and Java plugin-based apps was horseshit. They were sluggish and encapsulated clumsily within the plugin sandbox so the integration to the browser was terrible.
Yeah people did some amazing work on those proprietary platform when they were the only game in town, but it really doesn't hold a candle to what we have today in terms of a fully open and native web tech stack. If you want to be reductionist why not just say we haven't been on the bleeding edge since Lisp was invented and declare everything else derivative tripe.
They were faster than browsers were at the time, that's for sure. Especially Flash. At one point no serious design-focussed website worth its salt bothered with HTML because Flash was so much better and easier to author. Heck it's probably still easier to author.
The "open and native web tech stack" is something that evolved messily over a long period of time in a piecemeal fashion with little overall design vision. It's hardly something to be proud of.
There has never been a cross-platform, cross-media, accessible platform like the web in the history of computing or humanity for that matter. It is very much indeed something to be proud of.
And yet the sites that succeeded long-term (Google, Amazon, etc.) didn't use it, while all the sites that consisted of a zillion MB of Flash and Java all went by the wayside.
Maybe design snobbery isn't as important as designers think it is.
And yes, the web is definitely something to be proud of.
Actually, I wrote a pretty complex browser-based app in 2002. It ran on Microsoft Explorer as it was the only capable browser at the time, and it used Javascript, XML and XSLT to construct a Windows-like UI environment within the browser -- you may check the code at https://bitbucket.org/BerislavLopac/waexplorer
There were but probably in-house non public ones. I had a course where the teacher explained how its company was building portable asynchronous desktop-like applications in JS since early 2Ks. Maybe the exception though.
I used the web 10 years ago, along with a lot of those flash and java applets, and I use the web now, along with a lot of these richly interactive javascript applications, and comparing then with now strikes me as truly ridiculous. The web is hugely more usable now.
> Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.
This is also going to vary depending on the domain problem. If you're aiming to make something large and comprehensive, it helps to start "a bit too crude" so that every assumption you make at the start is grounded in the understanding of where you want to go later. But if you're pumping out microsites, a framework automates the process and makes it easier to maintain a large body of them.
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.
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.
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.
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.
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.
I agree with you wholeheartedly. I just recently started blogging exclusively on how to build dynamic without javascript framework @ 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.
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.
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.
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
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.
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.
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.
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.
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.
You missed out on the biggest core benefit of frameworks: battle tested code for a very large chunk of your application without having to re-invent it all from scratch. Frameworks give you a stable foundation to build on.
No, with libraries you have to provide the whole structure and this is exactly where plenty of programmers go horribly wrong. Frameworks abstracting out the structure is actually one of their largest benefits.
Except I've never seen a framework help with this at all. I've lost count of the number of code bases I've had to pull a part that used express, symfony, rails, angular, or whatever. Controllers stuffed with business logic, views modifying models... You can't protect coders from themselves.
You can limit the scope of the damage though, and that is an understated benefit of a framework. Architecting solutions for a team is about risk management in many ways.
I'd say most frameworks don't do this very well. One of the reasons I think React is really promising is that it does it better than most, but ironically it isn't a framework.
Personally I think there's no substitute for peer review. Code reviews and pair programming are both far more powerful tools.
Get you, I think that relying on a framework to teach you that is a problem. Once you've used or researched one or more frameworks in an area you learn the successful patterns (right down to file/folder/test/method naming). At that point the whole enforced structure can be a disadvantage.
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.
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.
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?
"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.
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..
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.
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.
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).
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.
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.
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.
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..
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
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.
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.
167 comments
[ 2.8 ms ] story [ 244 ms ] threadI've considered Libraries to be the pieces of code that let us 'paper over browser inconsistencies' to be things like jQuery. Sure, they also gave us some useful tools and plugins to accomplish tasks, but on the core purpose was to be able to write simple javascript code for common functions and have parity across all the major browsers.
Frameworks, I view at as code organization and paradigm tools. They create a more consistent structure for a group of developers to work on a single project. It aids in creating an MV* or other similar paradigm that a team can work within. Even outside of a team environment, Frameworks give you a ... framework, of how your app should be built, rather than just creating your own structure as you go along.
This is the reason why there are so many frameworks vs. libraries. Once you've chosen a library to handle browser inconsistency, as the author mentioned, barely an issue anymore, there is an endless possibility as to how your app should be structured. Some people like two-way data binding, some don't. Some people need extreme DOM performance of leveraging the virtual DOM, others hate the idea of having their html closely bound to their javascript (and framework as often the case).
As for preferring library over frameworks, sure why not. There are tons of reason to be able to do things other than the way that is described by a framework, but when you start to have teams bigger than 20, of different time zones, with varying skill level (important point here), having a prescribed way to do things may not be such a bad thing. There will be time to break the rules of the framework, but hopefully your choice of framework is good enough that it should only be less than 10% of the case.
To this, I can say that despite the failing of AngularJS, some teams just cannot live without it. Its very prescriptive to the point that people who a very good at Javascript may find it repulsive. But those prescription are just too robust for some team to abandon it and go for a more performant framework.
And there is a lot of companies that can't hire Google level developers. These people may not know Javascript enough, but are okay as long as there are good prescriptive example of how to do things. They should still aspire to be good at Javascript (or any language at that...), but sometimes that seems to be too much to expect for the portion of them. Sure, this is not ideal, but you have to remember, there are a lot of places in the world that IT is a cost center.
Frameworks give us a language to speak to each other about the nuts and bolts of our application. This means new developers can get ramped up quickly (provided they understand the framework) and there is a common body of best practices that can be referenced when faced with difficult problems. There's a lot of value in that.
Most problems are simple, but to solve them in a framework, you have much todo.
And when you understand and use everything "the right way", the new Version of the Framework arrive -> see angualar v2. A new Framework with a new underlying language (WTF?)
Best practices work without frameworks too, you have only to define them and communicate them with your co-coders.
Since requirejs with the modularity and different build tools, i feel no need for a huge framework.
I pick the libraries i need and build parts of the application into modules, since the communication run with events it is clean, structured and has a clear defined API.
How hard a problem is to solve depends completely on the framework. Obviously, the better frameworks make that as easy as possible.
Best practices outside of frameworks absolutely exist of course, but in the context of an application it's left up to you to decide what those are. Rather than spending time deciding this myself, I'd rather lean on people who have spent far longer on that decision than I have time for so I can get back to addressing the actual business problems my application is aiming to solve.
Agreed that is an advantage of frameworks, but is it not more of an argument for a mature framework like Rails, rather than the current JS frameworks which appear and become (essentially)obsolete/niche in a year or two?
Wait, what....
For companies that can throw huge resources at their apps (e.g. google) the language deficiencies do not matter as much because they can be dealt with with extra work and testing.
Unless you really mean weakly typed (e.g. "1" + 2 = "12" vs "1" + 2 raises TypeError). In which case I'd say that that's one of JavaScript's (pardon the pun) weaker points.
Disclosure: I like JS. Its weak typing can still be annoying (although you can avoid a lot of it by using strict comparisons).
The scope of applications and interactivity found in today's browser-based apps today dwarfs what we were doing even 10 years ago. The amount of experience and expertise that is being codified in (for example) Ember.js is fantastic and will allow you write much richer web apps in far less code than trying to achieve the same functionality with it.
Saying just use JS directly is sort of like saying don't bother with Rails, CGI.pm has everything you could ever need.
Web site, think blog, information landing page, or even web store product page(s).
Web app is highly interactive (may or may not be an SPA single page app), relying heavily on javascript for UI events, saving/fetching application state, remote datasets, and sometimes making use of modern HTML5 browser features.
Web site is displaying information and is just augmented with some javascript mostly for improving the UX or attaching analytics/social plugins etc.
In other words as someone else noted, it is a sandboxed application with
sandbox execution environment == browser IO == REST UI = HTML5 DOM manipulation of the same page
A website (or server app) is a series of HTML5 web apps or HTML5 static pages (JS-less web apps) with navigation logic and inter-app state living in a server app.
Thus I am a complex website engineer. It sounds ridiculous. The webapp developer is domain knowledge wise closer to traditional "application development" than to traditional "website development".
Web App are application like website.
So instead of traditional application/program such as Quicken we got Mint.com now. It makes application OS agnostic now too.
Web sites are bunch of pages that are hot link or connected via URL. Think of the old days of geocities, xoom, tripod, etc..
web sites are content centric and made for consuming it.
web apps are interaction centric and made to "do" something.
Note that this definition means that certain pieces of software could be considered either "sites" or "apps", depending on how they're being used.
For instance, blog software like Wordpress would be a "site" for the readers, but an "app" for the person who writes the posts.
One part is an editing software/gui and one part is a reading software/gui. Both working on the same data.
Since both are used by different kind of users, I would design them as different programs (one a site and one an app).
I'd dispute that. 10 years ago we had pretty brilliant browser based apps. They just happened to be using flash or Java applets whereas now they're using javascript.
It's only recently that graphics / audio / video / networking in javascript is almost as good as flash/java was 15 years ago!
Sometimes it's easy to think we're on the cutting edge. But we're really not.
Yeah people did some amazing work on those proprietary platform when they were the only game in town, but it really doesn't hold a candle to what we have today in terms of a fully open and native web tech stack. If you want to be reductionist why not just say we haven't been on the bleeding edge since Lisp was invented and declare everything else derivative tripe.
The "open and native web tech stack" is something that evolved messily over a long period of time in a piecemeal fashion with little overall design vision. It's hardly something to be proud of.
Maybe design snobbery isn't as important as designers think it is.
And yes, the web is definitely something to be proud of.
That pretty much sums up the article's stance on frameworks. Even with reusable components, there will be a need for frameworks because just using JS/CSS/HTML directly, one would essentially be creating a framework with each application. There are standard things that a framework encapsulates in any language or target environment which will be unnecessarily repeated and sub-optimally created if one decided to start from scratch on every application. I think the author misses this part completely. While learning a framework enough to start making things in it may take a day or two, creating a new framework because one hate using frameworks will take days to weeks and still likely leave desiring functionality they had not thought of or had implemented badly.
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.
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.
Frameworks are created because they make solving certain types of problems easier and reduce code duplication, whether you use someone else's or your own.
A framework has control of the application by default and gives control to your code at designated points, to perform some computation and then return control to the framework.
A library takes control of the application when/where your code calls it, performs some computation and then returns control to your code.
A library is a way to reuse code; a framework is a way to reuse application structure/design and control flow.
The pain points of frameworks are well known at this point, I guess the question is given a really good set of high-level libraries, could you be as productive as you are using a framework? Maybe not at first, because you have more design choices to make. But later, you have less of other people's design choices restricting you.
I think you're exaggerating : I use Firefox for everything and I wouldn't be able to name a website where I had to use Chrome instead.
Seriously, dude. If you're not doing stuff on the extreme bleeding edge, the same code usually works fine on Chrome, Firefox, Safari, Opera... everywhere but IE. If there are any changes needed, they're trivial. Only IE requires extensive effort to "support correctly".
Microsoft is a $180 billion company with 100,000 employees. I'm just a guy. If they want their browser to be "supported correctly" they should make it work correctly.
These are the core benefits of frameworks:
1. Standard code style.
2. There's only one way to do it (ideally).
3. Modularization.
4. Unit testing.
5. A realistic standard library for async/concurrent computation.
Angular, for instance, provides dependency injection and $scope/$digest. It would be pretty ridiculous to attempt to replicate those benefits until AT THE VERY LEAST Object.observe has solidified in terms of support. And even then, you're on your own in terms of mocking, in terms of communication between different modules, in terms of libraries you can drop in without dragging in a framework itself.
I'm appreciative of the attitude, but it's quite simply not a reality for people who don't want to invest in establishing their own patterns—in effect, writing a framework. With a framework, people can sit down and use the engineering techniques they've learned from other areas of CS and write an application without being bogged down in terms of figuring out how to write a high-performance single-threaded web app in a language without modules, integers, futures (or other similar async abstractions), calendar widgets.
Try going without JQuery for a day and see how much duplicate code you write.
Then, multiply yourself times a team of 10.... good luck.
Polymer is ridiculously slow in my tests.
Yes Polyemer/Dart is still not very fast due to:
a) polyfills
b) not having DartVM in Chrome
but things will get better and if you have project you plan to live more than 12 months and you start now - it's worth a try.
Personally I think there's no substitute for peer review. Code reviews and pair programming are both far more powerful tools.
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.
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.
But all these old monolithic frameworks/libraries, that try to solve everything and there citchen sink, are so 2009-ish.
They have its place in the enterprise world. And for performance optimisation you want a more modular approach.
Personally I'm with you, I enjoy a small, isolated, component based approach where each component follows the unix philosophy. I think this lets you write the most performant and resuable code. Also, I think when following this style, it limits the scope of your dependences, which is another big plus. For instance, you might need a library for crypto, but you won't need one for doing your authentication system, and you won't have massive modules for handling auth that would come from a framework getting compiled into your production code.
But when you go this route you do have to make a lot of "right" decisions that are made for you when using a framework. Also, I think a lot has to do with deadlines and developer speed, it initially takes a little longer to write good standalone components that are reusable, and just grabbing some framework will help get shit done in the short term, but might have the same detriments as technical debt in the long run.
Something like React bothers me far less as it smaller, less imposing, and solves real problems I've seen with other frameworks (for example by pushing clear/consistent/simple communication paths).
Except React is a library. The slogan [1] clearly says "A JavaScript library for building user interfaces".
[1] http://facebook.github.io/react/
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.
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..
http://www.ietf.org/rfc/rfc5023.txt
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.
* Object.observe
* Promises
* HTML Templates
Sorry but IE8 support. Nuff said.
If you replace Polymer with React, you can actually live in a world that's not so dissimilar from what the author is advocating. Of course then you're still using libraries, but arguing against libraries (as opposed to frameworks) is insane.