So far most of the courses have been pretty decent.  However, the projects are a different story.  The first one I did was fine - not particularly enlightening, but OK.  The second one, the Go CLI playbook, to be perfectly frank, is garbage.  At least, the first module is garbage.  I can't really speak to the rest because I can't get past the first module.

Now, in my own defense, it's not like the first module is hard.  In fact, it's completely trivial.  It basically comes down to "run go env > module1.txt ; go env -json > module1.json and then submit the result.  It even comes with a test file you can run locally.  So far so good.

The problem is, it doesn't work on Windows.  Like, doesn't work at all.  For starters, if you're running Powershell, output redirected to a file defaults to UTF-16 encoding, which is standard for Windows, but not for Go apparently.  Second, the go env command generates environment variables in an OS-specific format.  On Windows, that means it generates a file that can be consumed by cmd.exe.  Which is fine, except the project test file blithely assumes that the environment file is going to be in UNIX shell format, so the "set" at the start of each line makes it choke.

Well, that sucks.  Guess I'll just use WSL.  When I run the commands there and run the tests, they pass.  Great!  Let's upload the result and get on with our lives.  Except that doesn't work, because the tests fail when run in PluralSight's validator.  I don't know why.  My best guess is that something in the upload process is mangling the encoding.  I do know that it apparently doesn't run the test file you upload, so you can't hack around whatever the bug is.

The worst part is that you can't progress to the rest of the project until you "pass" that section.  So I'm pretty much just out of luck.  Maybe the rest of the course has some great material.  Or maybe it's equally useless.  Who knows?  Maybe it's just this project - so far the others I've tried have been OK.  Although I did have one other module where all the tests passed locally, but failed on upload.  But in that case, I at least had a legitimate bug in my code.  Why the tests passed locally is a different problem, though....

I mean...yeah.  But it's not like this is news.  The Node ecosystem has been messed up for years.  Remember the left-pad debacle?  That was five years ago.  It's pretty clear that the ecosystem was messed up then.  So I guess this article just tells us that not much has changed.

To be fair, a lot of the stuff Jared complains about isn't really specific to the JavaScript ecosystem.  I've also been in the industry for 20 years and I can say from experience that bugs and hype are endemic to most of the industry and have been for quite some time.  For example, in the early days of Rails, I remember seeing a million variations on the "build your own blog in 10 minutes with Ruby on Rails" tutorials.  And yes, that's fine, you can make a simple demo app in 10 minutes.  Whoop-de-doo.  In reality, what that usually means is that on a two-month project you've saved yourself...maybe a day or two at most.  There are lots of tools and framework in lots of language ecosystems that are grossly over-hyped - it's almost standard practice in the industry.

As for bugs, I can't speak to Jared's experience.  In any software ecosystem, bugs are obviously common and not mentioning them is almost de rigueur.  I mean, if you're developing a framework or library, of course you're not going to advertise the bugs and limitations of your tool.  You want people to use it, not be scared away.  But I'm willing to accept Jared's assertion that the JavaScript world is uniquely bad.  I know my experience of client-side JS libraries is...not fantastic in terms of reliability or documentation.  So while I'm not sure he's right, I wouldn't be surprised if he was.

I do think his point about the learning curve is interesting and valid, though I don't know that it relates specifically to bugs.  I haven't gotten deep into many of the fancy new JavaScript frameworks, but they do seem to be staggeringly complex.  I started working with JavaScript way back in 2005, when all you needed to do what save your code in a text file, open that file up in a browser, and see what it did.  It was extremely simple and the bar to entry was ridiculously low.  Then, a few years ago, I decided to try out React, since that's the big new thing.   Just to do "Hello, World!", I had to get my head around their weird template syntax, install a transpiler, and run some kind of server process (I don't even remember - maybe that's changed by now).  And when I saw that work, I quit because I had actual work to do.  It's hard for me to remember what it was like to be a beginner, but I can imagine that this kind of an on-ramp would be pretty daunting, even with the dumbed-down tutorials.  Heck, it seemed like kind of a lot to me, and I'm an experienced professional!

