9 ms·

Angular Material 1 will enter a maintenance mode

121 points by skrowl 10y ago

pg_is_a_butt 10y ago
this seems to be stardard practice at google. i've submitted tons of bugs ("issues") about app engine and compute engine, and google cloud in general, and after a month of them doing nothing, they respond with, "looks like we haven't done anything, closing"... they close it, you can't reopen. why fucking bother. just a bunch of idiots working over there padding their closed issue stats while they jerk off in larry's mouth.
franciscop 10y ago
I am the author of a slightly popular CSS library [1] and JS library [2] and I feel the pain explained here, trying to keep up the pace of issues and PR is daunting. However, cmon Google! You are not a sole developer lost somewhere in Spain. Get your act together and really support your own libraries for a sensible amount of time. Or hire more people to do so. [1] http://picnicss.com/ http://picnicss.com/ [2] http://umbrellajs.com/ http://umbrellajs.com/
- user_0001 10y ago
  support and google in the same sentence do not go well together
  - rch 10y ago
    I'm finding I get excellent service on the products I pay for.
    - Klathmon 10y ago
      And i get wonderful support even on those I don't... I've never had a bad support experience with google, from youtube, to gmail, to google apps for work, to some issues with my adsesnse account. Do those saying they have no support ever try? There are "contact us" links everywhere for most services, and they are really damn responsive when i need to.
- nixgeek 10y ago
  Not sure if sarcastic or serious. It seems to me that a major problem for Open Source in 2016 is assumption of support from the originating entity or person. Does this base assumption not risk alienating individuals and organisations into saying, "Should I release this at all?". Why should they hire people to support something which generates, as far as I can see, no revenue for Google?
  - deckar01 10y ago
    > Why should they hire people to support something which generates, as far as I can see, no revenue for Google? The reason most companies release projects open source for free is that they created them to solve a problem for themselves, but want to benefit from community contributions. Google's ease of abandon suggests they are not really using this library internally.
  - rhizome 10y ago
    Why should they hire people to support something which generates, as far as I can see, no revenue for Google? Because it helps people use Material design. I feel this interpretation is supported by the concept of brand advertising, such as Coca Cola commercials not really having a direct effect on sales.
  - franciscop 10y ago
    English is not my native language so I apologize for the misunderstanding, I didn't mean any sarcasm here. There is a big difference between releasing software "as-is", and saying - or making it look like - it will be supported for a long time: > "it was previously stated that Angular 1 will be supported for a long time to come" - Zach Bjornson Arguably, one of the main goals of Open Source is to be used. If companies that set expectations of support don't support it, then I think the future of Open Source is really doomed.
fridek 10y ago
The title is misleading, discussion linked has a clear explanation: > You are correct that many valid issues/bugs have been closed without resolution. > Our team simply does not have time to address all issues AND build Angular Material 2. (This is what we have consistently stated in our Forum posts). > We welcome community leadership with Pull Requests. Often those PRs have side affects, their scope of changes is too large, and ultimately the risk is simply too great to merge. > So we close/reject the PR... we do this to protect the existing user base. Pull Requests that have granular improvements and fixes are much easier to assess, test, and merge... and thus can be quickly merged. > Pull Requests that are submitted referencing closed issues will then trigger us to reopen those issues; until the merge is complete. > After Angular Material 2 has been released, we expect to continue to support and improve Angular Material 1 for many quarters. > Both versions are important. Both are need to support the Angular 1 and Angular 2 developers For me it's clear while the work on Material 1.x is not prioritized, it's not officially deprecated and PRs are still welcome if they are reasonable in size and impact.
- cwyers 10y ago
  The fact that you felt that you needed seven lines of pull-quotes to repudiate the "misleading" title is a pretty good indicator that titles are, um, titles and thus cannot carry as much information as one might want. But even after reading the material you quoted, I don't see the title of this submission as inaccurate.
  - Leszek 10y ago
    I think removing the word "deprecated" would go a long way towards making the title less misleading.
    - ebbv 10y ago
      Well deprecated may not be exactly the right word, but there's not a single word that is totally accurate. Maybe "sunsetting"? :P
      - 10y ago
