International “Break The Web Forward” Day(breakthewebforward.com)
breakthewebforward.com
International “Break The Web Forward” Day
http://breakthewebforward.com
6 comments
Y2K was a specific class of bugs, which was easy to define and focus on. I'm afraid "things that are there for backwards-compat and have been deprecated by standards" is quite a bit more vague.
Of course, if this movement took off, I would absolutely want to come up with a defined list/scope for our efforts.
I love the implicit assumption that the standards-of-the-moment are any better. The only useful current HTML standard is "does it render in webkit." I can't even count the number of websites that can't render at all on devices even a year or two old (looking at you, Forbes).
This whole 'effort' is moot since web practice veers so quickly that we'll be back in the same boat by 2020.
This whole 'effort' is moot since web practice veers so quickly that we'll be back in the same boat by 2020.
> I love the implicit assumption that the standards-of-the-moment are any better.
Of course they are objectively "better" (by almost any measure) than the mixed old-and-new-that-conflict crap we have.
Is the "new new" we have bettter than the "old new" we had back then? Who cares? That's an institutional question about standards in general.
I'm focused on a very different problem: how we as an industry react to the standards. Currently, we always pile up extra tech debt and almost never (not never, but very rarely) accept the pain of kicking out the really old.
> This whole 'effort' is moot since web practice veers so quickly
I'm not suggesting it's a one-time fix. It might have to happen once a decade, or once every 20 years.
BUT, I think there's a good amount of evidence to suggest this idea could achieve more positive forward motion than it might've in years' past.
Namely, the fact that all modern desktop browsers are on a drastically more rapid update cycle than we were in back when much of this tech debt was accrued (circa 2005). The quicker browsers auto-upgrade, the less likely we are to have widespread "adoption" of bugginess that sets in and becomes permafrost on our industry.
If we fix mistakes quickly, and often, it continues to spur companies to keep their apps fresh and updated.
Is it a perfect solution? Hell no. But I think it's better than what we've got now, which is to say, "approximately nothing."
Of course they are objectively "better" (by almost any measure) than the mixed old-and-new-that-conflict crap we have.
Is the "new new" we have bettter than the "old new" we had back then? Who cares? That's an institutional question about standards in general.
I'm focused on a very different problem: how we as an industry react to the standards. Currently, we always pile up extra tech debt and almost never (not never, but very rarely) accept the pain of kicking out the really old.
> This whole 'effort' is moot since web practice veers so quickly
I'm not suggesting it's a one-time fix. It might have to happen once a decade, or once every 20 years.
BUT, I think there's a good amount of evidence to suggest this idea could achieve more positive forward motion than it might've in years' past.
Namely, the fact that all modern desktop browsers are on a drastically more rapid update cycle than we were in back when much of this tech debt was accrued (circa 2005). The quicker browsers auto-upgrade, the less likely we are to have widespread "adoption" of bugginess that sets in and becomes permafrost on our industry.
If we fix mistakes quickly, and often, it continues to spur companies to keep their apps fresh and updated.
Is it a perfect solution? Hell no. But I think it's better than what we've got now, which is to say, "approximately nothing."
Disagree. This movement is tantamount to saying "web developers time is worth more than your money, so throw away anything you have that does not conform to whatever the hell we're interested in as of 01JAN2018."
The world has too many millions of older devices with older browsers embedded to take this seriously. It will always be cheaper to hire web programmers willing to make shit that works than it will be to discard entire classes of device every few years.
The world has too many millions of older devices with older browsers embedded to take this seriously. It will always be cheaper to hire web programmers willing to make shit that works than it will be to discard entire classes of device every few years.
For better or worse, the fact that there has never been an HTML flag day is what made the Web this successful.
Sure. But the web is well past its infancy, its hype curve, etc. It doesn't need "help" to find adoption. It made it.
Now it's time for maturity, in my opinion. I just think this is one way of going about shuffling off some of the old baggage (that admittedly got us here).
Now it's time for maturity, in my opinion. I just think this is one way of going about shuffling off some of the old baggage (that admittedly got us here).
Is it really worth breaking all legacy websites?
The most important thing to do is to ensure that people use new solutions.
Wouldn't it be nice if there was an HTML5 only mode in your browser and it would ignore legacy tags?
The most important thing to do is to ensure that people use new solutions.
Wouldn't it be nice if there was an HTML5 only mode in your browser and it would ignore legacy tags?
We've tried "document modes" before, and it was terrible. And it's even worse for JS and CSS.
> Is it really worth breaking all legacy websites?
In any organization, this question gets asked of their product's technical debt, many times over, and gets many "no" answers, until finally there's too much, and their "technical bankruptcy" is unavoidable. They suffer the (temporary) pains to deal with some or all of that debt, and get back on track.
I'm just wishing we could treat our industry that way. I think we're "there" at that point of decision. I just want to tip us over the edge into admitting it.
> Is it really worth breaking all legacy websites?
In any organization, this question gets asked of their product's technical debt, many times over, and gets many "no" answers, until finally there's too much, and their "technical bankruptcy" is unavoidable. They suffer the (temporary) pains to deal with some or all of that debt, and get back on track.
I'm just wishing we could treat our industry that way. I think we're "there" at that point of decision. I just want to tip us over the edge into admitting it.
People use legacy solutions because they work.
If tutorials started with while you are developing set your browser to developer mode which only allow HTML5 tags to be used.
Web developers copy code, that is one of the reasons the web is so great.
But if they copy code and it works they will move on without realizing that they are using deprecated tags.
If tutorials started with while you are developing set your browser to developer mode which only allow HTML5 tags to be used.
Web developers copy code, that is one of the reasons the web is so great.
But if they copy code and it works they will move on without realizing that they are using deprecated tags.
Yes, "how we get into this mess" is incredibly complicated and yet far too much a "pit of failure" for developers.
But that doesn't mean we have to just accept it'll never change.
I take a sense of pride and ownership in the web, and I have big hopes for its future. That means I have to want to try to make it better, not just keep it afloat. I just hope I can inspire others to do the same.
But that doesn't mean we have to just accept it'll never change.
I take a sense of pride and ownership in the web, and I have big hopes for its future. That means I have to want to try to make it better, not just keep it afloat. I just hope I can inspire others to do the same.
I like the idea. I don't like the proposed date. I have plans.
What's a date you're free? :)
January 2, 2018. :)
I played with binary representations of unix timestamps for a minute in an attempt to locate a date that is also a "nice round number", but didn't come up with anything striking.
I played with binary representations of unix timestamps for a minute in an attempt to locate a date that is also a "nice round number", but didn't come up with anything striking.
As soon as I get a a github repo for this thing, I'll happily accept your PR to change to 01/10/11111100010. :)
Any specifics that you are thinking of here?
In particular, lots of legacy JS bugs that we can't get rid of since people "rely" on them. Also, the biggest one that spurred me to launch this today is all the proprietary -webkit- CSS prefix stuff, especially the non-standard stuff everyone is relying upon in mobile!