Honestly, I kind of wonder how much of the problems Jared is seeing stem from the "youth" of the JavaScript ecosystem.  I'm not talking about the language, of course.  I'm thinking more of the historical and cultural part of the ecosystem.  Consider:

1. While JavaScript has been around for a 25 years, it was widely considered a "toy" language for the first 10 years or so.  Remember - JavaScript came out in 1995, but jQuery didn't come along until 2005.  And these days, building your site on jQuery is the equivalent of building your house out of mud and sticks.
2. In the roughly 15 years of JavaScript's non-toy lifespan, there's been a lot of churn in the web space.  And during much of that time, it was considered important for many businesses to support legacy web browsers.  I remember many times having to stop myself from using "new" features of JavaScript because, well, we still have to support old versions of Internet Explorer.  Yeah, nobody cares about that anymore (thank God), but it wasn't all that long ago that they did.  Heck, I remember getting yelled at in 2015 because I forgot to test something in IE9, which was released in 2010!
3. From 1 and 2 above, it's clear that, in terms of the evolution of the ecosystem, the 25 year history of JavaScript is really a lot less than 25 years.  In fact, it's probably only within the last five years or so that we've managed to shake off most of the legacy cruft and get adoption of modern stuff beyond the handful of early-adopters.
4. On the cultural front, it's been my experience that a lot of young people these days get into coding through web development.  This is not a bad thing - everybody has to start somewhere and the web is a relatively accessible and popular medium.  But it's also my experience that a lot of the people who create open-source tools and libraries are younger, because they're less likely to have families and other obligations and hence more likely to have the free time.  Again, this is not bad, but it means that the people writing the tools are disproportionately likely to be less experienced.
5. So while there are plenty of things in the JavaScript world that are old enough that they should be mature, we can see from 3 and 4 that this might not necessarily be the case.  When a tool is developed by relatively inexperienced coders and hasn't been widely used outside a relatively small circle for very long, it shouldn't come as a surprise when they have some issues.

Of course, I'm just spit-balling here - I could be completely wrong.  But the point is that developing a stable ecosystem takes time, and the JavaScript ecosystem hasn't actually had as much real time to develop as the calendar suggests.  I mean, there's still a hot new framework coming out every other week, so it doesn't seem like the ecosystem has even finished stabilizing yet.  Maybe in a few years things will settle down more and quality will improve.

Or maybe not.  We'll see.  In the mean time, we just have to make do with what we have.

Specifically, I got a pair of PowerBlock Elite EXP dumbbells.  These things may look like toasters, but they're actually adjustable dumbbells that can go from 5 to 50 pounds in 2.5 to 5 pound increments.  The big selling point is that they adjust quick  You can do 10 pound adjustments just by moving a pin, which is super fast.  The 2.5 and 5 pound increments are little more involved, as those are adjusted by removing weight cylinders from the handles, and you can't do all increments, but it's still just pulling the pin, flipping a lever, and dropping a cylinder in or out.

Compare this to my old set of dumbbells, which adjusts up to 52.5 pounds.  It adjusts in 2.5 pound increments (and does all of them), but does it by swapping out plates and securing them using a screw clamp.  It works fine, but it's slow.  So, for instance, my current program has a bunch of supersets in it, and for most of them I'm using different weights for each of the two exercises.  So the "go immediately into the second exercise" was actually more like "spend about a minute changing the weights and then go straight into the next exercise".  Clearly this is not ideal in terms of executing the program, and it also stretches out the workout.

I'm pretty happy with them.  They took a little getting used to, but after using them for a week or two they work pretty well.  My main complaint is that the instructions were a little iffy.  It took me a little playing around to figure out exactly how to put in the pin, which direction things went, and so forth.  But it's not complicated, so it just took a few minutes of messing around.