LOSEYOURSELF 10y ago
The old joke about sleeping through the birth, life, and death of a JS framework is still alive and well I see.
- spinlock 10y ago
  This is just going from version 1 to version 2. It's not like the new framework[1] that's replaced React. /s 1: https://github.com/developit/preact https://github.com/developit/preact
  - btdiehr 10y ago
    Except preact won't replace react.
    - spinlock 10y ago
      I'm pretty sure it already has.
hyperhopper 10y ago
Even though its deprecated, google did say Angular 1 was still supposed to be available as a fallback, and just closing issues and PRs is never correct, even if you are trying to phase it out.
- untog 10y ago
  This isn't Angular, though. It's specifically Angular Material.
iends 10y ago
By just simply closing Issues/PRs and not engaging the community better, lots of developers are going to be reluctant to invest time/effort in using Angular Material 2 due to the potential of a future Angular Material 3 surge.
- laichzeit0 10y ago
  Not just that, but if you've tried to write a serious project using Material 1 (I have), you'll know just how incomplete and feature-lacking Material 1 is. I personally would never touch Material again. Not in the next 3 years at the very minimum.
  - squeaky-clean 10y ago
    When I realized that the sidemenu on the Angular Material documentation site was not actually made with Angular Material.... that's when I realized I made a bad decision in using it.
lyschoening 10y ago
Angular Material is still missing a few essentials, but it is a good idea to speed up work on Material 2 now. Angular 2 will be out soon and many people will be unable to switch until Material 2 has caught up with the original.
- Someone 10y ago
  Doing that takes somewhat of a leap of faith. Why would one believe that, a year from now, we won't be in the situation of "Angular Material 2 is still missing a few essentials, but it is a good idea to speed up work on Material 3 now. Angular 3 will be out soon and many people will be unable to switch until Material 3 has caught up with the original." ? If one fears that, it may be better to switch to another library.
  - lyschoening 10y ago
    I am also a bit afraid about the future of Angular, primarily because the Angular team is working on way too many projects that sometimes seem needlessly complex. I don't think anyone could pick this up for Google if they dropped the ball on Angular. A hypothetical Angular 3 worries me less. The bulk of the differences between Angular 1 and Angular 2 come down to making use of technical improvements to JavaScript itself. There will be further changes in the future, but nothing as radical as modules, classes and the different asynchronous-related features. I also hope it will become somewhat easier to switch from Angular 2 to a different framework or from Material 2 to a different UI framework, because the new JavaScript language features create obvious best practice solutions where frameworks previously had to come up with their own conventions.
    - Someone 10y ago
      "There will be further changes in the future, but nothing as radical as modules, classes and the different asynchronous-related features" I expect huge changes. I foresee a future where each webpage is an almost empty <html/> tag that does little more than defining a grid that loads a big blob of WebAssembly that builds the actual 'page' (if you can still call it that by that time). One advantage would be that, say, a Python or Rust framework can run Python/Rust in the browser. Another 'advantage' would be that large companies could keep their front-end code more secret (WebAssembly obfuscates better than minifying does)
pekk 10y ago
Sounds like someone is upset their PR wasn't accepted. Poor baby.
- dang 10y ago
  Please don't do this here.
  - pekk 10y ago
    Maybe you object to the tone? There is a real community problem with sense of entitlement - just because a project is open source doesn't mean that you are entitled to have every PR accepted to that project. I'm getting tired of this kind of dirty laundry being aired publicly to shame projects into accepting PRs.
    - dang 10y ago
      Comments here need to be civil and substantive. Yours was neither. That's more than "tone". I'm sure there's a civil, substantive way to make your point.
