8 ms·

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

• Igglyboo 12y ago
  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.
  • seanflyon 12y ago
    > skill sets becoming out of date 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.
  • SonicSoul 12y ago
    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?
  • 7952 12y ago
    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.
• nawitus 12y ago
  >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.
  • mythz 12y ago
    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.
    • nawitus 12y ago
      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.
  • pistle 12y ago
    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.
  • fasouto 12y ago
    > 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.
    • greenpizza13 12y ago
• aikah 12y ago
  > 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.
  • shangxiao 12y ago
    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.
    • kaonashi 12y ago
      I think he's referring to the tight coupling between the object system and the data-binding/dom-update mechanisms. React and Angular are both able to avoid those.
    • aikah 12y ago
      > 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.
• mattwad 12y ago
  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]. [1] https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtEk/uYnY3900wpIJ https://groups.google.com/forum/#!msg/polymer-dev/4RSYaKmbtE...
• bellerocky 12y ago
  > 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.
  • SonicSoul 12y ago
    mind elaborating on what you liked about react.js over angular? I am guessing performance?
    • bellerocky 12y ago
      And inline JSX instead of separate template files. React is just very good at turning state into DOM elements.
  • enraged_camel 12y ago
    >>Personally, I have found react.js to be much better than Angular This is a tangent, but can you explain why?
    • mercer 12y ago
      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').
    • scotty79 12y ago
• Rygu 12y ago
  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. Personally I'd go for company-backed projects.
  • angersock 12y ago
    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.
    • Rygu 12y ago
      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.
      • encoderer 12y ago
        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.
• mbesto 12y ago
  > 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.
  • shangxiao 12y ago
    The risk is more about supporting legacy applications and the inevitable bitrot, not so much developers.
• soseng 12y ago
  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.
• greenpizza13 12y ago
  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.
  • sehr 12y ago
    So essentially what Ember and React have done? Nice to see
• wwweston 12y ago
  > 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.
  • rubiquity 12y ago
    > (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.
    • dpark 12y ago
      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.
      • possibilistic 12y ago
        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. http://kkovacs.eu/cassandra-vs-mongodb-vs-couchdb-vs-redis 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 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.
• ams6110 12y ago
  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.
• tootie 12y ago
  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.