Angular 2 first impression
-
It's the fact that the reality of web development is that you have to keep your site compatible with the march of progress in browser-land. This is new effort that comes with the decision of building a product as a web-based product.
Except this doesn't happen unless your application is tied to a specific browser usually older versions of IE. If your application was built using the standard APIs that are defined in the specs you don't run into these problems.
-
@lucas1 said in Angular 2 first impression:
@Vaire well you guys forgot how fucking bad 3.6 was to use. It was broken 4 was better but with some fucking horrendous bugs. I like the quick releases.
I forget NOTHING. It stays up there...
-
@lucas1 said in Angular 2 first impression:
@Vaire said in Angular 2 first impression:
Why keep adding crap nobody asked for (like a fucking chat client!) and CONSTANTLY changing the ui?
Just fecking remove it from the bar like you always have been able to.
It would still be there, in the code tubes ... waiting ... watching ... silently judging
-
@Jaime said in Angular 2 first impression:
@Vaire said in Angular 2 first impression:
Meh, working for a Fortune 20 company here, they simply do not care what is "rational."
My story was from my time at a Fortune 20 too. 5% chance it was the same place. Healthcare?
I have narrowed it down to 20 possibilities. Not going to narrow it down any more. MOST people here are cool, but obviously the higher up the chain of command one goes, the less cool they are about being talked about on the "int3rw3bS" unless it is words they put into the PR drones' mouths. We have an official company policy and everything about it, and they send a reminder every quarter
-
@lucas1 said in Angular 2 first impression:
Except this doesn't happen unless your application is tied to a specific browser usually older versions of IE. If your application was built using the standard APIs that are defined in the specs you don't run into these problems.
So, you're saying that Chrome 32 didn't break the Internet?
-
@Jaime Oh comon that is a Chrome on Windows bug. Not a browser feature defect which was your complaint.
They are two very different things.
-
@lucas1 That's a "I chose to use the web as a platform for my application and it failed me" problem. Sure it was only two versions of a single OS and one browser, but it affected like 20% of the Internet population.
Detection is irrelevant because all along my problem hasn't been supporting the feature set of current browsers, it's been the problem that browsers change after you've deployed. Here's the relevant quote from where I joined this conversation:
@Jaime said in Angular 2 first impression:
new incompatibilities are pretty much guaranteed to continue popping up several times a year forever
-
Detection is irrelevant because all along my problem hasn't been supporting the feature set of current browsers, it's been the problem that browsers change after you've deployed. Here's the relevant quote from where I joined this conversation:
And the relevant quote is nonsense as I have previously explained. Almost all features are additions and very few depreciations. If you write a web applications that conform to standards there will be very few problems.
A bad chrome release will be fixed, and has nothing to do with how you build an application in terms of detecting apis and dealing with the lack of them correctly.
-
@Jaime said in Angular 2 first impression:
new incompatibilities are pretty much guaranteed to continue popping up several times a year forever
Stop using vendor-specific shit then
-
@RaceProUK said in Angular 2 first impression:
Stop using vendor-specific shit then
The Chrome 32 bug I mentioned happened on a vanilla
SELECTtag. That's far from the only example of browser behavior changing in a breaking way.
-
@Jaime said in Angular 2 first impression:
@RaceProUK said in Angular 2 first impression:
Stop using vendor-specific shit then
The Chrome 32 bug I mentioned happened on a vanilla
SELECTtag. That's far from the only example of browser behavior changing in a breaking way.Which is irrelevant to the conversation because it isn't an "incompatibility". It's a bug.
Or are you telling me the Chrome team intentionally broke compatibility with
<select>tags?
-
@Jaime It still has nothing to do with detecting browser features FFS, you are conflating two entirely different concepts.
-
@sloosecannon I'm telling you that I had to write yet another workaround so that my customers could use my shit.
-
@Jaime Well, if we're going to stop using something because there's a bug in it, then I guess we'd better get rid of Chrome. Oh, and Firefox, Opera, IE, Edge, Safari, Maxthon, and all those others. Guess we'd better get rid of Apache, IIS, and nginx too. Oh, and we can't forget about dropping .NET and Java and the C Runtime. Oh, and Windows and Linux and OSX and Android and iOS, of course.
-
@lucas1 said in Angular 2 first impression:
It still has nothing to do with detecting browser features FFS, you are conflating two entirely different concepts.
I never mentioned feature detection. You grabbed on to it and won't let go.
-
@Jaime said in Angular 2 first impression:
@sloosecannon I'm telling you that I had to write yet another workaround so that my customers could use my shit.
Or just say "It's a known Chrome bug. It will be fixed soon. Please use another browser in the site for now. See bug db here: link". CLOSED_NOT_MY_BUG."
Of course, now, you've introduced a hacky workaround for a bug that's almost certainly been fixed by now, so you've got more code to maintain, etc.
-
@Jaime You specifically talked about your application not working with IE10, and this I bet would have been because it was using specific JS APIs only available in IE9 and lower. So yes feature detection was broken in your application
-
@RaceProUK said in Angular 2 first impression:
Well, if we're going to stop using something because there's a bug in it
Yes, this is a dichotomy - either accept all bugs or sit in the corner and cry.
My point is that these things come up more often in web development. You feedback that I have to suck it up and deal with it is irrelevant.
-
@lucas1 said in Angular 2 first impression:
You specifically keep on using the term and originally mentioned it.
Nope. I provided my original quote. Fuck off.
-
@Jaime I've corrected my statement as I went back to check. But my points still stands because your web application didn't do feature detection correctly.
How about you get bent because you obviously have no idea what the fuck you are talking about.
-
@Jaime I'm not surprised that someone who's scared of using standardised techniques because there might be a bug at some point would completely miss the point of my post.
-
@Jaime said in Angular 2 first impression:
@RaceProUK said in Angular 2 first impression:
Well, if we're going to stop using something because there's a bug in it
Yes, this is a dichotomy - either accept all bugs or sit in the corner and cry.
My point is that these things come up more often in web development. You feedback that I have to suck it up and deal with it is irrelevant.
Our (well, my) point is that this isn't a breaking change or an incompatibility. It's a major, high priority bug, that happened to make it to a stable release. This should be an exception to the rule and you shouldn't have to code changes for it, because that's not your job. It's the Chromium team's job.
A breaking change or incompatibility would be
<a>tags no longer supporthref="", it must be changed tolink=""per standards change. Which is the kind of thing that never happens precisely because it would break everything.