xviia 10y ago
I have determined that relying on Google products is just a bad idea. I once included Google's V8 engine on a project I was working on. Google would regularly make breaking changes with no documentation. Developers were required to figure out the new interface on their own... occasionally you would find someone else on a forum somewhere who had reverse engineered it, saving you the time. Sure, Google can do whatever they want. They have no obligation to people using their open-source projects. But he result is that many developers will be reluctant to use those projects in the future.
- mgkimsal 10y ago
  > But he result is that many developers will be reluctant to use those projects in the future. For the short term foreseeable future, there's a continuing larger number of people coming in to the field who've not yet been burned, and will continue to choose Google libs/projects without that experience. Google doesn't seem to need to worry about burning a few bridges here and there, yet. Maybe they'll need to adapt in the next 10 years?
  - xviia 10y ago
    Google probably doesn't care whether developers use their open source projects -- they hardly make any money from it and they make 95% of their money from advertising.
- joshmanders 10y ago
  For what it's worth, they're working on changing that now that Node.js exists.
- spinlock 10y ago
  Google does expect you to put in a lot of continuing effort to use their APIs as well. I suspect this is deeply engrained in their culture.
  - xviia 10y ago
    If by "continuing effort" you mean, "parsing new errors in your build, realizing that functions you used have been removed, and finding no information on the web", then yes, I absolutely agree
gwbas1c 10y ago
I've been in a situation where I've had to regularly maintain the "new" and "old" codebase. It's not sustainable. The problem is that such a situation quickly devolves into a scenario where porting changes between the two versions of the product takes a sizable development effort. Once v2 has 2-3 major refactors, merging a change in v1 means that the change essentially has to be completely re-implemented for v2. What causes this? Basically, management thinks that "new" is just a feature bolted onto "old;" or management wants to "have its cake and eat it too." Resolving this situation requires careful planning and communication early in the project stage, before creating "new." - What are the features that can be made in isolation from "old" code, so that merging changes into "old" doesn't create lots of merge conflicts? - When is the point where we can freeze "old," so that major refactoring can happen on "new?" - What is the soonest we can move users onto "new," even if it means that we don't build all the features we need? - What parts of "new" really should be build on "old," or, what refactoring should be done on "old," so we can avoid branching issues?
deleted 10y ago
[deleted]
beeker87 10y ago
I truly feel sorry for those who started learning web development somewhere between 2009 and 2014. During that time, it seems like what would be accepted as the new standard for creating web applications was completely up for grabs. You had Angular, Backbone, Ember, and probably many others that just didn't get noticed. Can you imagine being a new developer during this time, trying to learn how to create a web application with no prior knowledge? When I started getting serious about this in 2006 or so, it was difficult enough just learning the basics of HTML, CSS, JavaScript, and how everything worked together. I have been into computers and programming my entire life, had learned C and a few other languages, and it still took me years to become an intermediate 'full-stack' developer. Again this is before any of these MVC frameworks were out. I think the main problem comes in when you try to engineer a completely new standard on top of an already existing standard. Whatever happened to using servers and browsers as they were meant to be used? Why are we constantly trying to reinvent the standard and giving these libraries which make everything more complicated attention? Is the reduction in requests to the server by having everything on client side really that beneficial with today's computing power and language capabilities (Golang http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min...)? The logic here escapes me. Angular wants you to basically use a new language and web architecture, complete with hundreds of pages of documentation specific to Angular, on top of the standard. I didn't hear about Angular Material until now, and it's even more mind boggling - are we trying to have every site look and function just like the Google platform now? There's already a standard for that - no styling on inputs (granted it will look different from browser to browser). Luckily though, after half a decade, it seems like the community has a better understanding of what would be best and the tools have been built for it. I think in the near future, we'll see Golang and React take the lead in their respective areas of web development.
- bduerst 10y ago
  2009-2014 is a huge timeframe for the web, as mobile compatibility became increasingly important. Seven years from now we'll probably be talking about how much the web changed for VR/AR - or something new altogether.
  - 10y ago
drawkbox 10y ago
When using monolithic frameworks you have to be prepared for this moment, EOLing. It suddenly just made lots of Angular 1 apps at companies not very fun to work on. It is usually around this time (EOL or new flashy framework comes out) that people see past the hype on the last one and then see all the bloat, overly verboseness, and tons of code they didn't write that they have to support now that the hype train has left. To keep projects from getting to this dungeon, better to use microframeworks while controlling your own systems and not buy into monolithic frameworks that change too much on top of the core with too much abstraction, basically vendor lock-in in a way.