On the down side, Amazon is now sending me suggestions for the thing I just bought.  They did the same thing when I bought my new laptop on Prime day.

I'm sure at some point Amazon will fix this, but it doesn't exactly say much for their recommendation AI.  I mean, this recommendation is a different model and a lighter weight, so it's not exactly the same thing, but come on.  Can one of the biggest tech companies in the world, with huge amounts of computing power and legions of brilliant people devoted to building their recommendation systems, really not figure out that I don't need to buy a slightly different version of the thing I just bought from them?  

I don't know - maybe there's a good reason for that and I just don't know enough about Amazon and/or machine learning.  It's just a really annoying thing that seems like it should be an obvious thing to fix.  Heck, I would imagine that the machine learning systems might even pick up on that on its own.  I mean, do people who buy a thing really buy it again a week later that often?  I'd think those numbers are all fed into the recommendation system and that they'd be low enough that the algorithm would drop recent purchases (especially larger ones) off the recommendations.

Then again, maybe the algorithm knows something I don't.  Maybe people re-buy the same thing all the time.  It could be they even do that with items that cost hundreds of dollars.  I doubt it.  But what do I know?

As I'd written in a previous post, this was kind of confusing to me.  I mean, I got the technical aspect - that an NFT is a blockchain transaction that's tied to some file that lives outside the chain.  So you have an immutable record that the transaction happened, which is good.  But when you read about people paying hundreds of thousands, or even millions of dollars for an NFT, what did they actually get for that money?

The short answer is: it depends.

It looks like, legally speaking, it depends on the terms of the sale agreement.  It's possible that a high-priced NFT was purchased under an agreement that transfers full ownership and copyright rights to the purchaser.  However, it's also possible that all they got was that transaction on the blockchain.

It seems like the default is that buying an NFT is like buying a collectible, but in digital form.  Think of, say, a limited-edition collectible like a toy, coin, or something similar that comes with some sort of certificate of authenticity.  When you buy it, you get the physical item, but you also get documentation with some sort of serial number and proof that that specific item was sold to you.  Having that kind of provenance can, in and of itself, be very valuable to collectors.

However, while it might be understood that the supply of a limited-edition item will be fixed, you generally aren't guaranteed that.  There's not necessarily anything to stop the manufacturer from making a crap-ton more of them and flooding the market, thus diluting the value of your purchase.

That's kind of like how it works with NFTs.  Unless you have a contract that says otherwise, it seems like you can't generally assume that you get anything other than the digital equivalent of a proof-of-purchase.  You get the exclusive rights to that certificate, but the only rights you get over the work associated with it are basically the rights of private ownership, i.e. to have and use it for your own, personal purposes.

To my way of thinking, it's kind of like the difference between buying an e-book from O'Reilly and downloading the same e-book from a torrent site.  Either way, you have a copy of the book that you can read.  Either way, you can give your friend a copy of it to read.  But if you buy it, you have a receipt to prove that you bought it.

Is there some value in that?  Yes, I think there is.  I can especially see that in the case of a "digital collectible", where a significant portion of the value could be in just having them in your collection.  (I do think paying large amounts for that is silly, but I also think paying large amounts for physical collectibles with no intrinsic value is silly.)  But for cases where there's no physical asset, and no ownership rights over the original digital asset, and nothing to stop the creator from minting more tokens for the same asset...?  I have a hard time imagining a "certificate of authenticity for Jack Dorsey's first tweet" being worth $2.5 million.

So I'm moderating my position a little.  I'm not going to say that all NFT is just dumb.  Depending on the transaction details, it can be a useful thing to buy.  But I think it really depends on the details.  I mean, if all you're buying is a "certificate of authenticity" for something that somebody else owns and anyone can get for free, that seems kinda silly.  And paying thousands of dollars for something like that seems really silly.  So while NFT might not be totally worthless, I still think a lot of the high-priced transactions we read about are nothing but speculation.  (Or money laundering, or tax avoidance, or whatever other financial tricks people pull with collectibles.)

