I have to say, enterprise companies like WF really have it tough. With thousands of applications and tens-of-thousands of developers by the time they implement anything it's already been rendered obsolete.
At least they didn't go 100% Flex like some other companies
Flex (for better or worse) is still widely used in the financial space.
We started using the full google closure stack a couple of years ago and I am happy about that decision everyday.
I was the person that initiated using the closure library for a team back in 2010. It took ages to release products using it, someone called it the "write more, do less" library and I have regretted the decision ever since, especially when Google came out with Angular which felt like a total slap in the face. Closure Library had half hearted support, and even teams inside Google hated it, which is why Angular probably came about. It felt like a slap because people that bet on Google supporting Closure couldn't just stop using it and start using Angular.
It depends on what your desired outcome is. Angular is not as solid, not as fast, nor is the whole product as able to be statically analyzed.
Longer term maintenance is a pleasure with closure, adding new features a breeze, there are tons of exceptionally well tested components and I cannot stress enough how wonderful deep static analysis and dead code elimination is.
I don't really think it is fair to compare Angular and Google closure.
Angular is basically MVVM for the web, which is awesome because MVVM is awesome.
Closure is OOP and "lets move heaven and earth to pretend we are still coding java, but with a weird syntax and lambda functions". It appeals to different needs.
Isn't this the big advantage of open source and Javascript in general? Even if the creator abandons it, you should have enough development resources to at least maintain status quo.
Yeah it's the pro but the con (IMO) is that if you're the last active contributor then it has effectively become a custom framework... which nobody likes to support.
That's not quite right. The advantage is that you (and others) are ALLOWED to do what you want with it (within license limits), but there's no guarantee that you have the resources to make use of that right. Even maintaining the status quo might require more resources than you have as the world evolves and bit rot sets in. It is nice, though, that open source leaves open the possibility that some other party can pick up the ball if the original developers drop it and you can't do it yourself.
They chose YUI because of the current state of YUI and not because they believe on YUI future features anyway. So Yahoo bug fixes and security patches should be good enough for Wells Fargo for at least 1 year, maybe 3.
Wells Fargo is big enough that they can spend resources maintaining their fork. Yahoo is no longer working on it, but if somebody else wants to pick it up, they can.
To be fair, banks may also be grossly overvalued. Their market valuations are entirely dependent on large government bailouts (although Wells Fargo was certainly in good shape relative to their peers in 08.)
> Their market valuations are entirely dependent on large government bailouts
Hasn't been the case for years (and I'm pretty sure it was never the case actually). They are valued by their assets (funds in accounts, real estate holdings, equity in companies/investments, etc). Facebook's valuation appears to be based on nothing but magic.
They can do whatever they have the internal capacity to decide to do.
They're richer than Facebook, sure. But at many non-tech companies, spending tens or hundreds of millions of dollars to build a solid library is simply not in the cards. (Why should we spend so much on engineers? All they're doing is slapping together some HTML, my nephew in high school does that!)
Surely WF's needs with YUI-fork (or any other similar library) will be limited enough that they'll need to hire just one or two developers. I don't see how they'll need to spend hundreds (or even tens) of millions of dollars to build a solid library. I don't think even Yahoo has spent that much on YUI in total.
I worked at WF years ago on/around the WF-RIA project. They have the strongest frontend culture I've seen at any company before or since. I'm sure they'll be fine.
I also worked at WF and in my area (mutual funds) front-end was weak as hell. There were java developers, designers who still thought in points and "pixel perfect", and marketers, and just about nobody in-between. Granted this was a few years ago, but not long enough to excuse the ignorance. I can't speak too much about the rest of the company other than as a customer, and based on my experience as a customer, the front-end is weak as hell for everything else too.
Companies like Wells typically have governance policies and processes which expressly consider the scenario of the the open source 'vendor' ending development. Doesn't make it easier, but presumably someone considered the implications already.
Has anyone reading this ever worked at a place that had something like this (and was more than a paper illusion)? I think you're being overtly optimistic of big companies' IT practices.
IME, many big companies are so change-averse that an event like this is mostly irrelevant to their projects. Even if the external developer who was previously maintaining the library were still maintaining it, the project the big company is shipping would still be like 2-3 major versions behind with no immediate plans to upgrade.
Having access to the source and the legal ability to modify it without releasing rights to their own IP is the only issue I've really seen big companies be wary about when it comes to using external libraries, and practically speaking that's probably all they should be worried about.
Working at a large pharmaceutical, I can assure you this is real. There's a governance structure that rivals the size and budget of a medium sized business' entire software team's.
If a framework goes away because a clearly better alternative crops up, it is called progress :-)
In 2006, YUI was a step forward compared to the general state of JS frameworks. Today ReactJS is a step forward compared to YUI. When something supplants ReactJS because it's clearly better, I hope, nostalgia aside, few people will protest.
I will bet $5 that you never had the experience where you build on top of a platform or learn to rely on a product and suddenly it gets taken out to pasture. Nostalgia is one thing, but realizing that the application that you are supposed to support and develop for years to come is built on a platform that no longer exists really sucks. It sucks in very real, very pragmatic terms, and for all the progress we can make in the general sense, the specific case of it happening to you is not going to be much easier just because there are now better alternatives and you have an excuse to start from scratch.
One way to reduce this risk is modularization. If development stops for a single module, it can be replaced quite painlessly compared to rewriting everything because one relied on a monolithic framework.
Yes. The problem is that things like YUI (or Django, or NodeJS, or Rails) are not modules. These are frameworks where you plug your code in, not the other way around. And besides, the dictate the programming paradigm, not just variable names. You cannot create an abstraction layer on top of YUI that would work seamlessly for Angular or jQuery or straight DOM manipulation. They are completely different.
What I mean is that YUI is a large, monolithic framework, which can be replaced with a number of smaller libraries/frameworks. This is modularization, which reduces the risk of a large monolithic framework losing maintenance support.
I agree that YUI can be seen like this, with its relatively deep object relationships and manipulations required for its mvc, widgets, etc. -- but does not have to be used as such. I've been using YUI the last couple of years in a lighter way. My code uses as much modern JS as practical, and dips in to YUI for things that are tedious to do by hand. Most of my modules can be swapped out to work with requirejs, jquery, underscore, handlebars, etc. without too much fuss. I've done that a few times when YUI was slowing down and showing signs of neglect, but then went back to YUI because I saw no noticeable signs of improvement, but rather found the code more difficult to maintain -- multiple dependencies vs. 1, and each of those libraries has a multiplicative effect (different documentation locations and styles, following the updates, engaging the community, finding workarounds, etc.) For a long time YUI had great docs, great participation from core devs, and a nurturing attitude towards 3rd party modules. It is when that love began to fade, without explanation -- the promises of improvements in the future began to gather cobwebs, and the community infrastructure began to crumble (forum, gallery, web site), yui dev participation plummeted -- that I and I'm sure many other YUI users began to disengage with the YUI project, even if we were still using it.
Calling ReactJS a step forward from YUI is an extremely applesy/orangey comparison. YUI was a full-fledged do-everything framework, React is more like a hyper-efficient templating language.
Well forever is a _really_ long time, but I wouldn't be too surprised. I mean we still have significant banking infrastructure running on Cobol.
Hopefully browsers will ship with native support for something better, in addition to javascript. A common virtual machine that you could run your code on would be awesome. You can kinda do that today, except JS makes a terrible VM spec.
Probably, as javascript will remain the browser's only supported scripting language forever as it's such a big hurdle to get all the browser makers to implement a new language. I imagine javascript in the browser will eventually be like x86 assembler though in that almost everybody will write in a higher level language like coffeescript, or through layers of libraries like jQuery.
I interact with Wells for some backend services. The only interface they expose is an IE-only java applet. Can't say I'm surprised they are lagging the industry by a decade.
Several years ago I worked on the redesign for the access request tools (ART in jQueryUI, and the backend system using ExtJS), it was a lot of fun, my understanding is ExtJS and YUI share some heritage. That said, I'm not really a fan of the likes of ext, yui or dojo... they're a bit bulky and unwieldy.
Today, I've been working more on Bootstrap, React, Flux, Webpack and a few other bits... It's getting nicer all the time. I'm really appreciating JS front to back over other systems (.Net, Java) in terms of actually getting stuff done. Higher testing is pretty much required for a larger JS system, but modularity, npm, git etc go a long way.
YUI, differently from the other big js frameworks, has been around for a long time and should therefore be "stable enough" and there's a lot of code examples and documentation around the web.
I remember teaching a JS class with YUI like 9 years ago. At the time it was well featured, and had documentation that blew the competition out of the water.
Good documentation was critical, I couldn't in good conscience teach a class where my students would be out of luck for more help after they left.
Why do people use "the number of [...] issues and pull requests" to measure the usefulness of an open source project? Shouldn't a project gradually trend toward maturity, when the vast majority of bug fixes and big-win features are already part of it? Is that really the best point at which to start spinning it down?
I honestly didn't know it was still actively being developed. It has long been surpassed by other options, but I do have some [mostly] found memories of working with YUI. In the early days it was a lot more feature packed than most other frameworks I tried. In the first big professional project I helped build some 7 or 8 years ago, I even fought to use YUI over jQuery. Maybe its time to send a mia culpa over to my old company...
You recommended a Javascript library that was maintained for 8 years. I consider that a good recommendation. Backbone and Angular have only been around for half that (yet)
Abandonment is a risk facing any heavy "all-or-nothing" frameworks, not only is this bad for existing apps built on YUI, but it's also bad for developers skill set investments that will soon become obsolete.
It's hard to imagine heavy popular frameworks like AngularJS falling to the same fate, it would need something far superior with a lot of traction to displace it. But it's still a risk if you build your application the "Angular Way", "The React Way" or "The Ember Way", etc where if the primary developers halt development for whatever reason, your app dev stack becomes obsolete making it harder to attract great devs (who don't want to invest in a dying platform).
It's less of a risk with lightweight frameworks and libraries like Backbone.js where the code-base is so small and extensible, anyone can easily maintain their own fork. It's also less of a risk for WebComponents as the component model leverages the browsers DOM and lets you use modularized encapsulated components built with different technologies, so if one of the technologies ever becomes obsolete you can always start writing new components with newer tech and integrate it with your existing app, without having to rewrite it.
>but it's also bad from developers skill set investments that will soon become obsolete.
Why is it bad that developers will move from old legacy frameworks/libraries to newer, more modular solutions? I don't quite understand why someone would be unhappy to have to learn a new JavaScript framework.
Time spent learning new frameworks and "different approaches", is not spent delivering value to customers. Not to mention all the existing libraries/components accumulated in the years of simplifying building apps with it also become obsolete.
The value comes from the new "frameworks" being better than legacy. If YUI actually was better than the newer solutions, Yahoo! probably wouldn't claim that it's worse.
Experience in one context won't shift well and senior folks will seem junior, if not worse, for inserting non-idiomatic patterns into the newer solutions.
Q: Where's my cheese?
A: We don't have cheese here.
> I don't quite understand why someone would be unhappy to have to learn a new JavaScript framework.
Because you need to learn that framework.
And the new packaging system.
And the new *SQL database.
And SASS, LESS...
And the new test framework
And another build tool.
And a new programming language.
And understand the business logic of the new client.
And sleep 8 hours, exercise, see your friends, spend time with your gf...
Modern web development could be overwhelming, I'm still young and willing to learn but I totally can understand why some people stick with "old" technologies.
Unrelated: That’s uncool; you’ve just made every developer who read that, who has (or would like) a boyfriend instead of a girlfriend, feel like you think they shouldn’t belong here. And I would hope you actually don’t think that.
Your post doesn't make much sense. You could use a new packagin system, a new *SQL database, SASS/LESS, a new test framework, a new built tool etc. even without letting go of YUI.
If you never want to learn anything new, then be my guest, but I don't understand those developers.
Besides, developers should learn new software all the time, not develop with YUI for five years and suddenly learn everything at once.
He's saying there's a lot to do and already a constant flux of other new things to learn. I imagine seeing your favorite library being deprecated could be frustrating?
But I would say to those people that if the maintainers of your favorite library are saying that there are better things out there, then you have reason to learn new things.
i have a wife and 4 kids. i'm home to eat dinner with my family each day, i bathe my kids, i read to them for 15-20min before bed, i put them to bed, and then watch a tv show or movie w/ my wife. wife goes to bed, i usually stay up another 2-3 hours coding, reading, watching cosmos/st:tng, or something like practicing drywall mudding/taping. family first, then work, then sleep. w/ priorities clearly defined, i never have a problem deciding what to do (be it saying no to work at 6pm, or going back to office at 12am).
when i do read/code outside of work, i either focus on high level design pattern usage or on increasing knowledge of obscure js/css performance hacks. e.g. angular is dead-simple to write code for once you pay attention the patterns behind it instead of the conventions/syntax. otherwise it's a mess of hacked together code and googling for a better way to do what you're trying to do.
frameworks come, frameworks go. learn the foundations well and the rest of it matters a whole lot less.
This is why you should understand the language first.
A framework is just a tool to abstract some complex/repetitive tasks and work faster, but they're in no way a replacement for the language they're written in.
For example, jQuery.ajax(), you should not treat it as a black box, and pretend everything is done by magic.
You should at least understand the process behind it: Creating the XMLHTTPRequest object, setting the onreadystate event to check if the request was successful, etc.
If a feature brought by a framework is good enough, it will be added eventually to the language, ex. document.querySelectorAll().
As a developer, it's always interesting to learn outside your scope of knowledge. As a product manager, it's a PITA to spend X hours for technical stuff that delivers no value to the clients.
> But it's still a risk if you build your application the "Angular Way",
That's not true.AngularJS allows a total an clean separation between AngularJS and your code through dependency injection.
It means that your code can be totally decoupled from the framework (even the directives).
That's not the case for Backbone,Emberjs and others.Their first sin is the use of Active Record,which means vendor lockin,and over reliance on inheritance (Backbone.Model.extend ... )
A few month ago I had to make some business logic work in a webworker,without duplicating it ,nor using angulars,in an angularjs project. Because AngularJS uses an IoC container,it just worked,the only thing I had to do is to manually wire up dependencies,but the same code worked without a single line of Angular code.
That's the most important difference between AngularJS and the rest,easy opt-out. And I really hope the javascript world begins to embrace inversion of control ,because frankly,i'm sick of all these spaghetti code apps, I have to maintain. Only AngularJS gives you the tools to write clean and decoupled code without verbosity.
Backbone and Ember suffer from the same "rail's way" problem.AngularJS is a good compromise between configuration and conventions without Active Record .
People often say Backbone is "lightweight" ,actually I think AngularJS is lightweight compared to Backbone,and that's why it is so successfull, with one lib, one gets everything one needs to build small apps as well as large apps,without all the boilerplate.
Do you have any recommendations for good IoC containers for JavaScript, specifically node.js? I've looked at several and their are their far too complicated or not polished.
Depends how well built your application is. Good luck porting a crappy Angular app over - good engineering probably trumps choice of frontend framework the most.
Your rambling incoherence makes your point hard to understand. So you're saying that there's no risk of vendor lock-in by relying on Angular's dependency injection, which isn't used by other libraries? Gotcha.
Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
> Your rambling incoherence makes your point hard to understand. So you're saying that there's no risk of vendor lock-in by relying on Angular's dependency injection, which isn't used by other libraries? Gotcha.
> Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
You look frustrated, you sound you chose the wrong framework then came here to complain about those who made a smarter choice. But you're not saying anything,other than arguing on the form.
For the record, one thing I like about Angular... I think the library tries to support existing/future technologies rather than define its own way of doing things. For example, the devs are planning that components can be 'exported' to WebComponents in Angular 2.0[1].
> it would need something far superior with a lot of traction to displace it.
Personally, I have found react.js to be much better than Angular but in any case I found your comment to be filled with a heavy use of unwarranted intensifiers ("far superior") and some amount of fortune telling.
Front-end development is a fast moving field, and the new ECMAScript 6 changes, as well as further browser updates, will probably shake up the scene, but it's hard to predict what will happen. I doubt that we'll reach a point of stability any time soon where you didn't have to throw out at least some decent amount of code after 5 or 6 years due to library changes and browser updates.
I can't answer for the OP, but from my experience what makes React so good is that it drastically simplifies the whole 'situation' to the point that many of the features of heavier frameworks are just not necessary anymore. It's not just a view layer (although I can be just that); it's a different approach to the concept of a web app.
In my opinion the approach that React takes (as well as its siblings like Mithril and Ractive) will eventually be the default approach, even for the bigger frameworks (new or 'refactored').
Directives and scopes may be somewhat tricky concepts but they are not "bug ridden."
Do you want composability? Write a bunch of element directives and nest them -- it'll end up looking almost exactly like React's classes and components. The main difference is that in React you throw away MVC and replace with with a big ol' render() function that spits out "HTML" (well, a shadow-DOM version of it anyway)
Scopes are just objects that use prototypal inheritance to
inherit from outer scopes. Create an new (isolated) scope in your directive to isolate data to that component and its subcomponents.
throw away MVC and replace with with a big ol' render() function that spits out "HTML"
Simply put, no. React.js can be treated as a simple, dumb view or part of something larger ala Backbone, Flux, etc..
Angular.js doesn't even have a model layer aside from $scope, which in my experience is being thrown away more and more in favor of controllerAs syntax & convoluted services masquerading as 'models'
Sorry. After last two months with angular (and no previous experience with it) I found five bugs in angular. Fix for one was released in the meantime. Some already had fixes submitted months ago but got stuck on different stages of their process of accepting patches. One is not even reported yet (although I admit this one is not about directives but $ q).
As for composability they did not seriously thought this through. One bug I found out, the one that got fixed, showed up for anone who created two directives with isolated scope and transclusion, one used in template of the other. Basically isolated scope of outer directive got transcluded into inner one instead scope outer in relation to outside directive.
Scopes suffer from the same flaws that with() statement in js suffers mainly that when you assign inside it will be assigned not where you at first expect (current leaf scope not the scope of closest controller). When you add to this the fact that humble ng-model assigns you have a huge hole that nearly all newbies fall into at least once.
Another gripe is that angular doesn't eat it's own dogfood. For example ng-required is not a directive. It's just attribute parsed internally by input directive.
AngularUI router is worthless if you need to have multiple tabs inside your web app as it allows you to have just one branch of views tree shown at any given time. There are suggestions about implementing parallel subviews but last time I checked it was too hard for them.
Angular is set of legos with lots of weird pieces. React is blueprint how to make your own bricks so they fit together and won't turn into tower of ugly chaos when assembled.
I was distrustful towards virtual dom at first. But that's just a way of batching and saving dom changes. The architecture that's enabled by it is all about composability and maintaining control over your project.
Not every directive attribute needs to be another directive -- it's probably overkill, especially if the attribute applies to only on one type of element. ngValue is an example of dogfooding directives with more directives.
UI Router states are pretty tightly bound to the URL fragment path, which makes it difficult to point to all the parallel states that make up that particular view "configuration"
Say you have a page /foo that shows two sets of tabs, A B and X Y. To point to foo with tabs A and X open, you need put that in the URL, e.g. /foo/A,X, or express it as a state path foo.A,X. It gets even hairier if you then want to activate children of those states, e.g. A.a and X.x.
You could implement your own subview routing with ngSwitch and stateParams (perhaps query parameters). It's obviously not a great solution.
> Not every directive attribute needs to be another directive -- it's probably overkill,
I think that this particular example shows that rather than extending framework of directives to nicely incorporate lightweight directives such as ng-required angular team chose to hack it into input/select/textarea directive because it was easier that way for them. There are many places like that in angular where the hacky path was chosen and due to this, architecture is lacking some of very obvious features like one-way binding of expression given in attribute to isolate scope (which is what ng-requried does to get it's value). You need to use & as workaround to achieve one way binding.
As for Angular UI as I said there were people that wanted to figure out how to implement tabbed views but they got no love from core developers. Basically recent advice about using UI Router to implement tabbed app is "Don't".
So I just went to implement my own stuff with $route, $routeParams, $location and ng-include.
FUD. Backbone is nothing but a bootstrap. It really just means that you evetually rely on literally twenty or thirty other "micro" JS libraries to get the same shit done that one framework could singlehandedly provide. Those micro libraries have a higher abandonment rate than anything.
At the same time, a lot less is being abandoned--and your team is more likely going to be able to fight bitrot on a small microframework than on a huge thing like Angular.
Not having tons of libraries means that my team doesn't have to fight bitrot regularly though. Also bug reports / PRs are actually handled adequately by the bigger frameworks and their bigger pool of contributors, so code quality, which I find an important aspect of the software I deliver, is very much guaranteed.
I don't see much point fretting about bit rot. That's a murky future problem and there is little to guarantee the code we're writing today will outlive the libraries we're using. Instead what I care about is productivity and my experience as an engineer and engineering manager is that the simple, small, annotated source of libraries like Backbone and Underscore will beat the monolithic uber frameworks 9 times out of 10.
The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.
That's true, but most companies need to spend at least some of their time on writing their own code and features too. So we pick third party code that serves us and saves us time.
Analogy if the goal is to go for a smooth car drive, why would you want to stop and be replacing/reinventing wheels every few minutes?
Yes, when it was still relevant and heavily developed. So for a long time now I would've said chosen something else, more relevant to and convenient for modern-day web development.
Of course if you chose YUI a few years ago and you're still using and relying on it, that means it is still serving you well. Was a great past decision ay?
Well it's no longer "Google" Web Toolkit, it's now just "GWT"; they've handed it over to a steering committee.
At the time I loved using it as it had many nice features. But sadly it's very hard to migrate from. Most importantly is the vendor lock-in with the 2 framework specific RPC mechanisms used to communicate to the server.
As someone who has been working with GWT, and since moved to JS, I can elaborate on why I agree. GWT was an excellent tool when I started using it, but has been eclipsed (no pun intended) by substantially nicer frameworks (IMO). I am extremely thankful to be using it as little as possible, and am migrating as many of our GWT apps over into Javascript apps as soon as workload allows. (I'd LOVE to hear from someone who is currently using GWT, and has compelling reasons that it's a great tool that are not driven by the inertia of a large codebase.)
The main reason I'm glad not to use GWT is that I enjoy developing in Javascript a lot more than I do in GWT (Java). I have found that I can implement, modify, or troubleshoot a UI roughly an order of magnitude faster than I used to be able to do it with GWT. This is due to a combination of being able to reload by refreshing my browser (no slow re-compilation steps), as well as being able to inspect elements/styles directly in the Chrome dev tools.
There are about an order of magnitude (or more!) people who write about Javascript, or $FrameworkOfChoice (Angular, Backbone, etc) than there are that write about GWT. This includes both blogs and Stack Overflow, not to mention examples on JSFiddle or the like.
GWT doesn't easily let me integrate other Javascript libraries or components, so you have to implement your crappy version of Chosen (or similar) yourself. There's no JQuery or Underscore or similar, because it's all Java (basically).
The Chrome Dev Tools or Firebug are >>> the GWT debugger. The GWT Dev Mode plugins required for debugging, is also no longer supported in Chrome, and soon in Firefox. (I discovered this last week, the first time I've touched GWT in half a year. There's a newer Dev Tools alternative, but I've been unable to actually get it working.)
Javascript testing tools (Jasmine, phantomJS, etc) and build tools are now a MUCH more mature ecosystem than they were when GWT was first invented. We used to use a combo of JUnit + Watir/Selenium to test our UI, and now we can do similar with Javascript frameworks in a less fragile way.
In summary, GWT was awesome, but I see no reason to use it today. It helped me find my current job, so I'm grateful for that. However, if you were looking for a web framework, you would be much better served (IMO) if you chose React, Angular, or Ember rather than GWT.
Sorry to hear you couldn't get it working. We're seeing about 5x compile time improvements in Super Dev Mode on trunk, but setup is not as easy as it could be. (It's being worked on.)
I have used GWT on two from scratch front ends within the last 8 months.
All of your points are true and well written, but at the end of the day, I don't want to write and maintain large apps in JavaScript (or really in any dynamically typed language for that matter). GWT is still the best way to avoid that.
Past bad decisions stay that's hindsight. In this case not so much the project but technology has become irrelevant. Technology changes every few years or even evey year. Nothing to do about that. Software is difficult.
GWT is still being maintained, and I hear GWT 3.0 is on they way with a lot of great features.
The problem with GWT is that newer Google-associated projects are perceived by some people as better (and the comparison is not always apt): Web Components, Polymer, Dart, Angular, etc.
But that doesn't somehow make GWT any _worse_ than it was before, and it's still improving. The compiler is faster, they're adding Java 8 features like lambdas, the JS interop is better, they're tracking web APIs closer, and I think they have a even plan for web components integration.
I used to use GWT extensively, and I would be one of the ones to argue that it's approach was great at one time, and probably a bit outdated now, but it's not abandoned and it's evolving to fit better with today's modern browsers. I might not choose it today, but I wouldn't regret choosing it a few years back, or be in a huge rush to move off of it if I had a large codebase.
It's funny because although I regret using it to deliver products, I don't regret having been exposed to it as a developer. I learnt a lot about how to build well structured front end code by using it.
I still believe it's doomed though just because I don't believe they can match the pace of the JS world.
'Company-backed' is a very nebulous term. If Microsoft was backing Angular I would have every confidence that it would be supported at least for security fixes for the next 10 years even if microsoft had to add a whole compatibility layer on there next 3 OSs to do so. Google backing an open source project on the other hand has a whole different level of support expectations in a 3 year timeframe.
> But it's still a risk if you build your application the "Angular Way", "The React Way" or "The Ember Way"
This misses the point. A good developer, in my mind, has the ability to adapt regardless of they framework they choose. The only risk is really the one who chooses not to adapt, regardless of the way their CV is positioned at any one point in time.
That being said, COBOL developers still get paid $100's of dollars per hour in today's environment due to legacy software holders.
As a developer that still uses YUI on multiple production applications, I've never felt that my front-end skills were stagnating due to its usage. The same goes for ExtJs, which I have used heavily in the past. Both libraries allow you to create the models, views, controllers, templates, etc. And they both have notions of apps and routes. There might be a lot less magic going on in terms of getting data binding to work, but it's something javascript devs should understand anyways (loose coupling using custom events). I think the detriment comes more from newer companies looking to hire front end folks who have experience with modern frameworks such as angular, ember, and react. But there's also a lot of magic going on in those newer frameworks and libraries so when something breaks or you need to step out of the box, a deeper understanding of what's going on is usually good.
Just imagine if jQuery stopped development. Obviously someone would pick it up but if they didn't there would be a massive number of frontend skill sets becoming out of date.
maybe i'm missing something, but I don't see jQuery as a massive skill-set investment. There is the selectors and the api, but it does overlap with a lot of other frameworks like underscore.js etc.. after switching it would be a matter of looking up the new syntax for a few weeks?
There are probably some quite old versions of JQuery running happily. The wonderful thing is that you can Google "jquery <insert problem here>" and get a good answer. This property would be useful for a long time to come even if better libraries evolved.
I would like to point out, with regard to Angular, that they are moving to a much more lightweight delivery strategy. Their plans moving forward are to break out all the individual components into importable modules, and make Angular sort of a salad bar of functions. This should help mitigate the "all-or-nothing" nature of large frameworks. Hopefully it will also help make it relevant and compatible with new technologies like Polymer.
> It's hard to imagine heavy popular frameworks like AngularJS falling to the same fate, it would need something far superior with a lot of traction to displace it. But it's still a risk...
To emphasize the "still a risk" part: Angular is only four years old, and its popularity is arguably only two years old. People are just barely starting to get a feel for the advantages and disadvantages of building the Angular way. There's some significant things to like about it, but there's absolutely no guarantee those things won't be subsumed into something else or devs won't decide some other way is better, either on the merits of careful thinking or enthusiasm for a fashion of the moment.
(If someone had told me 10 years ago, for example, that relational databases were soon to fall out of vogue for hierarchical/document databases or key-value stores, I would have said history seemed to be against them, but here we are.)
This is software, ephemeral foundations and vicissitudes are pretty much a given.
> (If someone had told me 10 years ago, for example, that relational databases were soon to fall out of vogue for hierarchical/document databases or key-value stores, I would have said history seemed to be against them, but here we are.)
I promise you this is some sort of bias you have. Relational databases are still used way more frequently than NoSQL databases, probably to the tune of 1000-10000 times more.
Relational databases are a more general-purpose solution, so have received far more attention historically and have already matured far beyond the NoSQL alternatives. NoSQL gets press because it's different from the mature alternative and so it's interesting, but it's also very niche in comparison.
Both solve entirely different classes of problem. There are functional overlaps for small problem domains, but as your infrastructure tries to do more, you may find a need to run several distinct lightweight services backed by a variety of datastores serving focused requests.
Many of you have already seen Kovacs' comparison of nosql stores. Just throw a SQL DBMS into the decision matrix. Consider how several might work together.
(If someone had told me 10 years ago, for example, that relational databases were soon to fall out of vogue for hierarchical/document databases or key-value stores, I would have said history seemed to be against them, but here we are.)
Those who don't learn from history are doomed to repeat it.
if one of the technologies ever becomes obsolete you can always start writing new components with newer tech and integrate it with your existing app, without having to rewrite it.
This is the kind of snake oil that's been sold to developers for decades. We never (collectively) seem to learn.
The risk of abandonment is heavily mitigated by the project being open source. If an organization is heavily invested in a project that gets abandoned, they can always fork it and maintain it themselves. Compare that to what happens when a private company decides to kill a product.
I work in Liferay Portal and AUI, which is a fork of YUI. Liferay will probably be impacted greatly by this. My company has done a few large scale Enterprise application implementations in recent years and continue to do more Liferay work (It's actually booming). YUI is a huge framework and not just a library. It contains a lot of neat UI Components and Utilities. Although styling the components and making them responsive always seemed tough.
"Node.JS", "isomorphic single page applications", "npm", "bower", "Grunt", "Broccoli", "Gulp", "Backbone", "React", "Ember", "Polymer", "Angular", "Mocha", "Casper", "Karma", "evergreen web browsers", ad infinitum.
While the above bouquet of random monikers may excite the cutting-edge startup developer, try pitching such an amalgamation to management in an enterprise environment.
Inevitably, this week's fashionable web technologies will be supplanted by next week's fads. YUI was nice because it channeled the Borg in absorbing the good from multiple technologies while attempting to provide users with some form of a migration path, usually through its better-than-average documentation. YUI evolved. Many of the above technologies will be cut-and-run like the projects they supplanted last week.
Perhaps the answer to this industry's flightiness will be found in the increasing use of transpilers. Javascript, with its callback-heavy code reading like so much thread through so many needle-eyes, does not seem to engender longevity in its creations. A framework built around something like gopherjs may be more libel to grow and adapt rather than becoming yet another abandonware.
Walmart uses node.js and it has paid off for them handsomely, I'm pretty sure they fit your definition of enterprise seeing as they have 2 million employees and close to 500 million in revenue yearly.
I don't get that article. They are presumably not really using node client-side. It sounds like they just have a node backend. I'm guessig the use of node was coincident with them rebuilding from the ground up.
As I read it: they are rendering pages on the backend if a slow device visits the site. On faster devices, it's better to let the Javascript run on the client.
Node.js is a platform from which tools are built, much like Ruby, Python, Bash, and C/C++. With Node.js comes `npm`, a tool for getting the tools.
bower is also a package manager, IIRC. I'd avoid it.
Isomorphic single page apps seemed to be buzzwords to me.
Grunt, Broccoli, and Gulp are all tools used to create build scripts in the Node community. You only need one, and you could pick Grunt or Gulp with a coin flip and not be worse off.
React, Backbone, Ember, Polymer, Angular...they're all client side JS frameworks. IMO, go with React if you want stability. But in any case, this is what you would use instead of YUI. And these tools work well with the rest of tools Yahoo mentioned.
Mocha is a unit testing framework. You need some testing framework, and this is a good one.
Casper...I think that's a headless web browser. Not sure, I've never used it.
Evergreen web browsers is a buzzword for the practice of Mozilla and Google of putting out updates every 6 weeks. It's a state of the environment, not a technology.
The explosion of tools in the JS environment started with Node.js. It was a critical point in the history of JS, and it means that if you want higher quality software, you have more tools to do so. Make sure you aren't choosing tools because they are trendy, but because they solve a problem you are having.
>Isomorphic single page apps seemed to be buzzwords to me
How would you describe a single-page app that is pre-rendered on the server? Hmm, maybe "pre-rendered" would have been a better term than "isomorphic".
First you are mixing clientside and serverside development libs which are not the same thing. I believe there is little reason to use nodejs on the server. Yeah,it 'scales' , but so does the JVM or go. And frankly async programming the nodejs way sucks,even with promises or generators ,since there is no way to abstract asynchronicity 100%.
If you eleminate all the serverside tools, then you only need a framework (AngularJS for instance) and a testrunner ( like Jasmine,you can even run it on the browser directly). You might need a tool to minify code, but gzip compression,a cdn and caching are often enough to reduce the load.
What is an "isomorphic single page application"? I know what isomorphic means in a group theoretic context, but I have no idea what it means in a webapp context.
> try pitching such an amalgamation to management in an enterprise environment.
I remember being is such a "pitch" meeting once with relatively senior managers. They were discussing the difficulty integrating some components of a client side web framework, and I recall some developer excitedly announcing how some <insert random moniker> by <some random hacker> had come out just 2 weeks ago on Github that would solve all their problems.
The looks on their enterprisy faces was priceless.
Management should not be told what kind of tech will be used to build their system, at least not on such a detailed level as that.
And if you want something enterprizy just tell them you will be using Google Closure which looks enough like Java that they are going to leave you alone.
>While the above bouquet of random monikers may excite the cutting-edge startup developer, try pitching such an amalgamation to management in an enterprise environment.
What "management" makes these kind of tech decisions? Sounds like a flawed management structure.
honestly at this point, i think most people are using jquery with either jqueryui or bootstrap. Still its really sad to see such an established framework become EOL. Thank you Yahoo for all the work you've done on YUI.
When teams halt development on projects, I really appreciate when they say "People should go use project X" instead. I know it is difficult to full their full-weight behind a single endorsement, but the team is obviously picking an alternative and since their followers trusted their original code they should trust the successor.
It would be great if the YUI team stood up and said "We're moving to something, and think you should too."
Given how many things YUI was composed of, I doubt there's one single "move to this" library out there. People aren't making these sorts of monolithic do-everything libraries anymore.
Right now the scenario here at Yahoo is mixed. We have teams using Ember and React, but no enforcement or recommendation to migrate any product based on YUI to any other technology.
I guess Yahoo official support for any other library is very unlikely to happen in the near future.
All of the UI teams in Ads & Data are mandated to use EmberJS. Having said that, I do know of a team exploring AngularJS and know that ReactJS is ramping up in other departments.
There's really no basis for putting a stake in the ground with web front-end frameworks right now. Based on recent history, the leading frameworks today will be YUI in 2-5 years. The best you can do is chose something that has a large community TODAY, get the most mileage you can out of it, and know that in 5 years or so you'll be scrapping most of it.
Scrapping it may not be an option. If you have built hundreds of thousands of lines on top of a framework, the cost of a rewrite will dwarf the cost of maintaining the framework yourself. The trick is to choose a framework which you can maintain yourself (sources to every aspect of it which you understand well enough to maintain).
"If you have built hundreds of thousands of lines on top of a framework,"
Perhaps that wasn't the smartest architecture decision made. Now, don't compound it by rewriting it in the same deeply coupled way for the next shiny framework that sashay's by.
This is interesting, and more than a little bit sad, given that one of the big recent pushes that YUI had done was to build out their own "MVC" App Framework:
I wonder if YUI was solving any Yahoo specific problems, their goal (should be) is to make FrontEnd Dev easy for Yahoo employees not to build a framework that's a good fit for the rest of the world. So who cares if its losing traction in the open source community?
> New application frameworks (Backbone, React, Ember, Polymer, Angular, etc.) have helped architect web applications in a more scalable and maintainable way.
Then they say:
> The consequence of this evolution in web technologies is that large JavaScript libraries, such as YUI, have been receiving less attention from the community. Many developers today look at large JavaScript libraries as walled gardens they don’t want to be locked into.
If by "component library" you mean a library of components, then Polymer is not a component library. Polymer is just a library that helps you write custom elements.
The Polymer project has created two separate component libraries of elements made with Polymer - core-elements and paper-elements - but Polymer itself doesn't contain any components.
First posted on /r/javascript, but I think it's worth posting here too:
I was a member of the YUI team until a few months ago. I'm still at Yahoo now, just on a different team, but just wanted to give my own thoughts on this (I don't represent the company or the YUI team).
My software engineering career started with the YUI team - I actually joined as an intern at Yahoo because of a Reddit post on /r/javascript. I was pretty new to engineering in general back then, and as a biology major with no real professional experience, I didn't have an easy time getting internships. Jenny, the manager of the YUI team back then, really took a chance on me, and that really changed my entire career path.
I solved a bunch of YUI bugs, added a few features here or there, and I always tried to help other folks on #yui on IRC, the mailing list, or in-person here at Yahoo, which I really enjoyed. I learned a crazy amount of JavaScript, some pretty advanced debugging / performance profiling techniques, and even gave some talks. Eventually, a lot of people always came to me first whenever they had a question about YUI, which was pretty cool.
From the view of some people in the JavaScript community, YUI was always considered a huge, monolithic framework that was only good for widgets. I never thought that was the case - YUI pioneered a lot of the techniques that are popular in advanced JavaScript development today, like modules, dynamic loading, and creating logical view separation in your code. A lot of the influence in RequireJS / CommonJS / ES6 modules can be seen from what YUI did first, which people used to consider "over-engineering".
With a lot of new development in JavaScript though (data-binding, tooling like Grunt / Yeoman, promises and other async handling techniques), it was always hard for YUI to keep up with new features while still being able to maintain backwards compatibility with the constantly deploying products that people were building at Yahoo. We had to support product teams while also building out the framework at the same time, and making sure the user-facing products were the best was more important. Eventually, it was hard when developers who were familiar with newer JavaScript tools tried to use YUI, but ended up having to spend quite some time with the framework just to get it working with the rest of the JS ecosystem.
In the end, I wasn't involved with this decision, but I think it was the right thing to do. A lot of the YUI (now YPT) team and other front-end teams at Yahoo are now working on helping out with more cutting-edge core JavaScript work, like internationalization (https://github.com/yahoo/intl-messageformat) and ES6 modules, as well as building out components for newer frameworks like React and Ember (https://github.com/yahoo/flux-examples). Yahoo still has a lot of really strong front-end developers, and working on these more important core components is more beneficial to both Yahoo and the JS community as a whole, than continuing to maintain a framework that's a walled garden.
The one thing to take away from this is that no technology lasts forever, and in the end, what the user sees is the most important, whether it's JavaScript, Android / iOS, or holographic smartwatches.
I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.
I have to give some serious props for Yahoo for taking a chance on a new dev with little experience. A lot of people go through the same frustrating thing, and many potentially talented people get looked over. Your story is inspiring (as well as a little wink to hiring managers :)
Also, super excited about the work Yahoo has been doing with React. Keep it up!
When I was a hiring manager at Yahoo, I constantly included a mix of new developers to veteran ones (perhaps a 80/20 split) for many reasons:
+ New devs can soak up a ton of knowledge quickly.
+ New devs don't come with a lot of baggage and tend to enjoy trying lots of new things.
+ New devs brought new ideas to the team that often challenged traditional ways of thinking.
+ While veteran devs acted as mentors and shared best practices.
From a recruiting standpoint, it's also easier to find new developers than veteran ones. So many companies fight for experienced talent that they overlook inexperienced talent, which meant I could assemble a good team relatively quickly.
It changed the recruiting process quite a bit though. Interviews became more about assessing potential and ability to learn than existing skills (which I think is more important anyways). It's not easy to assess for these things though.
It also changed the training process and team dynamic. The environment was one of constant learning and collaboration. New ideas were welcomed, code reviews were frequent, everyone was encouraged to hold a quick informal brownbag session on something they learned (even if others were known to be the "experts"), formal mentoring programs were established, etc.
And it made the veteran hires even more important. These devs needed to not only be strong technically, but strong with interpersonal skills too. But someone who can do this and support an inexperienced team with lots of potential is worth their weight in gold.
A lot of good developers emerged from this process. And I should add that new != young developers. There were some devs who changed careers to become devs, and shared the same energy and ability to learn as recent college graduates.
This is great. I got my first tech-related job (my first job ever, to be fair) because a hiring manager took a chance on me. This opened the doors for me to work at some great companies.
I wish I had kept a list of all the ideas you brought to the table that significantly influenced the team. From the Clarion method of code reviews to team seating arrangements to all the innovative ideas that we later saw being implemented by other startups, you were and are a font of inspiration and ideas! Your current team is extremely lucky to have you!
230 comments
[ 2.9 ms ] story [ 254 ms ] threadI have to say, enterprise companies like WF really have it tough. With thousands of applications and tens-of-thousands of developers by the time they implement anything it's already been rendered obsolete.
At least they didn't go 100% Flex like some other companies
Frankly, it soured me on the whole third-party framework idea, seeing how it was impossible to predict which one will retain support over the years.
Longer term maintenance is a pleasure with closure, adding new features a breeze, there are tons of exceptionally well tested components and I cannot stress enough how wonderful deep static analysis and dead code elimination is.
Angular is basically MVVM for the web, which is awesome because MVVM is awesome.
Closure is OOP and "lets move heaven and earth to pretend we are still coding java, but with a weird syntax and lambda functions". It appeals to different needs.
Hasn't been the case for years (and I'm pretty sure it was never the case actually). They are valued by their assets (funds in accounts, real estate holdings, equity in companies/investments, etc). Facebook's valuation appears to be based on nothing but magic.
And this is the most ridiculous thing in those bailouts. You manage responsibly and competently and, in return, you get government funded competition.
There should be a better way.
In other words, such valuation of a big corporation has little to do with the direct utility to, or meaning for a single individual.
It's like a red blood-cell wondering why the eye is so highly valued compared to the liver.
They're richer than Facebook, sure. But at many non-tech companies, spending tens or hundreds of millions of dollars to build a solid library is simply not in the cards. (Why should we spend so much on engineers? All they're doing is slapping together some HTML, my nephew in high school does that!)
When did Facebook become the benchmark? Facebook is tiny compared to an awful lot of companies.
Having access to the source and the legal ability to modify it without releasing rights to their own IP is the only issue I've really seen big companies be wary about when it comes to using external libraries, and practically speaking that's probably all they should be worried about.
I will code up and play the worlds smallest violin in reactjs today in their honor.
In 2006, YUI was a step forward compared to the general state of JS frameworks. Today ReactJS is a step forward compared to YUI. When something supplants ReactJS because it's clearly better, I hope, nostalgia aside, few people will protest.
Hopefully browsers will ship with native support for something better, in addition to javascript. A common virtual machine that you could run your code on would be awesome. You can kinda do that today, except JS makes a terrible VM spec.
https://www.destroyallsoftware.com/talks/the-birth-and-death...
Today, I've been working more on Bootstrap, React, Flux, Webpack and a few other bits... It's getting nicer all the time. I'm really appreciating JS front to back over other systems (.Net, Java) in terms of actually getting stuff done. Higher testing is pretty much required for a larger JS system, but modularity, npm, git etc go a long way.
Occasionally I still see YUI tutorials but to be honest, the usage is quite low. At least the number of "mentions" today.
Good documentation was critical, I couldn't in good conscience teach a class where my students would be out of luck for more help after they left.
It's hard to imagine heavy popular frameworks like AngularJS falling to the same fate, it would need something far superior with a lot of traction to displace it. But it's still a risk if you build your application the "Angular Way", "The React Way" or "The Ember Way", etc where if the primary developers halt development for whatever reason, your app dev stack becomes obsolete making it harder to attract great devs (who don't want to invest in a dying platform).
It's less of a risk with lightweight frameworks and libraries like Backbone.js where the code-base is so small and extensible, anyone can easily maintain their own fork. It's also less of a risk for WebComponents as the component model leverages the browsers DOM and lets you use modularized encapsulated components built with different technologies, so if one of the technologies ever becomes obsolete you can always start writing new components with newer tech and integrate it with your existing app, without having to rewrite it.
Why is it bad that developers will move from old legacy frameworks/libraries to newer, more modular solutions? I don't quite understand why someone would be unhappy to have to learn a new JavaScript framework.
Because you need to learn that framework.
And the new packaging system.
And the new *SQL database.
And SASS, LESS...
And the new test framework
And another build tool.
And a new programming language.
And understand the business logic of the new client.
And sleep 8 hours, exercise, see your friends, spend time with your gf...
Modern web development could be overwhelming, I'm still young and willing to learn but I totally can understand why some people stick with "old" technologies.
Unrelated: That’s uncool; you’ve just made every developer who read that, who has (or would like) a boyfriend instead of a girlfriend, feel like you think they shouldn’t belong here. And I would hope you actually don’t think that.
If you never want to learn anything new, then be my guest, but I don't understand those developers.
Besides, developers should learn new software all the time, not develop with YUI for five years and suddenly learn everything at once.
But I would say to those people that if the maintainers of your favorite library are saying that there are better things out there, then you have reason to learn new things.
when i do read/code outside of work, i either focus on high level design pattern usage or on increasing knowledge of obscure js/css performance hacks. e.g. angular is dead-simple to write code for once you pay attention the patterns behind it instead of the conventions/syntax. otherwise it's a mess of hacked together code and googling for a better way to do what you're trying to do.
frameworks come, frameworks go. learn the foundations well and the rest of it matters a whole lot less.
A framework is just a tool to abstract some complex/repetitive tasks and work faster, but they're in no way a replacement for the language they're written in.
For example, jQuery.ajax(), you should not treat it as a black box, and pretend everything is done by magic.
You should at least understand the process behind it: Creating the XMLHTTPRequest object, setting the onreadystate event to check if the request was successful, etc.
If a feature brought by a framework is good enough, it will be added eventually to the language, ex. document.querySelectorAll().
That's not true.AngularJS allows a total an clean separation between AngularJS and your code through dependency injection.
It means that your code can be totally decoupled from the framework (even the directives).
That's not the case for Backbone,Emberjs and others.Their first sin is the use of Active Record,which means vendor lockin,and over reliance on inheritance (Backbone.Model.extend ... )
A few month ago I had to make some business logic work in a webworker,without duplicating it ,nor using angulars,in an angularjs project. Because AngularJS uses an IoC container,it just worked,the only thing I had to do is to manually wire up dependencies,but the same code worked without a single line of Angular code.
That's the most important difference between AngularJS and the rest,easy opt-out. And I really hope the javascript world begins to embrace inversion of control ,because frankly,i'm sick of all these spaghetti code apps, I have to maintain. Only AngularJS gives you the tools to write clean and decoupled code without verbosity.
Backbone and Ember suffer from the same "rail's way" problem.AngularJS is a good compromise between configuration and conventions without Active Record .
People often say Backbone is "lightweight" ,actually I think AngularJS is lightweight compared to Backbone,and that's why it is so successfull, with one lib, one gets everything one needs to build small apps as well as large apps,without all the boilerplate.
[1] https://github.com/c9/architect
Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
React and Angular are both able to avoid those.
> Edit: Oh and it isn't polite to write things like "That's bullshit", then come back and edit it out later on without flagging that you've edited your code.
You look frustrated, you sound you chose the wrong framework then came here to complain about those who made a smarter choice. But you're not saying anything,other than arguing on the form.
[1] https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...
Personally, I have found react.js to be much better than Angular but in any case I found your comment to be filled with a heavy use of unwarranted intensifiers ("far superior") and some amount of fortune telling.
Front-end development is a fast moving field, and the new ECMAScript 6 changes, as well as further browser updates, will probably shake up the scene, but it's hard to predict what will happen. I doubt that we'll reach a point of stability any time soon where you didn't have to throw out at least some decent amount of code after 5 or 6 years due to library changes and browser updates.
This is a tangent, but can you explain why?
In my opinion the approach that React takes (as well as its siblings like Mithril and Ractive) will eventually be the default approach, even for the bigger frameworks (new or 'refactored').
Angular has some fair parts (testing, resources) and some really convoluted and what's more important bug ridden parts (directives and scopes).
Do you want composability? Write a bunch of element directives and nest them -- it'll end up looking almost exactly like React's classes and components. The main difference is that in React you throw away MVC and replace with with a big ol' render() function that spits out "HTML" (well, a shadow-DOM version of it anyway)
Scopes are just objects that use prototypal inheritance to inherit from outer scopes. Create an new (isolated) scope in your directive to isolate data to that component and its subcomponents.
Also, using AngularUI Router is essential.
Simply put, no. React.js can be treated as a simple, dumb view or part of something larger ala Backbone, Flux, etc..
Angular.js doesn't even have a model layer aside from $scope, which in my experience is being thrown away more and more in favor of controllerAs syntax & convoluted services masquerading as 'models'
As for composability they did not seriously thought this through. One bug I found out, the one that got fixed, showed up for anone who created two directives with isolated scope and transclusion, one used in template of the other. Basically isolated scope of outer directive got transcluded into inner one instead scope outer in relation to outside directive.
Scopes suffer from the same flaws that with() statement in js suffers mainly that when you assign inside it will be assigned not where you at first expect (current leaf scope not the scope of closest controller). When you add to this the fact that humble ng-model assigns you have a huge hole that nearly all newbies fall into at least once.
Another gripe is that angular doesn't eat it's own dogfood. For example ng-required is not a directive. It's just attribute parsed internally by input directive.
AngularUI router is worthless if you need to have multiple tabs inside your web app as it allows you to have just one branch of views tree shown at any given time. There are suggestions about implementing parallel subviews but last time I checked it was too hard for them.
Angular is set of legos with lots of weird pieces. React is blueprint how to make your own bricks so they fit together and won't turn into tower of ugly chaos when assembled.
I was distrustful towards virtual dom at first. But that's just a way of batching and saving dom changes. The architecture that's enabled by it is all about composability and maintaining control over your project.
UI Router states are pretty tightly bound to the URL fragment path, which makes it difficult to point to all the parallel states that make up that particular view "configuration"
Say you have a page /foo that shows two sets of tabs, A B and X Y. To point to foo with tabs A and X open, you need put that in the URL, e.g. /foo/A,X, or express it as a state path foo.A,X. It gets even hairier if you then want to activate children of those states, e.g. A.a and X.x.
You could implement your own subview routing with ngSwitch and stateParams (perhaps query parameters). It's obviously not a great solution.
I think that this particular example shows that rather than extending framework of directives to nicely incorporate lightweight directives such as ng-required angular team chose to hack it into input/select/textarea directive because it was easier that way for them. There are many places like that in angular where the hacky path was chosen and due to this, architecture is lacking some of very obvious features like one-way binding of expression given in attribute to isolate scope (which is what ng-requried does to get it's value). You need to use & as workaround to achieve one way binding.
As for Angular UI as I said there were people that wanted to figure out how to implement tabbed views but they got no love from core developers. Basically recent advice about using UI Router to implement tabbed app is "Don't".
So I just went to implement my own stuff with $route, $routeParams, $location and ng-include.
Personally I'd go for company-backed projects.
The trouble is that people often use examples of what you can accomplish with a framework if you follow the common path. But we've all been there -- a 20 hour feature where you build 90% of it with heavy framework support in the first 10 hours, then spend the next 10 fighting the framework for whatever it is that you need done differently than the framework prescribes. This blunts that seemingly-huge time save that a framework appears to provide when you watch a 5 minute build-a-blog screencast. So in the end, it comes, as it usually does, to mastery. The guy who has developed mastery over his tools will outperform, and I think it's a lot easier to master these small libraries with accessible source code.
Analogy if the goal is to go for a smooth car drive, why would you want to stop and be replacing/reinventing wheels every few minutes?
> Personally I'd go for company-backed projects.
You mean company-backed projects like YUI?
Of course if you chose YUI a few years ago and you're still using and relying on it, that means it is still serving you well. Was a great past decision ay?
At the time I loved using it as it had many nice features. But sadly it's very hard to migrate from. Most importantly is the vendor lock-in with the 2 framework specific RPC mechanisms used to communicate to the server.
The main reason I'm glad not to use GWT is that I enjoy developing in Javascript a lot more than I do in GWT (Java). I have found that I can implement, modify, or troubleshoot a UI roughly an order of magnitude faster than I used to be able to do it with GWT. This is due to a combination of being able to reload by refreshing my browser (no slow re-compilation steps), as well as being able to inspect elements/styles directly in the Chrome dev tools.
There are about an order of magnitude (or more!) people who write about Javascript, or $FrameworkOfChoice (Angular, Backbone, etc) than there are that write about GWT. This includes both blogs and Stack Overflow, not to mention examples on JSFiddle or the like.
GWT doesn't easily let me integrate other Javascript libraries or components, so you have to implement your crappy version of Chosen (or similar) yourself. There's no JQuery or Underscore or similar, because it's all Java (basically).
The Chrome Dev Tools or Firebug are >>> the GWT debugger. The GWT Dev Mode plugins required for debugging, is also no longer supported in Chrome, and soon in Firefox. (I discovered this last week, the first time I've touched GWT in half a year. There's a newer Dev Tools alternative, but I've been unable to actually get it working.)
Javascript testing tools (Jasmine, phantomJS, etc) and build tools are now a MUCH more mature ecosystem than they were when GWT was first invented. We used to use a combo of JUnit + Watir/Selenium to test our UI, and now we can do similar with Javascript frameworks in a less fragile way.
In summary, GWT was awesome, but I see no reason to use it today. It helped me find my current job, so I'm grateful for that. However, if you were looking for a web framework, you would be much better served (IMO) if you chose React, Angular, or Ember rather than GWT.
All of your points are true and well written, but at the end of the day, I don't want to write and maintain large apps in JavaScript (or really in any dynamically typed language for that matter). GWT is still the best way to avoid that.
The problem with GWT is that newer Google-associated projects are perceived by some people as better (and the comparison is not always apt): Web Components, Polymer, Dart, Angular, etc.
But that doesn't somehow make GWT any _worse_ than it was before, and it's still improving. The compiler is faster, they're adding Java 8 features like lambdas, the JS interop is better, they're tracking web APIs closer, and I think they have a even plan for web components integration.
I used to use GWT extensively, and I would be one of the ones to argue that it's approach was great at one time, and probably a bit outdated now, but it's not abandoned and it's evolving to fit better with today's modern browsers. I might not choose it today, but I wouldn't regret choosing it a few years back, or be in a huge rush to move off of it if I had a large codebase.
I still believe it's doomed though just because I don't believe they can match the pace of the JS world.
This misses the point. A good developer, in my mind, has the ability to adapt regardless of they framework they choose. The only risk is really the one who chooses not to adapt, regardless of the way their CV is positioned at any one point in time.
That being said, COBOL developers still get paid $100's of dollars per hour in today's environment due to legacy software holders.
To an extent. None of the people I know who use jQuery regularly would have any trouble adapting. They might be unproductive for a couple weeks.
Large code bases that depend on jQuery seem like a bigger problem if for some reason no one was able maintain jQuery.
To emphasize the "still a risk" part: Angular is only four years old, and its popularity is arguably only two years old. People are just barely starting to get a feel for the advantages and disadvantages of building the Angular way. There's some significant things to like about it, but there's absolutely no guarantee those things won't be subsumed into something else or devs won't decide some other way is better, either on the merits of careful thinking or enthusiasm for a fashion of the moment.
(If someone had told me 10 years ago, for example, that relational databases were soon to fall out of vogue for hierarchical/document databases or key-value stores, I would have said history seemed to be against them, but here we are.)
This is software, ephemeral foundations and vicissitudes are pretty much a given.
I promise you this is some sort of bias you have. Relational databases are still used way more frequently than NoSQL databases, probably to the tune of 1000-10000 times more.
Many of you have already seen Kovacs' comparison of nosql stores. Just throw a SQL DBMS into the decision matrix. Consider how several might work together.
http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis
Fowler's microservice post is a decent introduction to the microservice architecture, which is more or less what I'm describing.
http://martinfowler.com/articles/microservices.html
Granted, this probably isn't how to get the MVP out the door. But once you grow, this architecture can prevent the formation of monoliths of pain.
Those who don't learn from history are doomed to repeat it.
This is the kind of snake oil that's been sold to developers for decades. We never (collectively) seem to learn.
Yahoo owns tumblr.
Liferay, meh they seem break stuff with every new release anyway :)
While the above bouquet of random monikers may excite the cutting-edge startup developer, try pitching such an amalgamation to management in an enterprise environment.
Inevitably, this week's fashionable web technologies will be supplanted by next week's fads. YUI was nice because it channeled the Borg in absorbing the good from multiple technologies while attempting to provide users with some form of a migration path, usually through its better-than-average documentation. YUI evolved. Many of the above technologies will be cut-and-run like the projects they supplanted last week.
Perhaps the answer to this industry's flightiness will be found in the increasing use of transpilers. Javascript, with its callback-heavy code reading like so much thread through so many needle-eyes, does not seem to engender longevity in its creations. A framework built around something like gopherjs may be more libel to grow and adapt rather than becoming yet another abandonware.
http://venturebeat.com/2012/01/24/why-walmart-is-using-node-...
You mean 500 Billion.
bower is also a package manager, IIRC. I'd avoid it.
Isomorphic single page apps seemed to be buzzwords to me.
Grunt, Broccoli, and Gulp are all tools used to create build scripts in the Node community. You only need one, and you could pick Grunt or Gulp with a coin flip and not be worse off.
React, Backbone, Ember, Polymer, Angular...they're all client side JS frameworks. IMO, go with React if you want stability. But in any case, this is what you would use instead of YUI. And these tools work well with the rest of tools Yahoo mentioned.
Mocha is a unit testing framework. You need some testing framework, and this is a good one.
Casper...I think that's a headless web browser. Not sure, I've never used it.
Evergreen web browsers is a buzzword for the practice of Mozilla and Google of putting out updates every 6 weeks. It's a state of the environment, not a technology.
The explosion of tools in the JS environment started with Node.js. It was a critical point in the history of JS, and it means that if you want higher quality software, you have more tools to do so. Make sure you aren't choosing tools because they are trendy, but because they solve a problem you are having.
It's an abstraction and utility library that sits in front of headless web browsers.
How would you describe a single-page app that is pre-rendered on the server? Hmm, maybe "pre-rendered" would have been a better term than "isomorphic".
If you eleminate all the serverside tools, then you only need a framework (AngularJS for instance) and a testrunner ( like Jasmine,you can even run it on the browser directly). You might need a tool to minify code, but gzip compression,a cdn and caching are often enough to reduce the load.
I remember being is such a "pitch" meeting once with relatively senior managers. They were discussing the difficulty integrating some components of a client side web framework, and I recall some developer excitedly announcing how some <insert random moniker> by <some random hacker> had come out just 2 weeks ago on Github that would solve all their problems.
The looks on their enterprisy faces was priceless.
And if you want something enterprizy just tell them you will be using Google Closure which looks enough like Java that they are going to leave you alone.
What "management" makes these kind of tech decisions? Sounds like a flawed management structure.
Nowadays Angular is what killed jQuery for me (I still like to be able to use jqLite or jQuery if needed it though).
I guess that (regular CS) pattern means that the next big thing will be a lightweight library (React ?).
It would be great if the YUI team stood up and said "We're moving to something, and think you should too."
just sayin' :)
I guess Yahoo official support for any other library is very unlikely to happen in the near future.
Perhaps that wasn't the smartest architecture decision made. Now, don't compound it by rewriting it in the same deeply coupled way for the next shiny framework that sashay's by.
Abandoning YUI is a sensible move by Yahoo for a technology whose time has passed.
Docs: http://yuilibrary.com/yui/docs/app/
Video: https://www.youtube.com/watch?v=wCexiX_eUJA
> New application frameworks (Backbone, React, Ember, Polymer, Angular, etc.) have helped architect web applications in a more scalable and maintainable way.
Then they say:
> The consequence of this evolution in web technologies is that large JavaScript libraries, such as YUI, have been receiving less attention from the community. Many developers today look at large JavaScript libraries as walled gardens they don’t want to be locked into.
Huh?
Ember and Angular are heavier weight but they do play well with others in different cases (there is definite lock in however with those).
The Polymer project has created two separate component libraries of elements made with Polymer - core-elements and paper-elements - but Polymer itself doesn't contain any components.
YUI.util.Event.addListener('el', 'click'...);
I was a member of the YUI team until a few months ago. I'm still at Yahoo now, just on a different team, but just wanted to give my own thoughts on this (I don't represent the company or the YUI team).
My software engineering career started with the YUI team - I actually joined as an intern at Yahoo because of a Reddit post on /r/javascript. I was pretty new to engineering in general back then, and as a biology major with no real professional experience, I didn't have an easy time getting internships. Jenny, the manager of the YUI team back then, really took a chance on me, and that really changed my entire career path. I solved a bunch of YUI bugs, added a few features here or there, and I always tried to help other folks on #yui on IRC, the mailing list, or in-person here at Yahoo, which I really enjoyed. I learned a crazy amount of JavaScript, some pretty advanced debugging / performance profiling techniques, and even gave some talks. Eventually, a lot of people always came to me first whenever they had a question about YUI, which was pretty cool.
From the view of some people in the JavaScript community, YUI was always considered a huge, monolithic framework that was only good for widgets. I never thought that was the case - YUI pioneered a lot of the techniques that are popular in advanced JavaScript development today, like modules, dynamic loading, and creating logical view separation in your code. A lot of the influence in RequireJS / CommonJS / ES6 modules can be seen from what YUI did first, which people used to consider "over-engineering".
With a lot of new development in JavaScript though (data-binding, tooling like Grunt / Yeoman, promises and other async handling techniques), it was always hard for YUI to keep up with new features while still being able to maintain backwards compatibility with the constantly deploying products that people were building at Yahoo. We had to support product teams while also building out the framework at the same time, and making sure the user-facing products were the best was more important. Eventually, it was hard when developers who were familiar with newer JavaScript tools tried to use YUI, but ended up having to spend quite some time with the framework just to get it working with the rest of the JS ecosystem.
In the end, I wasn't involved with this decision, but I think it was the right thing to do. A lot of the YUI (now YPT) team and other front-end teams at Yahoo are now working on helping out with more cutting-edge core JavaScript work, like internationalization (https://github.com/yahoo/intl-messageformat) and ES6 modules, as well as building out components for newer frameworks like React and Ember (https://github.com/yahoo/flux-examples). Yahoo still has a lot of really strong front-end developers, and working on these more important core components is more beneficial to both Yahoo and the JS community as a whole, than continuing to maintain a framework that's a walled garden.
The one thing to take away from this is that no technology lasts forever, and in the end, what the user sees is the most important, whether it's JavaScript, Android / iOS, or holographic smartwatches.
I'll be a bit melancholy today, but I'll raise a glass to YUI tonight. RIP.
Also, super excited about the work Yahoo has been doing with React. Keep it up!
+ New devs can soak up a ton of knowledge quickly.
+ New devs don't come with a lot of baggage and tend to enjoy trying lots of new things.
+ New devs brought new ideas to the team that often challenged traditional ways of thinking.
+ While veteran devs acted as mentors and shared best practices.
From a recruiting standpoint, it's also easier to find new developers than veteran ones. So many companies fight for experienced talent that they overlook inexperienced talent, which meant I could assemble a good team relatively quickly.
It changed the recruiting process quite a bit though. Interviews became more about assessing potential and ability to learn than existing skills (which I think is more important anyways). It's not easy to assess for these things though.
It also changed the training process and team dynamic. The environment was one of constant learning and collaboration. New ideas were welcomed, code reviews were frequent, everyone was encouraged to hold a quick informal brownbag session on something they learned (even if others were known to be the "experts"), formal mentoring programs were established, etc.
And it made the veteran hires even more important. These devs needed to not only be strong technically, but strong with interpersonal skills too. But someone who can do this and support an inexperienced team with lots of potential is worth their weight in gold.
A lot of good developers emerged from this process. And I should add that new != young developers. There were some devs who changed careers to become devs, and shared the same energy and ability to learn as recent college graduates.
Cheers to people like you!
You know... It's still open-source.
If not even Oracle could manage to kill MySQL, I seriously doubt there is a way to kill YUI.