
Angular Material 1 will enter a maintenance mode - skrowl
https://groups.google.com/forum/#!topic/ngmaterial/4ActiQp3nA0
======
fridek
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
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.

~~~
fridek
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.

~~~
dang
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.)

~~~
mst
Given the exact words of the post, I'd've added "for Q3", since they didn't
say the maintenance mode is permanent.

Not sure if that helps that much though.

------
xviia
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
> 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
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.

------
iends
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
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
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.

------
franciscop
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/)

~~~
nixgeek
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
> 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.

------
beeker87
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...](http://marcio.io/2015/07/handling-1-million-requests-per-minute-with-
golang/))? 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
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.

~~~
beeker87
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.

------
gwbas1c
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?

------
hyperhopper
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
This isn't Angular, though. It's specifically Angular Material.

------
drawkbox
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.

------
lyschoening
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
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
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
_" 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)

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

~~~
spinlock
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
Except preact won't replace react.

~~~
spinlock
I'm pretty sure it already has.

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

~~~
dang
Please don't do this here.

~~~
pekk
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
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.

