

International “Break The Web Forward” Day - _getify
http://breakthewebforward.com

======
saosebastiao
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.

~~~
_getify
Of course, if this movement took off, I would absolutely want to come up with
a defined list/scope for our efforts.

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

~~~
_getify
> 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."

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

------
gioele
For better or worse, the fact that there has never been an HTML flag day is
what made the Web this successful.

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

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

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

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

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

------
daveloyall
I like the idea. I don't like the proposed date. I have plans.

~~~
_getify
What's a date you're free? :)

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

~~~
_getify
As soon as I get a a github repo for this thing, I'll happily accept your PR
to change to 01/10/11111100010\. :)

------
richbradshaw
Any specifics that you are thinking of here?

~~~
_getify
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!