121 points by skrowl 10y ago

this seems to be stardard practice at google. i've submitted tons of bugs ("issues") about app engine and compute engine, and google cloud in general, and after a month of them doing nothing, they respond with, "looks like we haven't done anything, closing"... they close it, you can't reopen. why fucking bother. just a bunch of idiots working over there padding their closed issue stats while they jerk off in larry's mouth.

franciscop 10y ago

I am the author of a slightly popular CSS library [1] and JS library [2] and I feel the pain explained here, trying to keep up the pace of issues and PR is daunting. However, cmon Google! You are not a sole developer lost somewhere in Spain. Get your act together and really support your own libraries for a sensible amount of time. Or hire more people to do so. [1] http://picnicss.com/ http://picnicss.com/ [2] http://umbrellajs.com/ http://umbrellajs.com/

user_0001 10y ago
support and google in the same sentence do not go well together
- rch 10y ago
  I'm finding I get excellent service on the products I pay for.
  - Klathmon 10y ago
    And i get wonderful support even on those I don't... I've never had a bad support experience with google, from youtube, to gmail, to google apps for work, to some issues with my adsesnse account. Do those saying they have no support ever try? There are "contact us" links everywhere for most services, and they are really damn responsive when i need to.
nixgeek 10y ago
Not sure if sarcastic or serious. It seems to me that a major problem for Open Source in 2016 is assumption of support from the originating entity or person. Does this base assumption not risk alienating individuals and organisations into saying, "Should I release this at all?". Why should they hire people to support something which generates, as far as I can see, no revenue for Google?
- deckar01 10y ago
  > Why should they hire people to support something which generates, as far as I can see, no revenue for Google? The reason most companies release projects open source for free is that they created them to solve a problem for themselves, but want to benefit from community contributions. Google's ease of abandon suggests they are not really using this library internally.
- rhizome 10y ago
  Why should they hire people to support something which generates, as far as I can see, no revenue for Google? Because it helps people use Material design. I feel this interpretation is supported by the concept of brand advertising, such as Coca Cola commercials not really having a direct effect on sales.
- franciscop 10y ago
  English is not my native language so I apologize for the misunderstanding, I didn't mean any sarcasm here. There is a big difference between releasing software "as-is", and saying - or making it look like - it will be supported for a long time: > "it was previously stated that Angular 1 will be supported for a long time to come" - Zach Bjornson Arguably, one of the main goals of Open Source is to be used. If companies that set expectations of support don't support it, then I think the future of Open Source is really doomed.

fridek 10y ago

The title is misleading, discussion linked has a clear explanation: > You are correct that many valid issues/bugs have been closed without resolution. > Our team simply does not have time to address all issues AND build Angular Material 2. (This is what we have consistently stated in our Forum posts). > We welcome community leadership with Pull Requests. Often those PRs have side affects, their scope of changes is too large, and ultimately the risk is simply too great to merge. > So we close/reject the PR... we do this to protect the existing user base. Pull Requests that have granular improvements and fixes are much easier to assess, test, and merge... and thus can be quickly merged. > Pull Requests that are submitted referencing closed issues will then trigger us to reopen those issues; until the merge is complete. > After Angular Material 2 has been released, we expect to continue to support and improve Angular Material 1 for many quarters. > Both versions are important. Both are need to support the Angular 1 and Angular 2 developers For me it's clear while the work on Material 1.x is not prioritized, it's not officially deprecated and PRs are still welcome if they are reasonable in size and impact.

cwyers 10y ago
The fact that you felt that you needed seven lines of pull-quotes to repudiate the "misleading" title is a pretty good indicator that titles are, um, titles and thus cannot carry as much information as one might want. But even after reading the material you quoted, I don't see the title of this submission as inaccurate.
- Leszek 10y ago
  I think removing the word "deprecated" would go a long way towards making the title less misleading.
  - ebbv 10y ago
    Well deprecated may not be exactly the right word, but there's not a single word that is totally accurate. Maybe "sunsetting"? :P
    - 10y ago