However, this Slashdot post points out that there are some potential issues with NFTs.  Basically, NFTs don't actually store the asset you're purchasing.  So if you buy an NFT for an image, the image doesn't actually live on the blockchain.  You've only bought a reference to the image, which is actually hosted someplace else.  So if whatever server or service is hosting that image goes away, you will no longer be able to access it, regardless of owning the NFT.

So I guess what I'm confused about is: what's the point?  I mean, what are you really getting when you buy an NFT?  In a theoretical sense, I can see how an NFT is better than "conventional" digital assets in that it's not tied to a particular service.  Your ownership of that item is recorded in you crypto wallet which is independent of any particular service an can be used with multiple NFT marketplaces.  And that's a good thing. 

But when you look at it functionally, there's not really much difference.  The actual asset still exists completely independent of the blockchain, so it's not like a physical asset - there might only be one token, but you can still infinitely duplicate the asset.  And as far as I can tell, buying an NFT doesn't actually mean you're purchasing the copyright for the asset.  So you're just buying a copy and there's nothing to stop anyone from making other copies.  And because the asset isn't stored on the blockchain, if you want to ensure you always have access then you need to download a copy of it.  So...how is this different from buying a service-specific digital asset?

It seems like the point is less the actual asset and more that NFT is the same thing as Bitcoin - that it's just a different way to speculate on blockchain stuff.  Especially when you're talking about something like spending $2.5 million for jack Dorsey's first tweet, it's hard to see any other rational explanation.  But even for less absurd cases, it's not clear to me what the practical benefit is.  The main reason that blockchain "works" for cryptocurrency is because the thing on the blockchain is the thing you're transferring.  As soon as you introduce a disconnect between the thing being traded and the thing on the blockchain, it seems like you lose a lot of the benefit of the blockchain.  

This particular afternoon I was listening to some talks from the GOTOpia Europe 2020 virtual conference.  This one had an especially good lineup, including talks from Dave Thomas, Kevlin Henney, and Allen Holub, who are some of my favorite presenters.  Cat Swetel, who I'd never seen speak before, also had a very interesting presentation on metrics that I would heartily recommend.

It might not be the same vibe as the live conferences, but it's at least nice to be reminded that the entire world hasn't been canceled due to the pandemic.  And there are always some interesting discussions at GOTO, so it's worth a watch.

In case it's not already obvious, this is a bad thing.  Academic journals are supposed to be where we publish new advances in human knowledge and understanding.  Of course, not every journal article is a leap forward for human kind.  In fact, the majority of them are either tedious crap that nobody cares about, of questionable research quality, or otherwise not really that great.  And since we're talking about open-access journals, rather than top-tier ones like Nature, lower-quality work is probably over-represented in those journals.  So in reality, this is probably not a tragedy for the accumulated wisdom of mankind.  But still, there might have been some good stuff in there that was lost, so it's not good.

To me, this underscores just how transient our digital world is.  We talk about how nothing is ever really deleted from the internet, but that's not even remotely true.  Sure, things that go viral and are copied everywhere will live for a very long time, but an awful lot of content is really just published in one place.  If you're lucky, it might get backed up by the Internet Archive or Google's cache, but for the most part, if that publisher goes away, the content is just gone.

For some content, this is a real tragedy.  Fundamentally, content on the Internet isn't that different from offline content.  Whether it's published on a blog or in a printed magazine, a good article is still a good article.  A touching personal story is no more touching for being recorded on vinyl as opposed to existing as an MP3 file.  I know there's a lot of garbage on the web, but there's also a lot of stuff that has genuine value and meaning to people, and a lot of it is not the super-popular things that get copied everywhere.  It seems a shame for it to just vanish without a trace after a few short years.

