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.
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.
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.
> 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.
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.
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.
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.
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.
That's essentially what deprecated means. It is discouraged to start new projects with it. It doesn't mean that it's dead, but we seem to always take it that way.
Deprecated implies "will stop being supported soon, so you should stop using it as soon as you can". Maintenance mode implies "will continue to be supported for critical things like security fixes, but won't get new features, so there is no hurry to stop using it if you are fine with it staying in its current form forever".
Actually deprecated implies a deprecation timeline, which can be on the order of years.
Python 2 was deprecated when Python 3 was released, but the timeline of transition was over 10+ years.
Django has deprecation timelines that last over 1.5 years.
In Enterprise, its often seen to have deprecation last 7 years.
During deprecation, only maintenance is performed. That is---security fixes.
The real difference between deprecation and "maintenance mode" is that the later is indefinite and implies continuation until profit-loss. AWSv2 isn't in maintenance mode, its deprecated. Eventually Amazon may stop offering it, and doesn't want you to start using it, but while its in operation that doesn't mean they won't close security holes in services that offer it.
Well, how about using the original title - "Surge Focus on Material 2"? It seems more appropriate as nothing in the discussion included a notice on deprecating the 1.x branch.
Since people are concerned with Material 1, we've replaced the title with what seems to be the most representative phrase from the article about Material 1. I couldn't fit in the bit about bugs in the 80 char limit.
(Submitted title was "Google deprecating Angular 1.x Material library and is just closing issues and PRs", which was wrongly editorialized, since the article apparently doesn't say they're 'deprecating' the library, and 'just' is just spin. Submitters: please don't rewrite titles to put your spin on a topic, especially not to gin up controversy. If a title is misleading or linkbait, it's ok to rewrite it (see the HN guidelines), but the new title needs to be accurate and neutral, and should preferably use representative language from the article itself.)
I understand closing PRs if they're complicated and out of scope, but closing issues doesn't make sense. These bugs don't go away just because the primary developers are leaving.
Closed issues don't go away. Lots of bugs are edge conditions that not enough people care about for the developers to ever pay any attention to fixing. They fall under the category of "sure, and if you submit a PR, we'll merge it". I imagine there's also issues for architectural problems with 1.x which will never, ever get fixed because nobody will be willing to spent the time massively refactoring the codebase. From a developer perspective its pointless to keep those open.
How you feel about this probably depends on if you're a user or developer. If you're a developer you view the issue tracker as a TODO list. If you're literally never going to bother fixing an issue, its best to just close it and move on.
Users seem to view issue trackers as defect trackers and believe that bugs should stay open until they're fixed.
If active project are always supposed to be closing, then deprecated 1.x branches of projects should have an even higher bar for anything they keep around open.
I apologize, but there's only so much you can do in 80 character titles. It was not my intention to be unclear.
When you:
* Move all of your developers / resources from Project A to Project B
* On the page for Project A you state "Project A development efforts are focused on bug fixes and minor improvements."
* THEN you go and close a bunch of valid even minor / easily fixed bugs (ex https://github.com/angular/material/issues/1659) and PRs stating "This issue is closed as part of our Project B efforts."
...it's my opinion that Project A is now deprecated, even if they don't expressly state that it is.
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.
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.
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.
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.
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.
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.
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.
"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)
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.
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.
> 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?
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.
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
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?
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-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.
I think the transition could have been much smoother and did not require engineering a new MVC framework on top of an already existing MVC framework. The only thing needed to make a page mobile ready is responsive CSS. What is more of a concern for mobile, and especially was back in 2009, is how much processing power a page needs to render and function fluidly.
The truth is React isn't doing anything that requires new technology, it could've been built in the early 2000's. I guess ideas like Angular taking off are just the natural way of things when you have a big company supporting it. It goes to show though that even the largest companies on the planet sometimes get it wrong (but also get many things right, Google with Golang and Facebook with React). Did it really take 4-5 other inferior frameworks though to see the simplistic idea behind React and build it out? If so, people who see these bad practices happening and are capable of doing something about it should do so immediately, for the sake of the development community.
>are we trying to have every site look and function just like the Google platform now?
The internet would be a thousand times better if every website used Material Design properly. The amount of broken and poorly designed bullshit out there is staggering. Websites worth tens or hundreds of millions of dollars flat out not working. Or working so slowly they may as well just not work. Even the ones that wind up working, they have horrific UI/UX decisions.
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.
55 comments
[ 4.8 ms ] story [ 121 ms ] threadHowever, 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/
[2] http://umbrellajs.com/
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.
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?
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.
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.
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.
> 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.
Python 2 was deprecated when Python 3 was released, but the timeline of transition was over 10+ years.
Django has deprecation timelines that last over 1.5 years.
In Enterprise, its often seen to have deprecation last 7 years.
During deprecation, only maintenance is performed. That is---security fixes.
The real difference between deprecation and "maintenance mode" is that the later is indefinite and implies continuation until profit-loss. AWSv2 isn't in maintenance mode, its deprecated. Eventually Amazon may stop offering it, and doesn't want you to start using it, but while its in operation that doesn't mean they won't close security holes in services that offer it.
(Submitted title was "Google deprecating Angular 1.x Material library and is just closing issues and PRs", which was wrongly editorialized, since the article apparently doesn't say they're 'deprecating' the library, and 'just' is just spin. Submitters: please don't rewrite titles to put your spin on a topic, especially not to gin up controversy. If a title is misleading or linkbait, it's ok to rewrite it (see the HN guidelines), but the new title needs to be accurate and neutral, and should preferably use representative language from the article itself.)
Not sure if that helps that much though.
How you feel about this probably depends on if you're a user or developer. If you're a developer you view the issue tracker as a TODO list. If you're literally never going to bother fixing an issue, its best to just close it and move on.
Users seem to view issue trackers as defect trackers and believe that bugs should stay open until they're fixed.
https://blog.jessfraz.com/post/the-art-of-closing/
If active project are always supposed to be closing, then deprecated 1.x branches of projects should have an even higher bar for anything they keep around open.
When you:
* Move all of your developers / resources from Project A to Project B
* On the page for Project A you state "Project A development efforts are focused on bug fixes and minor improvements."
* THEN you go and close a bunch of valid even minor / easily fixed bugs (ex https://github.com/angular/material/issues/1659) and PRs stating "This issue is closed as part of our Project B efforts."
...it's my opinion that Project A is now deprecated, even if they don't expressly state that it is.
1: https://github.com/developit/preact
"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.
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.
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)
I'm sure there's a civil, substantive way to make your point.
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.
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?
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?
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-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.
Seven years from now we'll probably be talking about how much the web changed for VR/AR - or something new altogether.
The truth is React isn't doing anything that requires new technology, it could've been built in the early 2000's. I guess ideas like Angular taking off are just the natural way of things when you have a big company supporting it. It goes to show though that even the largest companies on the planet sometimes get it wrong (but also get many things right, Google with Golang and Facebook with React). Did it really take 4-5 other inferior frameworks though to see the simplistic idea behind React and build it out? If so, people who see these bad practices happening and are capable of doing something about it should do so immediately, for the sake of the development community.
The internet would be a thousand times better if every website used Material Design properly. The amount of broken and poorly designed bullshit out there is staggering. Websites worth tens or hundreds of millions of dollars flat out not working. Or working so slowly they may as well just not work. Even the ones that wind up working, they have horrific UI/UX decisions.
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.