LOSEYOURSELF 10y ago

The old joke about sleeping through the birth, life, and death of a JS framework is still alive and well I see.

spinlock 10y ago
This is just going from version 1 to version 2. It's not like the new framework[1] that's replaced React. /s 1: https://github.com/developit/preact https://github.com/developit/preact
- btdiehr 10y ago
  Except preact won't replace react.
  - spinlock 10y ago
    I'm pretty sure it already has.

hyperhopper 10y ago

Even though its deprecated, google did say Angular 1 was still supposed to be available as a fallback, and just closing issues and PRs is never correct, even if you are trying to phase it out.

untog 10y ago
This isn't Angular, though. It's specifically Angular Material.

iends 10y ago

By just simply closing Issues/PRs and not engaging the community better, lots of developers are going to be reluctant to invest time/effort in using Angular Material 2 due to the potential of a future Angular Material 3 surge.

laichzeit0 10y ago
Not just that, but if you've tried to write a serious project using Material 1 (I have), you'll know just how incomplete and feature-lacking Material 1 is. I personally would never touch Material again. Not in the next 3 years at the very minimum.
- squeaky-clean 10y ago
  When I realized that the sidemenu on the Angular Material documentation site was not actually made with Angular Material.... that's when I realized I made a bad decision in using it.

lyschoening 10y ago

Angular Material is still missing a few essentials, but it is a good idea to speed up work on Material 2 now. Angular 2 will be out soon and many people will be unable to switch until Material 2 has caught up with the original.

Someone 10y ago
Doing that takes somewhat of a leap of faith. Why would one believe that, a year from now, we won't be in the situation of "Angular Material 2 is still missing a few essentials, but it is a good idea to speed up work on Material 3 now. Angular 3 will be out soon and many people will be unable to switch until Material 3 has caught up with the original." ? If one fears that, it may be better to switch to another library.
- lyschoening 10y ago
  I am also a bit afraid about the future of Angular, primarily because the Angular team is working on way too many projects that sometimes seem needlessly complex. I don't think anyone could pick this up for Google if they dropped the ball on Angular. A hypothetical Angular 3 worries me less. The bulk of the differences between Angular 1 and Angular 2 come down to making use of technical improvements to JavaScript itself. There will be further changes in the future, but nothing as radical as modules, classes and the different asynchronous-related features. I also hope it will become somewhat easier to switch from Angular 2 to a different framework or from Material 2 to a different UI framework, because the new JavaScript language features create obvious best practice solutions where frameworks previously had to come up with their own conventions.
  - Someone 10y ago
    "There will be further changes in the future, but nothing as radical as modules, classes and the different asynchronous-related features" I expect huge changes. I foresee a future where each webpage is an almost empty <html/> tag that does little more than defining a grid that loads a big blob of WebAssembly that builds the actual 'page' (if you can still call it that by that time). One advantage would be that, say, a Python or Rust framework can run Python/Rust in the browser. Another 'advantage' would be that large companies could keep their front-end code more secret (WebAssembly obfuscates better than minifying does)

pekk 10y ago

Sounds like someone is upset their PR wasn't accepted. Poor baby.

dang 10y ago
Please don't do this here.
- pekk 10y ago
  Maybe you object to the tone? There is a real community problem with sense of entitlement - just because a project is open source doesn't mean that you are entitled to have every PR accepted to that project. I'm getting tired of this kind of dirty laundry being aired publicly to shame projects into accepting PRs.
  - dang 10y ago
    Comments here need to be civil and substantive. Yours was neither. That's more than "tone". I'm sure there's a civil, substantive way to make your point.

xviia 10y ago

I have determined that relying on Google products is just a bad idea. I once included Google's V8 engine on a project I was working on. Google would regularly make breaking changes with no documentation. Developers were required to figure out the new interface on their own... occasionally you would find someone else on a forum somewhere who had reverse engineered it, saving you the time. Sure, Google can do whatever they want. They have no obligation to people using their open-source projects. But he result is that many developers will be reluctant to use those projects in the future.