I sometimes wonder what anthropologists 5000 years from now will find of our civilization.  We already know that good quality paper can last for centuries.  How long will our digital records last?  And if the media lasts 5000 years, what about the data it contains?  Will anthropologists actually be able to access it?  Or are they going to have to reverse-engineer our current filesystems, document, and media formats?  Maybe in 5000 years figuring out the MPEG-4 fomat from a binary blob on an optical disk will be child's play to the average social science major, who knows?  Or maybe the only thing they'll end up with the archival-quality print media from our libraries.  But then again, given what the social media landscape looks like, maybe that's just as well....

These days, of course, RSS is passé, and when people refer to a "feed", it's usually coming from Facebook, Twitter, Instagram, or whatever vendor-locked service the kids are using this week.  I find this sad.  The idea of the open web was so promising, but not that much really came of it.  Instead of being spoon-fed our information and entertainment by big media companies via broadcast and print media, we're now spoon-fed our information and entertainment via the internet by big tech companies.  And this time, the content is not selected by gate-keeping editors, but by AI algorithms that are tuned to feed us whatever will keep us clicking, with little to no regard for whether it's true, useful, or even remotely good for us.

For the record, I still use RSS feeds all the time.  I use the Tiny Tiny RSS aggregator, which is quite nice, to read the various blogs and news that I'm interested in following.  I have accounts with a few of the big social media platforms, but I rarely ever read them and never post anything.  I find them to be a huge time-sink and not especially conducive to good mental health, and so better off avoided.  Of course, your mileage may vary, but just keep in mind that you don't need to look at these sites - if anything truly important happens, someone will tell you about it.  I mean, unless you're a shut-in with no friends or family.  In that case, maybe social media is a good thing for you.  

At any rate, these were my thoughts in 2007.  Perhaps they'll be interesting or enlightening.  Or perhaps entertaining in their naivete.  Enjoy!

If you frequent tech sites or weblogs, you've probably seen the RSS icon or the XML feed icon .  You may also have seen other icons or text links referring to XML feeds, RSS, or even podcasts.  In fact, if you're using a web browser other than Internet Explorer, you may have seen one of these icons pop up in the address bar or status bar.  In this article, I will try to explain, in layman's terms, what RSS is and why it is so useful and important to the future of the internet.

What is RSS?

RSS stands for Really Simple Syndication.  As this name suggests, it is a syndication format.  

By "syndication," we mean essentially the same thing as when we talk about syndicated television shows.  A syndicated TV show is one that is shown on multiple independent channels at the same time, as opposed to being exclusive to a single network.  So for example, a syndicated show in the United States might be broadcast by NBC, Fox, the Sci-Fi channel, and USA all at the same time.

RSS works the same way.  An RSS file, usually referred to as a feed, contains a list of recent updates to a site.  The site operators publish this file on the web site and allow other people to subscribe to it, which is really just a fancy way of saying they automatically download it on a regular basis.  These people can then "republish" the information, either by incorporating it into their own sites or simply reading it into a desktop application.  The idea is that if the site's operators update the RSS feed every time they update the site, anyone who subscribes to it will automatically get the next "episode" the next time he downloads the file.

But what would I do with it?

If you are not already familiar with RSS, you may be wondering why anyone would bother with this.  After all, if you just want to read the updates of a site, isn't it just as easy to read the home page?  

At this point, you may be thinking that this doesn't sound much different from just visiting the web site in question.  After all, why would you want to bother with this RSS thing when you can just go to the site's home page like you've been doing for years?  

You wouldn't be wrong to think that.  If you're talking about just one site, with one set of updates to track, then RSS doesn't make any sense.  It would just be a different way of doing the same thing.

The beauty of RSS is that, unlike a web page, you can easily write a program to break up the information and organize it in a useful way.  For example, you can have a script on your web site that takes RSS news feeds from CNN, the BBC, and others and puts them all together in a news ticker on your home page.  You can also have programs such as RSS aggregators, which pull together news items from multiple sites and display them together so that you can browse them quickly and easily.  

I will discuss some other uses of RSS, including the trendiest of them all, Podcasting, later in this article.  (Note from the future: I never actually did that.)  But before that, we need to cover why RSS is useful and separate the fact from the hype.

