Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Angular Material 1 will enter a maintenance mode

groups.google.com

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Angular Material 1 will enter a maintenance mode

#21

Post by mgkimsal »

xviia wrote: post #19

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…

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

Re: Angular Material 1 will enter a maintenance mode

#22

Post by Someone »

lyschoening wrote: post #13

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.

Re: Angular Material 1 will enter a maintenance mode

#23

Post by xviia »

mgkimsal wrote: post #21
xviia wrote: post #19

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…

> 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…

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.

Re: Angular Material 1 will enter a maintenance mode

#24

Post by 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?

Re: Angular Material 1 will enter a maintenance mode

#25

Post by laichzeit0 »

iends wrote: post #12

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.

Re: Angular Material 1 will enter a maintenance mode

#26

Post by joshmanders »

xviia wrote: post #19

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…

For what it's worth, they're working on changing that now that Node.js exists.

Re: Angular Material 1 will enter a maintenance mode

#28

Post by dang »

fridek wrote: post #10
cwyers wrote: post #7

Earlier quoted context omitted.

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.

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

Re: Angular Material 1 will enter a maintenance mode

#29

Post by spinlock »

xviia wrote: post #19

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…

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.

Re: Angular Material 1 will enter a maintenance mode

#30

Post by spinlock »

LOSEYOURSELF wrote: post #5

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

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

Post reply on HN