mgkimsal 10y ago
> But he result is that many developers will be reluctant to use those projects in the future. For the short term foreseeable future, there's a continuing larger number of people coming in to the field who've not yet been burned, and will continue to choose Google libs/projects without that experience. Google doesn't seem to need to worry about burning a few bridges here and there, yet. Maybe they'll need to adapt in the next 10 years?
- xviia 10y ago
  Google probably doesn't care whether developers use their open source projects -- they hardly make any money from it and they make 95% of their money from advertising.
joshmanders 10y ago
For what it's worth, they're working on changing that now that Node.js exists.
spinlock 10y ago
Google does expect you to put in a lot of continuing effort to use their APIs as well. I suspect this is deeply engrained in their culture.
- xviia 10y ago
  If by "continuing effort" you mean, "parsing new errors in your build, realizing that functions you used have been removed, and finding no information on the web", then yes, I absolutely agree

gwbas1c 10y ago

I've been in a situation where I've had to regularly maintain the "new" and "old" codebase. It's not sustainable. The problem is that such a situation quickly devolves into a scenario where porting changes between the two versions of the product takes a sizable development effort. Once v2 has 2-3 major refactors, merging a change in v1 means that the change essentially has to be completely re-implemented for v2. What causes this? Basically, management thinks that "new" is just a feature bolted onto "old;" or management wants to "have its cake and eat it too." Resolving this situation requires careful planning and communication early in the project stage, before creating "new." - What are the features that can be made in isolation from "old" code, so that merging changes into "old" doesn't create lots of merge conflicts? - When is the point where we can freeze "old," so that major refactoring can happen on "new?" - What is the soonest we can move users onto "new," even if it means that we don't build all the features we need? - What parts of "new" really should be build on "old," or, what refactoring should be done on "old," so we can avoid branching issues?

deleted 10y ago

[deleted]

beeker87 10y ago

I truly feel sorry for those who started learning web development somewhere between 2009 and 2014. During that time, it seems like what would be accepted as the new standard for creating web applications was completely up for grabs. You had Angular, Backbone, Ember, and probably many others that just didn't get noticed. Can you imagine being a new developer during this time, trying to learn how to create a web application with no prior knowledge? When I started getting serious about this in 2006 or so, it was difficult enough just learning the basics of HTML, CSS, JavaScript, and how everything worked together. I have been into computers and programming my entire life, had learned C and a few other languages, and it still took me years to become an intermediate 'full-stack' developer. Again this is before any of these MVC frameworks were out. I think the main problem comes in when you try to engineer a completely new standard on top of an already existing standard. Whatever happened to using servers and browsers as they were meant to be used? Why are we constantly trying to reinvent the standard and giving these libraries which make everything more complicated attention? Is the reduction in requests to the server by having everything on client side really that beneficial with today's computing power and language capabilities (Golang http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-golang/ http://marcio.io/2015/07/handling-1-million-requests-per-min...)? The logic here escapes me. Angular wants you to basically use a new language and web architecture, complete with hundreds of pages of documentation specific to Angular, on top of the standard. I didn't hear about Angular Material until now, and it's even more mind boggling - are we trying to have every site look and function just like the Google platform now? There's already a standard for that - no styling on inputs (granted it will look different from browser to browser). Luckily though, after half a decade, it seems like the community has a better understanding of what would be best and the tools have been built for it. I think in the near future, we'll see Golang and React take the lead in their respective areas of web development.

bduerst 10y ago
2009-2014 is a huge timeframe for the web, as mobile compatibility became increasingly important. Seven years from now we'll probably be talking about how much the web changed for VR/AR - or something new altogether.
- 10y ago

drawkbox 10y ago

When using monolithic frameworks you have to be prepared for this moment, EOLing. It suddenly just made lots of Angular 1 apps at companies not very fun to work on. It is usually around this time (EOL or new flashy framework comes out) that people see past the hype on the last one and then see all the bloat, overly verboseness, and tons of code they didn't write that they have to support now that the hype train has left. To keep projects from getting to this dungeon, better to use microframeworks while controlling your own systems and not buy into monolithic frameworks that change too much on top of the core with too much abstraction, basically vendor lock-in in a way.