A brief technical digression

What makes RSS so useful and so widely applicable is that it is a standard format.  It is an application of XML, the eXtensible Markup Language, which is an industry standard markup language for use with structured information.  I won't bore you with a description of XML, but the upshot of this is that RSS files all contain a certain set of standard information which is always marked with the same standard tags.  This means that a program can easily go through the file and pick out particular pieces of information, like the title of a particular news item, without having to pay any attention to what the title actually says or how it is formatted for display.  And because RSS is based on XML, there is already a wide array of programming tools that can be used to create and manipulate the files.

This is in stark contrast to web pages.  Although HTML, the markup language used to build web pages, has a standard set of tags, there is no standard for how a page is structured.  So while there are fixed ways of defining lists, tables, and paragraphs in HTML, there is no agreed upon way to say, "This is a news item, this is its title, and this is the link to its page in the archives."  (Note from the future: With the advent of HTML 5 this is no longer technically true.  However, semantic markup is not universally or consistently applied, so it's still close enough.)  So while a human being can easily look at a page full of items and determine where one ends and the next begins, there is no simple and general way for a computer to do that.  Because everyone is free to pick how they want to denote those things, a program would have to analyze the content of the page and figure out what the author of each page was thinking.  Needless to say, this kind of mind-reading is not something computers are particularly good at.

Getting past the hype

You know what the computing industry is best at producing?  It's not software, hardware, or anything else you can buy in the local office supplies store.  It's hype.  And to really appreciate how good RSS is, you have to get past the hype generated breathless pundits who seem to think it will cure cancer, feed the starving, and bring peace to the world.  (Note from the future: Nobody gives two hoots about RSS or XML anymore.  Hype has a very limited life span.)

From a technical standpoint, there is absolutely nothing revolutionary about RSS.  It's just a standard way of formatting a text file.  You could even create an RSS file in Windows Notepad if you really wanted to.  

And when you think about it, using RSS feeds is just a fancy name for putting a text file on your web site and then letting people download it and mess around with the information it contains.  How is that revolutionary?  We could do that 20 years ago.  

However, it is important to remember that "revolutionary" and "innovative" are not the same as "good."  RSS is good because it provides a standard way of transmitting certain kinds of information in a way that puts all the power in the hands of the consumer, not the publisher.  It's not the technology itself that's revolutionary, but rather the way people have chosen to apply it.

The real reason RSS and the whole "Web 2.0" thing are important is not because of the technology, but because of the paradigm.  That paradigm is: the user is king.  In an era where Hollywood and the music industry are trying to tell you when and where you're allowed to use the music and movies you paid for, open standards put that power in your hands.  (Note from the future: People have forgotten about that aspect, so now "Web 2.0" means "the site uses AJAX."  Also, substitute "Hollywood" for "big tech companies.")

Of course, this is obviously not true of all developers (like Lauren, for example), but if we apply it to the general zeitgeist of the community, at least as you see it online, then there does seem to be something to this.  As a group, developers are very focused on "the coming thing", as Brisco County Jr. would say.  We all want to be ahead of the curve, working with the cool new technology that's going to take over the world.  We want to be on greenfield projects that are setting the standard for how to do things.  That's why otherwise intelligent programmers do or suggest crazy things like rewriting their conventional LAMP-based site in Go and ReactJS.  Of course, it's long been established that rewriting from scratch is almost always stupid and wasteful, but the fact is that while PHP might pay the bills, it isn't cool.

Of course, it isn't just because they want to be cool that developers like newer technologies.  There are plenty of other reasons.  Intellectual curiosity, for one.  Many of us got into this line of work because we enjoy learning new things, and there are always interesting new technologies coming out to learn.  Learning old things can be interesting as well, but there are a few problems with that:

1. Older technologies are less marketable.  Learning new tech takes a lot of time and effort, and if the tech is already on the way out, the odds of seeing a return on that investment of time, whether financial or just in terms of re-using that knowledge, are significantly lower.
2. Older tech involves more grunt work.  In other words, older programming technologies tend to work at a lower level.  Not always, but the trend is to increasing levels of abstraction.  That means that it will likely take more effort and/or code to do the same thing that you might get more or less for free with newer tech.
3. The problems are less fun.  This particularly applies to things like "supporting Internet Explorer", which Lauren mentions.  When you have to support both the old stuff and the new stuff, you generally have lots of problems with platform-specific quirks, things that are supposed to be compatible but really aren't, and just generally trying to work around limitations of the older tech.  These are the kind of problems that can be difficult, but not in a good way.  They're less like "build a better mousetrap" and more like "find a needle in this haystack".

So, in general, developers aren't usually super enthusiastic about working with or supporting old tech.  It's not really as bad as some people make it sound, but it's not really where most of us want to be.

Another factor is the way websites are developed.  The ideal is that you'd have somebody who is trained and experienced in designing user experiences and who is capable of considering all the use-cases and evaluating the site based on them.  That person could communicate that information to the designers and developers, who could incorporate it into their work and produce sites that are easy to use, compatible with assistive technologies, degrade gracefully when using less capable hardware or software, etc.  The reality is that this rarely happens.  In my experience:

1. Many teams (at least the ones I have experience with) have no UX designer.  If you're lucky, you'll have a graphic designer who has some knowledge or awareness of UX concerns.  More likely, it will be left up to the developers, who are typically not experts.  And if you're very unlucky, you'll have to work with a graphic designer who is fixated on pixel-perfect fidelity to the design and is completely indifferent to the user experience.
2. Most developers are on the young side.  (There are plenty of older developers out there, but the field has been growing for years and the new people coming in are almost all young.)  They're also able-bodied, so they really have any conception of the physical challenges that older people can have.  And it's hard to design for a limitation that you didn't think of and don't really understand.
3. While it's easy in principle, progressive enhancement and graceful degradation can be very tricky to actually pull off.  The main reason is that it's extremely easy to accidentally introduce a change that doesn't play well with some browser, doesn't display properly at some resolution, or what have you.
4. And let's not forget testing.  Even if you can build a site with progressive enhancement, proper accessibility, and attention to the needs of less technical users with little support available, you still need to test it.  And the more considerations, use-cases, and supported configurations you have, the more your testing space expands.  That makes it much harder and more time-consuming to make sure that all these things are actually present and working as intended for all users.

So what am I trying to say here?  I do agree with Lauren that supporting elderly users, disabled users, etc. is an important thing.  It's a thing that, as an industry, we should do.  But it's hard.  And expensive (at least compared to the way most shops work now).  That's not an excuse for not doing it - more like an explanation.

Every shop needs to find a balance between supporting a diversity of users and doing what they need to do within a reasonable budget of time and money.  While it's important to think about security and support new standards, I think that in recent years the industry has probably been a little too quick to abandon old, but still widely used technologies.  If nothing else, we should at least think more about our target user base and whether we're actually serving them or ourselves by introducing $COOL_JS_FRAMEWORK or dropping support for Internet Explorer.  I'm sure that in many (but not all) cases, dropping the old stuff is the right choice, but that shouldn't be the default assumption.

Of course, approximately 90% of those startups will be out of business in less than five years, but hey, you never know, right?  After all, the entire business model is "get big so you can IPO or get bought out".  Sure, you could try to build a profitable, medium-sized business, but that's basically the same thing as failure.  Besides, if you can attract venture capital, it's not your money you're blowing through anyway, so who cares?

The good news is that the industry seems to be moving away from that mindset a little bit in the last few years.  Or, at least, things seem to be moving more toward business-to-business sales, as opposed mass-market products that have no clear business plan beyond "get huge".  So maybe that's a good sign and this idea of copying every crazy/innovative thing that the big boys are doing will be a thing of the past soon.

Or maybe not.  But I can dream.