Will Your Hardware Startup Make Money? - <AUTHOR> https://medium.com/@BoltVC/will-your-hardware-startup-make-money-677a8e6c665b <comment><USER2> This is a great article and the estimates are decent for what it is. The ultimate point is absolutely right: you will not make money on your first production run. But there are three big warnings that should be in BLINK tags under the headline:

(1) This is a decent estimate for a completely commodity product (Bluetooth headphones). No iOS/Android app development, no content development, very little custom firmware or electronics development required. (That correspondingly means you face the least differentiation and the most competition.)

(2) This is for a "plastic and PCB" product build. That's as simple as it gets. Any product that goes beyond a PCBA inside a plastic enclosure is usually going to have significantly greater design and engineering challenges, not to mention COGS costs. Moving parts? Temperature? Water? Cameras/lenses? Sensors? etc.

(3) The marketing / customer acquisition cost is either ignored or assumed to be some laughably small number. Even at its highest, this article assumes $3/unit customer acquisition cost. That's ridiculous (go look at Fitbit or Gopro or any other filing statements). If it were true, a lot more people would go ahead and get that initial capital to make their own Bolt-o-Phones.

(Disclosure: co-founder of a hardware startup [https://www.pantelligent.com/](https://www.pantelligent.com/) and about to ship our first production run.)

<comment><USER3> What's your estimate for item 3?

<comment><USER4> i think OP was suggesting you look at GoPro / Fitbit's filing documentation with the government, which publicly discloses these numbers.

i'll look for them and update this comment if i find them

\</comment></comment></comment><comment>----

> We have recently begun to spend significant amounts on advertising and other > marketing campaigns to acquire new users, which may not be successful or > cost-effective.

> We have recently begun to spend significant amounts on advertising and other > marketing campaigns, such as television, cinema, print advertising, and > social media, as well as increased promotional activities, to acquire new > users and we expect our marketing expenses to increase in the future as we > continue to spend significant amounts to acquire new users and increase > awareness of our products and services. In 2014 and for the three months > ended March 31, 2015, advertising expenses were $71.9 million and $21.1 > million, respectively, representing approximately 10% and 6% of our revenue, > respectively. While we seek to structure our advertising campaigns in the > manner that we believe is most likely to encourage people to use our > products and services, we may fail to identify advertising opportunities > that satisfy our anticipated return on advertising spend as we scale our > investments in marketing, accurately predict user acquisition, or fully > understand or estimate the conditions and behaviors that drive user > behavior. If for any reason any of our advertising campaigns prove less > successful than anticipated in attracting new users, we may not be able to > recover our advertising spend, and our rate of user acquisition may fail to > meet market expectations, either of which could have an adverse effect on > our business. There can be no assurance that our advertising and other > marketing efforts will result in increased sales of our products and > services.

ALSO

> Revenue increased $474.3 million, or 175%, from $271.1 million for 2013 to > $745.4 million for 2014. A substantial majority of the increase was due to > an increase in the number of devices sold from 4.5 million in 2013 to 10.9 > million in 2014, including $151.9 million from new products that we began > selling in 2014. U.S. revenue, based on ship-to destinations, increased > $356.5 million, or 173%, from $206.1 million for 2013 to $562.6 million for > 2014 and international revenue, based on ship-to destinations, increased by > $117.9 million, or 181%, from $65.0 million for 2013 to $182.9 million for > 2014.

So ballpark 11 million units sold in 2014, and 71.9 million dollars in advertising in 2014

That's $6.59 worst case customer acquisition cost (assuming no repeat customers)

[http://www.sec.gov/Archives/edgar/data/1447599/0001193125151...](http://www.sec.gov/Archives/edgar/data/1447599/000119312515176980/d875679ds1.htm)

<comment><USER2> Your "assuming no repeat customers" is a key point -- when reading overall financial statements like these, note that at "jumbo scale" like Fitbit/GoPro, the "average" customer acquisition cost actually drops tremendously because you get: referral sales / word-of-mouth from existing customers, much more public awareness and perceived legitimacy, more free press coverage, replacement and upgrade sales, gifting from existing owners, etc. all of which contributes to $0 effective CACs on those additional units sold. It does not mean that their _marginal_ cost to acquire an additional new customer is $6.59; if it were, they'd certainly go out and spend it as fast as they can until saturation.

In contrast, a hardware startup (or a software one, for that matter) just has to go out and hustle to get every single sale, whether through paid or non- paid customer acquisition channels. This is where YC's philosophy of treating hardware and software companies similarly works: they both usually have very similar customer acquisition challenges in rapidly building and scaling their growth channels (rather than, say, technical engineering challenges, which are very rarely the limiting factor in startups).

</comment></comment><comment><USER5> You're software start-up probably won't make you money either. At least for hardware, people don't have so many free options. The barriers to entry are also higher. Someone won't be developing hardware after a 12 week online course. To me it looks like a great time to build hardware.

Kickstarter has really changed the game. These guys launched today, for example, and they'll probably be funded within 24 hours:

[https://www.kickstarter.com/projects/1152958674/the- sensel-m...](https://www.kickstarter.com/projects/1152958674/the-sensel-morph- interaction-evolved)

<comment><USER6> I tried to launch a hardware start-up on Kickstarter earlier this year ([http://www.pcgamer.com/introducing-gameref-the-anti-cheat- ha...](http://www.pcgamer.com/introducing-gameref-the-anti-cheat-hardware/)). Unfortunately, it didn't get funded.

I might just suck at PR, but I don't think The Sensel Morph is really representative of your run-of-the-mill funding experience.

<comment><USER5> These guys raised $650k for their keyboard last month:

[https://www.kickstarter.com/projects/keyboardio/the- model-01...](https://www.kickstarter.com/projects/keyboardio/the-model-01-an- heirloom-grade-keyboard-for-seriou/description)

I think a lot of these guys try to build a following before they launch.

<comment><USER7> Yes, there's a lot of planning that goes into a successful campaign. We prepared for six months. It's not hardware, but similar business/marketing challenges. Here's how we raised $484k on Kickstarter: [http://blog.glowingplant.com/post/85922974558/how-we- raised-...](http://blog.glowingplant.com/post/85922974558/how-we- raised-484k-on-kickstarter-to-make-glowing)

</comment></comment></comment></comment><comment><USER8> I would add a few additional things to consider when thinking about a hardware product (via retail). First, creating additional value for your entire supply chain is extremely important, and gives you a lot of leverage. The OP mentioned this indirectly via high demand products creating walk in value, but additional value also can include selling a higher value/higher margin product, or creating a product that is highly consumable and has a high churn rate (think 5 hr energy). Ultimately the retailer is trying to maximize the $/sq ft in their store, and doing the things mentioned above will certainly help with that. Also selling a product that drives accessory purchases will give you additional leverage. Think phones that push purchases of cases and screen covers. Also think of Apple and the huge amount of floor space their products take up in a Best Buy. They can do this because of the higher value their products offer to the retailer. In addition, the higher value product you sell, the lower margin your retailers can be willing to take in order to sell the product. Ultimately, the retailer has to make more money with your product than the other products he or she could be selling in the same space to justify selling your product. This line or reasoning goes for your suppliers as well, especially if you are working with a factory that is near or at at capacity.

</comment><comment><USER9> Really good explanation of all the costs people don't think about. Don't be disheartened. Take those numbers and work them down. Get the overhead cost down by doing it yourself and using consultants. Get the manufacturing cost down through dogged engineering and adjusting your product spec. Write a product strategy that allows you to ramp up toward retail availability, even if it takes several products to get there.

Yes, you will likely fail if you've never done this before and you're trying to make a consumer-quality product. So get experience with an intermediate step or two.

<comment><USER10> Underrated post here. Kestner's launched multiple products. Greets from the ML.

</comment></comment><comment><USER11> It is certainly true that you can spend this amount of money on a product and not make money on the first 5000 product run.

But it is certainly possible to make money on such a first batch: Why do you need inhouse EE, ME, DE en Embedded Engeneer for a headphone. Many of these functions can be done by a small design firm or freelancer that you hire for a much smaller fee. In addition, these people do this all the time for different companies and have a huge experience this way and good contats (you can also go with teh bigger firms, but then you probably need the same amount of money).

<comment><USER12> So... You are a hardware start-up that doesn't actually do any hardware. I recall a guy who got seriously burnt by taking this approach in a kickstarter: he had designed a iPad cover, successfully funded it and then proceed to crash as all his supply chain decided that wanted a bigger slice of that money. He even got sued by some random backer.

I think you really need some expertise in what you are trying to build. It has to be really hard doing a decent cost estimation otherwise.

</comment></comment><comment><USER6> I did a hardware startup earlier this year ([http://gameref.io](http://gameref.io)) and tried to fund it via Kickstarter. I need to write a post-mortem one of these days, but even after significant media coverage (including PC Gamer, Vice, Polygon, etc.):

\- [http://www.pcgamer.com/introducing-gameref-the-anti-cheat- ha...](http://www.pcgamer.com/introducing-gameref-the-anti-cheat-hardware/)

\- [http://www.redbull.com/en/esports/stories/1331720277392/game...](http://www.redbull.com/en/esports/stories/1331720277392/game- ref-esports-cheating-interview)

\- [http://www.pcgamesn.com/gameref-is-a-prototype-anti-cheat- sy...](http://www.pcgamesn.com/gameref-is-a-prototype-anti-cheat-system-that- uses-hardware-to-weed-out-hackers)

\- [http://www.polygon.com/2015/2/23/8090221/onling-gaming- cheat...](http://www.polygon.com/2015/2/23/8090221/onling-gaming-cheating)

\- [http://motherboard.vice.com/read/can-this-little-device- fix-...](http://motherboard.vice.com/read/can-this-little-device-fix-cheating- in-esports)

.. it failed to get funded. Failure is part of the game and I wasn't too phased by it, but it still sucks. Unlike a software start-up where I can build and launch a working alpha/beta, you NEED some money to pour into a hardware start-up right at the start. It's not easy and, as the article mentions, the margins aren't as great as software. The sentiment of hardware being tougher than software is ubiquitous from what I can tell.

Props to the people that make it though.

See the KS page here: [https://www.kickstarter.com/projects/1094040691/game- ref-the...](https://www.kickstarter.com/projects/1094040691/game-ref-the- worlds-first-hardware-anti-cheat-devi)

<comment><USER13> Curious what the endgame looks like for hardware startups that fail? One of the things that appeals to me about software startups is that if they don't work out, I've learned a lot of valuable technical skills that there's a market for. I can easily do some consulting or get a job with a fast-growing company to replenish the bank account, and then try again if I have another idea.

Is there the same transferability with hardware startups? Do other companies love to hire failed hardware entrepreneurs the way they usually like to hire failed software entrepreneurs, or do you just write off the money and time spent on the startup as a dream forgotten?

<comment><USER6> > do you just write off the money and time spent on the startup as a dream > forgotten?

This isn't my first rodeo, but I usually just write off failed start-ups in general as dreams forgotten (and boy do I have a lot of forgotten dreams). I obviously gained a lot of technical knowledge: how USB works, packet formats, some hardware engineering, driver programming, etc. But unless I ever get a job writing low-level code for hardware devices, I doubt I'll ever use that knowledge again.

Who knows, maybe for another hardware start-up?

</comment></comment></comment><comment><USER14> This is probably an underestimate for the product development phase. And if you want to sell to Best Buy you usually need to work with a distributor who has their own margin. Rule of thumb is 3-4x COGS to get to MSRP.

</comment><comment><USER15> I'm having trouble with this article and I hope someone from HN will help clarify for me: why was an initial run of 5000 units selected? This seemingly arbitrary number seems too important in HW development to be relegated to a single non-explanatory bullet point.

If my understanding is correct, product dev teams seem to aspire to an initial 500 - 2000 units for that initial run as the symbolic point of reaching this "finalized" level of development. Any production at this level is considered a finished good ready for the sales/supplier pipeline.

Once a product has reached this level, my understanding is that subsequent runs is typically for 10K to 25K widgets per run ("lot") that see anywhere from 10,000 to 250,000+ widgets for a single SKU per production run.

Above 1 million units, everything changes, but the 5K first-and-only run seems abnormal.

<comment><USER16> Producing 500 or 2000 units would virtually require the same time, so you may as well get a standard batch size and improve your margins.

<comment><USER15> There's a big difference between 2000 and 5000 unit initial runs... why 5000?

<comment><USER17> For an initial production run there are a lot of fixed setup costs. Just from my gut feel 5000 units is just barely off the NRE (non recurring engineering cost) 'knee'. (And the manufacturing learning cost knee) Less than 5000 units the NRE costs start to dominate your out the door manufacturing price. So at 2000 units that might be 50% to 80% higher per unit than at 5000 units.

Also people often forget about your suppliers management, accounting, and sales overhead. That means that they will have minimum orders below which they don't make enough money justify the overhead of shepherding your product through their shop. For Chinese suppliers 5000 units appears to be typical because lower volumes are typically on-shored. On shoring is going to increase your costs by probably 30%.

You might ask the other question, why not 10,000 or 20,000 units? Answer is that starts to be a huge chunk of money for something that isn't proven.

So ans: 5000 because less the NRE kills you. And you'll have to on shore production. And no more than that because otherwise your initial production costs becomes the dominant part of the investment risk.

<comment><USER16> Thanks for complementing my answer. That's exactly what I had in mind, but I (still) can't type from mobile devices. :)

</comment></comment></comment></comment></comment><comment><USER18> Great read and sums up a lot of my experiences. As a product manager who launched a niche consumer hardware product recently, I came up with the same analysis. Plus, manufacturing state-side (boston) had its own perks (quality control) and cons (labor cost and freight from china for components). Even after you factor in all the costs, there is cost of acquire customers which can be quite a lot for a product that is new in its category, where a lot of startups aspire to be. What is tricky is seeding customers, organic growth through hackathons, co-marketing, and customer stories.

Thanks for the post.

PS: Full Disclosure, i launched a robotic haptic device (cubify.com/touch).

<comment><USER3> >What is tricky is seeding customers, organic growth through hackathons, co- marketing, and customer stories.

How did Cubify handle these things?

</comment></comment><comment><USER19> One thing those tables don't account for is paying for your own (and other full-time) employee salaries post-production. Someone has to keep working after the initial production (and future) run is complete. You don't just sell your hardware, make your profit and leave :)

To sell 50k units or more you will need a few people to handle your store, marketing and support. Also will you continue to sell the same model for years or develop new versions? Lots of other costs to keep a business running should be included in your business financials.

A 3x multiplier is slightly low for CPGs, I'd go with 4-5x depending on the product and market to give yourself some breathing room. Things like sales, resellers and coupons all eat into profit.

</comment><comment><USER20> Those salaries seem absurdly low.

Also, why is the cost of employees with overhead lower? (NB/EDIT: Pointed out below this is for 3/4 of the year, not the full year - but the rest of my point stands.) That makes zero sense. Surely they are paying payroll tax, unemployment insurance and health insurance for their employees, no?

<comment><USER21> > Also, why is the cost of employees with overhead lower?

I think that's the cost of the employees for the 9 months (not 12) it takes them to do the required work.

<comment><USER20> Oh right. Math. Yes. Good call.

</comment></comment></comment><comment><USER22> Finding a talented EE for 75K/year seems like an impossible endeavor (if I read this correctly)

<comment><USER23> I know the EE space well in SF Bay Area (source - I was an internal recruiter for a hardware based startup). EE generally sits between 70-90k (but have seen people demand $120k), whereas software developers (especially mobile) is more like 90-120k (and for top talent sits around $150-200k). Depending on the financial health (i.e. funding) of the company, the full cost of an employee can range from 1.25x-1.80x their base salary. Hardware startups generally are stingy on their cost structure (and therefore probably skimp on benefits, bringing them down to 1.25x) because the cost structure is so high relative to software. For example, tooling costs could vary between $100-250k which is terribly difficult to estimate when you don't know the design or demand of your final product. The difference of $100k is...you guessed it...equivalent to a full additional human resource. Resource planning for hardware startups is scary.

I know for a fact finding talented EE people is possible at $75k, and that same level talent would most likely cost $100k for a software dev. Interestingly, there is a decent supply of EE talent out there, however due the varying degree of hardware applications finding the right person is more difficult than it seems on the surface.

<comment><USER24> But if your an EE _and_ a software dev can you get 75 + 100 or $175K ? :-)

One of the best advice my Dad ever gave me when I was thinking about majors in college was that you could program computers with an EE or a CS degree but without an EE degree they probably wouldn't let you build/design them. The math and physics were, to my taste, more difficult but I got tremendous satisfaction in being able to understand a computer from the PN junction of its transistors, to the process model of its operating system.

<comment><USER15> You don't need a degree for common sense.

My parent spout a lot of the same nonsense. Just who exactly are these "they" gatekeepers the Boomers keep referring to? Pretty sure "they" are the same keepers of great wisdom such as "Housing prices will always rise", and "Work hard, you'll get a pension and gold watch," sorts of people. Not intentionally wrong, but definitely behind the times.

Want to make a computer? WE don't need "them" to gatekeep their own bullshit anymore. Everthing, including fabs has been virtualized and is available online. Funding, PCB design and layout, soft-hard your FPGA ASIC designs, etc, etc, etc. Make your tradeoffs same as the rest of us, but don't think for a second that you must have "them" to make that computer.

I know it's not really that easy (my parents spout the same nonsense all the time, but I love them nonetheless), but try to surround yourself with enablers not gatekeepers. And be able to quickly differentiate between the timeless and the boomer knowledge.

</comment></comment></comment></comment><comment><USER25> One issue not being discussed is the revolving cost of having products out in the market and the cost of the next production run.

if your orders double from 20K units to 40K, your costs will roughly double, usually meaning that any profit made on the 20K is re-invested to make the 40K - usually plus additional capital.

So long as your production quantities double, you will not actually "have" any money (unless your FOB cost is north of four times sell price). Many companies cannot "realise" profit until orders stabilise.

</comment><comment><USER26> Thanks for the nice write up.

Hope someone can do an explanation like this for a software startup too.

</comment><comment><USER27> Also on HN Frontpage: "When Hardware kickstarters ship" [https://news.ycombinator.com/item?id=10113987](https://news.ycombinator.com/item?id=10113987)

</comment><comment><USER28> This should be prerequisite reading material for anyone doing a hardware kickstarter. Still waiting on my 3D printer 3 years later...

</comment><comment><USER29> Is he using COGS in the right sense? I think he means CIF, cost/insurance/freight. My company produces products in Europe and Japan and we use the term 'landed CIF' to include all the costs associated with mfg, freight, and duties before it hits our US warehouse.

COGS for us is how much is sold through a distributor to an end user.

</comment><comment><USER30> The first assumption "$30 to produce and you sell it for $99" is bad. That's not a high enough profit margin. Second, obviously don't hire people at full salary. Make something that people are excited to work on and give them equity to do it.

<comment><USER31> Equity doesn't pay for a house or feed children. 90% of the time, they will never bring in any money.[1]

You won't always be able to hire whoever you want/need if you offer them equity. An inexperienced, younger person who's willing to work for equity might cause delays in delivering which will also cost money.

1\. [http://www.forbes.com/sites/neilpatel/2015/01/16/90-of- start...](http://www.forbes.com/sites/neilpatel/2015/01/16/90-of-startups- will-fail-heres-what-you-need-to-know-about-the-10/)

<comment><USER30> True many people won't be able to work for equity full time. I've been lucky enough to find people willing to work with me for equity in their spare time. I'm not a connected or wealthy person. For many people like me it's the only option. I've been able to get people really excited about the product, but I also have had to accept that I have to be flexible with deadlines for people I'm not yet paying. Things take longer when you don't have money. Sometimes it's better to go slow.

</comment></comment></comment><comment><USER30> This article simply makes all the assumptions that will lead you to be unprofitable. Yes if you have a boring product and you spend too much developing it and don't have a high enough profit margin you wont make any money.

</comment><comment><USER32> Another hidden cost here (particularly if your main sales channel is direct to consumer) is shrinkage/fraud.

Consumer hardware is easy to purchase with a stolen credit card and fence on eBay.

</comment><comment><USER33> This article made me think of Betteridge's law of headlines ([https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...](https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headlines)): _" Any headline that ends in a question mark can be answered by the word no."_

On a serious note, it surprised me that the BOM listed the shipping materials as being about as expensive as an assembled and flashed PCB. It's interesting that a cardboard box (which feels pedestrian) costs about as much as a printed circuit board (which feels a little like magic).

<comment><USER34> I haven't downvoted you but I think people are because they're tired of references to Betteridge's law of headlines in every single submission ending with a question mark.

I personally don't think this is a good case of Betteridge's by the way.

<comment><USER33> Thanks for the feedback -- I really appreciate it!

</comment></comment></comment><comment><USER35> I half-expected a single word article with the word "no".

</comment><comment><USER36> An ee that can program and do some simple mechanical design can do all that engineering himself.

<comment><USER37> Maybe for a simple box, but for an injection moulded curved enclosure like the headphone example? If you didn't get that designed by someone who'd done it before you'd be taking a huge risk.

<comment><USER38> > you'd be taking a huge risk.

The subject at hand is a hardware kickstarter. That bridge has long been crossed and burned. If you had all the talent and resources at hand already, you'd probably have funding too.

</comment></comment></comment><comment><USER39> On a side note, is there a site like hacker news for Hardware?

<comment><USER40> Also check out [http://hackaday.com/](http://hackaday.com/) \- not quite the same, but much more hardware-focused.</comment></comment>


DaScript – high-performance statically strong typed scripting language (2019) - <AUTHOR> https://dascript.org/ <comment><USER2> OK, so I'm going to be a grumpy old man ...

My eyesight isn't great, so I use the "Zoom" function on Firefox to increase the font size. But the text now doesn't wrap, and I'm constantly scrolling from side-to-side to be able to read the text. It's tedious in the extreme.

Screen shot here: [https://www.solipsys.co.uk/images/daScript.png](https://www.solipsys.co.uk/images/daScript.png)

Magnification, line truncation, and scroll bar indicated.

* Why doesn't the text wrap to the window size? No idea.

* Why is it written like this? No idea.

Annoying, irritating, and so unnecessary.

<comment><USER3> > I'm going to be a grumpy old man ...

Ironically, the site is made using tables for layout! Like, the really old technique where the left and right margins of the content are actually td's with a bunch of &nbsp's inside.

I'm really surprised that someone would make a site this way nowadays. It is _a lot_ more work than necessary and the end results are not great (as you can see here).

PS: Running this in your console will get to a mostly workable state (not great, but better):

[...document.querySelectorAll('*')].map(e => {e.style.width = 'auto';})

Edit: I did my good deed of the day by opening a PR that modernizes the site's markup and CSS, fixing the issues too:

[https://github.com/GaijinEntertainment/daScript/pull/70](https://github.com/GaijinEntertainment/daScript/pull/70)

<comment><USER4> Thank you for that contribution!

Updated site is now live (along with big documentation update and link to sandbox tio.run).

</comment></comment></comment><comment><USER5> Nice one, it is nice to see an increase in more productive languages offering compilation as part of their toolchain capabilities.

</comment><comment><USER6> Curiously the daScript repository goes back to 2008, when it contained a URI parser: [https://github.com/GaijinEntertainment/daScript/tree/262ca4a...](https://github.com/GaijinEntertainment/daScript/tree/262ca4aecf26f9d399c27e592f6246c4b7f74fb6)

Ten years later, in 2018, someone added a basic lexer for "YZG" to the repo: [https://github.com/GaijinEntertainment/daScript/commit/215d5...](https://github.com/GaijinEntertainment/daScript/commit/215d50a2f84f630bde7369d508730baa51f951df)

</comment><comment><USER7> Too early to say anything but looks like it could replace lua as game's default scripting language. Suggestion to authors: copy Golang tour

</comment><comment><USER8> Looks really interesting. Nice approach and interesting featureset. I'll have to keep an eye on it.

Currently, it seems to be lacking documentation on how to embed and interoperate with C++, though, so have no idea how easy it is to get working (especially AOT vs interpreted and interop with templated C++ code).

</comment><comment><USER9> Used by Gaijin Entertainment and compiled and run on Nintendo Switch are two things that caught my eye. I will have to check it out for use in place of LuaJit.

</comment><comment><USER10> Compare to Nim?

<comment><USER11> Indeed. And Crystal ([https://crystal-lang.org/](https://crystal-lang.org/))

<comment><USER12> Does Crystal have an interpreter? I get the impression traditional ahead-of- time compilation is currently the only way to use it.

daScript has both ahead-of-time compilation and an interpreter.</comment></comment></comment>


Apple and Cisco Partner to Deliver Fast Lane for iOS Enterprise Users - <AUTHOR> http://www.apple.com/pr/library/2015/08/31Apple-and-Cisco-Partner-to-Deliver-Fast-Lane-for-iOS-Enterprise-Users.html

<comment><USER2> Fast lane? Really?

<comment><USER3> It doesn't sound like this is actually a net neutrality thing, just a really poor choice of words.</comment></comment>


Quality is fractal (2012) - <AUTHOR> https://web.archive.org/web/20120214085940/http://uxhero.com:80/ux-theory/quality-is-fractal/ <comment><USER2> Backwards compatibility which is all configurable by the network admin. If I have 2000 machines doing it one way there is no question that it's cheaper to add a new one without a 'new' feature.</comment>


Dear Developer, the Web Isn't About You - <AUTHOR> https://www.sonniesedge.co.uk/talks/dear-developer <comment><USER2> Previous discussion (8 months ago, 88 comments): [https://news.ycombinator.com/item?id=16773398](https://news.ycombinator.com/item?id=16773398)

<comment><USER3> That doesn't seem like a good reason for it to be marked as [dupe]...

<comment><USER4> Indeed. Is there some other more active discussion somewhere?

</comment></comment></comment><comment><USER5> > But the cultural focus is on developer happiness, on developer fun and > ramping up of code-related skillsets. "How does this benefit users?" has > suddenly gone missing from our vocabulary.

No, it hasn't. It's still 100% about how to benefit users for most teams. That is quite literally the only thing that matters and everything else is a means to an end.

I'm not going to deny the fact that there are some shoddy websites out there. There are some sites that are using the latest and greatest JS stuff when really, they should just be using HTML and CSS. Fine.

The majority of the work that gets talked about here, by software and tech startups, _will not be effectively built using HTML /CSS or server-side rendering_. Since we're on the topic of users, users have come to expect a certain level of interactivity. They expect that if you right click on a row, you get a drop-down menu and you can delete it. They expect that you can do inline editing of an item without being redirected elsewhere. They expect that you can create a new thing on the page without reloading and redirecting.

Let's forget about that part, though. Most software features are, at the end of the day, experimental. We don't know exactly what is going to be a hit and what isn't. If new tools allow us to iterate at 2x or 5x or 10x the rate of old tools, this is a net positive for users.

No one would denigrate a carpenter for using an electric screwdriver over a manual one. No one would complain that the carpenter only cares about their "carpenter experience". At the end of the day, the "user" wants their cabinets finished.

<comment><USER6> I can't agree. Most sites I see nowadays are not in any way more effective for their deep use of frameworks. Best example of the craziness here is the blogging stuff Google has that loads the content after the page load. Why?

React is amusing, as it makes it look like you have to have a complex JavaScript framework to have hot loading. But you don't. Never have. Will you need a fancy tool that knows JavaScript well? Yes. Do you need to be writing to that tool, or with it?

So, nobody would mock a carpenter for using power tools. They would question one that only worked with a 3d printer. Even though that would certainly let them iterate faster.

<comment><USER7> People use react because:

1\. It is designed to be testable. It makes testing the components much easier than testing jQuery soup. 2\. It has an opinionated way for developing javascript applications 3\. Will validate input types passed to controllers 4\. Has nicer syntax than jQuery soup

<comment><USER8> > jQuery soup

I'm not sure if you're blaming the tool or not, but at least for 3rd parties, I want to clarify: jQuery doesn't mandate "soup" \- In fact, devs learned over time that the best approach development with jQuery was the same as without - have application state tracked as variable(s), have routines to translate the current state into the the DOM. That's the unidirectional flow that React likes, and both vanilla JS and jQuery can run with it.

But jQuery makes it EASY to use your DOM as state storage, which works well at first and quickly grows nastily complex. Meanwhile, React makes it EASY to update the DOM from state without performing unnecessary re-renderings.

So jQuery doesn't mandate, or even encourage "soup", but there's nothing guiding you away from it. React, OTOH, makes the path of least resistance be towards this particular best practice.

To your points as to why people use React, I don't think those are bad points, but those aren't my primary points. React best practices mimic the best practices of coding in general: Small, single-purpose components with minimal coupling. This allows me to bring in experience from outside React, and allows me to apply React experience outside of React.

<comment><USER9> > application state tracked as variable(s),

Model.

> have routines to translate the current state into the the DOM

Views. Triggered by #changed notifications.

> That's the unidirectional flow that React likes,

Aka MVC.

</comment></comment></comment></comment></comment><comment><USER10> The '30% of rural Americans still not on broadband' point is, understatedly, one of the most important points of the article by far.

It is so, so easy, to be living and working in big cities like Toronto (me), SF (a bunch of you), NY, Chicago, et cetera, and truly forget the context of the absolutely _awful_ experience a lot of people have online outside of these urban epicentres.

I remember living on a farm in rural Illinois (Marengo), and the best internet we could get at the time was satellite. Which (or, worse, dial-up) is the only option for a lot of Americans, apparently.

Satellite internet, in particular, causes these poorly-optimized web sites with hundreds of tiny JS files and images to take forever to load on this type of connection, because Satellite internet works by pinging the satellite for every connection, meaning downloading a large file can be fast, but opening Facebook can take up to 3-4 minutes. (My ex-partner who still lives on that farm confirmed this for me today.)

The author, then, brings up the next, most important point: 'Your website had better be amazing for it to justify that length of download time.'

For those making the audacious claim here that this isn't considering the dev's time put into it, I'd argue immediately back that the devs need to be considering the actual users.

People living in the country aren't 'edge cases'. They're usually extremely hardworking people who simply don't have access to the luxury of broadband like we do. Just because we don't necessarily see these people, or travel to other countries with shitty connections, doesn't mean they don't exist, doesn't mean they're not actually a potentially significant number of people, and doesn't mean we should not be arsed to trim 1MB-2MB off our bloated image- and-video-wieldy sites, or even that it would necessarily take a lot of time in most instances.

I agree. The web isn't about us. It's about who uses it.

<comment><USER11> Do we actually care about these users? Are they going to buy the products we advertise on our websites? Are they going to subscribe to our platform?

No. So why should we optimize for people who do not matter to our bottom like?

<comment><USER12> > Are they going to buy the products we advertise on our websites?

Why wouldn't they? Physical location aside, they're not any different than you or I. They have purchasing power like everyone else.

> Are they going to subscribe to our platform?

Why wouldn't they? Because they can't load your page? Doesn't sound like their problem.

> No. So why should we optimize for people who do not matter to our bottom > like?

Why don't they matter to your bottom line? Because you present them with tools and platforms they can't use, so they _can 't_ contribute to your bottom line? A self-fulfilling prophecy if there ever was one.

</comment></comment></comment><comment><USER13> > We're back to building sites that are not for everyone - huge, bloated > sites, running fragile imperative code on the users local device. We have > started to explicitly say "I think you should have this level of tech, > processing power, and bandwidth before I think you're eligible to use my > site".

This isn't in and of itself the problem, per se. Sometimes a more powerful and robust UI / UX / application is necessary. The problem is when said "solution" is applied to __every__ need. The problem is, when screwdrivers are being used to pund nails.

Much "like publish of perish" there's no (ego) glory in saying "Yeah. It's relatively lo-tech but that's the solution that best fit the business need." Rare is praise and/or hiring based on good analysis, appropriate tools and smart solutions. Nah. Size is all that matters. How people who can't do what you do it more important than doing the right thing(s).

<comment><USER14> _We have started to explicitly say "I think you should have this level of tech, processing power, and bandwidth before I think you're eligible to use my site"._

I actually worked with a pair of developers who believed this wholeheartedly. It seemed to be part of some kind of design philosophy they picked up where it was the responsibility of developers to build complex web sites and apps in order to "further" technology and encourage people to upgrade for the good of... something. I'm not sure.

They picked some baseline iPhone level (two generations removed from what was current, IIRC) and decided that anyone who wasn't "smart" enough to own that model, or better, shouldn't be allowed to use the product.

Then when they were ready to deploy, it turned out that the product only worked on _their_ phones, which happened to be the latest/greatest available at the time. So they built in a bunch of kludges and trimmed features to make it load on an older phone, and that was "good enough."

Not surprisingly, the company went out of business.

<comment><USER10> I have seen this...so many times.

I've been an iOS developer since the App Store became a thing 8 or whatever years ago, and the amount of people I've seen willing to only test applications on devices only 1-2 generations behind, if that, is shocking.

What's more offensive, shocking, and actually confusing is that, yes, management is usually the one saying this kind of thing.

The reason that confuses me, is that you'd think, I mean, if _I_ was in a management position at a mobile-related startup, one of the first things I'd do is have someone on my team do some market research to provide statistics on the current state of iOS device and version usage, and buy a freaking _heapload_ of test devices, in all the different resolutions and variants.

Dismissing your users because they're not 'smart' enough to have a newer model is, as mentioned in the article, essentially blaming these people for the circumstances in their lives that leave them unable to, or is simply insulting their intelligence.

I still use an iPhone 6S. Why? I need a headphone jack. I run an independent music label and _rely_ on GarageBand on a multiple-a-day basis. Bluetooth audio's latency is too awful to be usable when playing instruments or mixing/EQ'ing tracks, and furthermore, I'm not about to replace my $300 studio-quality headphones for some shitty bluetooth alternative, _or_ drag some tiny dongle around I'll need to adapt the headphones.

Does this make me 'not smart'? I think the exact opposite. I couldn't _use_ a new iPhone the way I have for the previous 6-8 generations before it.

There are _dozens_ of reasons why people prefer to keep older models of devices. My 2011 MacBook Pro is still my daily Logic Pro driver, and I even still do a bunch of iOS development on it, because, _gasp_ , I was able to open it up and upgrade the RAM to 16GB, remove the original hard drive, put in a 512GB SSD, remove the optical drive, and replace it with a 2TB HDD...which, if I'd bought a 2017/2018 and felt like the 8 or 16GB that came with it wasn't enough, I might as well throw out the window for all it's upgradeability.

Then let's talk about software - most of the people I know actively avoid software updates on their devices because they either don't know if it will hurt their device, or they simply _actively like it the way it is already_ , and don't want to be forced into whatever changes the devs and managers felt like this time around.

People like what works for them. And they don't like change.

tl;dr - Highly intelligent people have highly intelligent reasons to stick with their older devices and software. Hipster managers who think they're 'too cool' to see this piss me right off.

<comment><USER15> Saying you use a 6S as if you're using old slow technology is a bit of a stretch. The 6S from 2015 is actually faster than most modern Android phones in single core performance - including the Samsung Galaxy s9

<comment><USER10> I'm not saying a 6S is 'old technology'. My point is, it's the newest that is available/usable to me, and my path to an upgrade to 'new technology' is non- existent.

I am saying, that the impression OP gave me is they were literally throwing it on the CEO's iPhone X, they felt like it worked there, and didn't bother to even go a couple generations back.

This wouldn't be the first time I've actually seen this kind of business- destroying, frankly elitist behaviour that does not benefit business.

</comment></comment></comment></comment></comment><comment><USER16> Ha! That's in line with an idea I'm considering - a modern HTML-only browser. A bit like one of those terminal browsers, but with nice proportional fonts, images and other basic things. Customizable entirely up to likings of a user. A user agent, not a webdev agent. It could also support Gopher protocol. CSS got out of control, so sorry no more position:fixed bars that are more and more in fashion.

Ech. But first I need to get back to work on a search engine that would _not_ index ad serving pages with possible option of filtering out JS serving pages.

<comment><USER17> Build it on links. It supports advanced terminal functionality like graphics already.

</comment></comment><comment><USER18> Here's the real problem. The JS tools got really powerful and the majority of users now experience faster dev cycles and richer features. Now users cannot go back. If we started serving smaller sites with less js people would complain about all the little features they liked that don't exist anymore.

A developer now has a choice: use the big framework where you can satisfy those now entitled users or give up some success and make a tiny site with limited use of js. I'm all for the free web but I know which choice I would make when running a for-profit company.

<comment><USER19> Has anyone tried? Gone back to a simpler interface, fewer "little features"? I think I would like that, and others would, too.

<comment><USER20> HN seems to be doing fine

</comment></comment></comment><comment><USER21> I think it's true that many sites are over engineered for what they are. Does a site that's primarily for reading articles really need to be an SPA? Why can't your sign in fallback to being a simple form? Etc.

Then again it can actually be pretty easy to over engineer nowadays. Once you have your node/npm environment set up with webpack and all the rest you can quickly iterate a new site based on an earlier project. And if you hear of something new and cool it's only an npm command and a few hooks away.

<comment><USER22> What I've been thinking about ever since I learned about web brutalism is - how can I make simple, HTML focused websites, static? That is to say, not requiring a backend I build to generate the necessary HTML and serve it as a document to a given url?

So index.html is easy, but is there a way to make it such that I can go to my website/articles/my-happy-day, and have that page be generated, rather than a separate handwritten my-happy-day.html file?

I typically "deploy" simple shit by uploading it directly to my bluehost filesystem, or Amazon s3. The only thing I can think of is a precompile thing, and then uploading the build.

<comment><USER19> I'm sure you know about static site generators like [https://jekyllrb.com/](https://jekyllrb.com/). Are those what you have in mind?

<comment><USER22> I have heard of them but I've yet to try them. I guess I'm trying to figure out if there's some way to basically duplicate the idea of an SPA (using client-side templating or whatever) without all the overhead. I think you're right, that static site generators fill that gap, or perhaps just server-side rendering with very little JavaScript on the frontend.

</comment></comment></comment></comment><comment><USER23> I'm mildly annoyed that images won't load properly with JS disabled due to lazy-load.js not running.

<comment><USER10> You'd think she would've thought of that on such a post. :P

EDIT: Isn't there also a way to pre-cache images with just CSS? o.o

</comment></comment><comment><USER24> This article makes the assumption that every decision you make as a web developer is unaffected by co-workers.

I'm all for progressive enhancement. However, if the expectation is a web _application_ that has a certain level of interactivity designed for, with a real world deadline, and a targeted demographic of "people with supercomputers in their pockets", I can guarantee you'll make some compromises.

Bringing up Springer Nature and the BBC as examples of the Web Built Right™ is short-sighted when they are web _sites_ that serve static content. Of course you should send HTML from the server that represents the entire content of the page, apply some CSS, and sprinkle in JS. And of course, there are a lot of developers out there that would reach for the latest trending JS library + framework combo to pull it off, and they'll implement it poorly.

There's very little point in bashing "npm install exciting-tech", when I can npm install gatsby-cli, and do everything the article is crying out for in a "modern" stack. Oh, also, the BBC example? They use Node, and React, and server-side render React[0]. You can bet they're npm installing exciting-tech.

However, the web is not just static sites anymore. People expect a lot more functionality, you work with people that design and promise a lot more interactivity, and there's a lot more people coding without enough experience to reach for the tech that is the most efficient solution to a problem.

I don't think a condescending article like this is beneficial for our community. Maybe we should try educating (nicely?) on how to pick the right tech for the problem[1]. Maybe we should ditch "user" for "person" (or "surfers" lol), when talking about the consumers of our output. And finally, maybe we should have more empathy of the people that work with our trade and work together towards a better internet.

[0] [http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-44...](http://www.bbc.co.uk/blogs/internet/entries/47a96d23-ae04-444e-808f-678e6809765d)

[1] [http://mcfunley.com/choose-boring-technology](http://mcfunley.com/choose- boring-technology)

<comment><USER25> I think the observation necessary for appreciating this article is that most sites that are built as SPAs these days aren't really web apps, they're still web pages. They're more similar to BBC and Springer Nature than to Google Sheets or LucidCharts. That's a property of the problem they're trying to solve. Building a web app where a web page would do shows total lack of interest about providing value to the user.

</comment></comment><comment><USER26> While it's a bit long and I don't agree with everything, the article raises important reminders for web development with empathy and accessibility. This part felt especially relevant:

"[Progressive enhancement] won't work with something like React though, and I don't cry about that. This is a distinct robust design pattern, which we feel is durable and doesn't lock us into a _limited-life framework that will get replaced by something else in a year or two_." (emphasis mine)

I imagine this last line gets some people reacting emotionally. I've spent the last few years in React-land (in addition to a soon-to-be-legacy stack slowly transitioning), and benefited much from the paradigm shift. It has moved the web (and web dev) forward in many ways, especially conceptually. At the same time, I can't deny that it will eventually get replaced, just like the rise and fall of jQuery. That means we must keep in mind not to be locked-in, to emphasize the core concepts which will outlive any framework du jour.

Progressive enhancement is certainly doable with server-rendered React, but it does seem like the recent trends have favored developer experience at the cost of user experience.

</comment><comment><USER27> (1) That's a clickbait headline

(2) I think "management" deserves some criticism here too. I think the average developer doesn't want to stick 15 different third-party trackers in a page, but they don't get much empathy when they bring it up with the "business" people.

</comment><comment><USER28> This is something I've wanted to mention for ages. A lot of modern web development seems to be about what's 'fun' for the developers rather than what works best for the company or user, and you can see it in the framework/tech obsession present in many companies and organisations. A lot of the time they don't need all React/Angular/Vue/Docker/Serverless/blockchain/whatever, they just need a simple CRUD system that lets them input content and have it shown to the user in plain HTML/CSS. But that's not 'fun', it doesn't get them respect on Twitter or at conferences (or on Hacker News) and makes it hard to hire programmers for, so hey, let's overengineer everything and pretend our blog is freaking Google.

Still, over engineering sites and products because you want work to be 'fun' isn't exactly exclusive to web developers. Quite a few game designers have similar issues in that field, and I suspect there's a bit of a clash in ideals between creators and audiences overall. It's rare you find a creator of any kind who just wants to do the same thing over and over and works solely for the money, and that's the cause behind all these issues.

</comment><comment><USER10> This is a great article, even though the irony of the layout seeming to waste a lot of space/have a lot of whitespace/doesn't look/feel right on my mobile isn't lost on me, the content makes up for it. :)

</comment><comment><USER29> And this server-side website takes 20 seconds to load. Imagine every interaction with a web app taking this long.

At this point the web is documents and also an application platform. Conflating the two causes trouble - sure, simple documents don't need JS, but non-trivial webapps really benefit from dynamic UIs/data vs old-school form post interactions.

<comment><USER30> And if you disable Javascript, all the images are _really_ blurry. This can't be for page loading speed, as they are all small images that would be not more than a few kB.

</comment></comment><comment><USER31> I really like this article but I struggle with implementing it now.

I've learned a lot of React recently for creating sites. I test all pages that can be static with javscript disabled, (I use gatsby or next for html ssr), but some parts can't be static, or worse there's still the "webpack inlines from hell" problem.

I would LOVE to replace my javascript powered pages with a templating language, and offer feature parity. But using a template language like Jinja2 for building component-based sites just doesn't work as well, unless I'm missing some magical secret sauce.

This is mostly for B2B web applications. I work on a lot of analytics dashboards that are pretty data dense. Even with react though, my sites never go over 400kb on load.

Okay, essentially my question is: what templating language/server framework can replace react, jsx, and graphql for webapps? I really want something like that.

<comment><USER2> I'm not sure I understand your requirements, but couldn't you just use JSX as your templating language and render React server-side? [https://stackoverflow.com/questions/25777931/server- renderin...](https://stackoverflow.com/questions/25777931/server-rendering- react-js-on-a-static-website)

</comment></comment><comment><USER32> I generally agree with the author's statements, but the analogies to cars and doorknobs to me were just inaccurate. There are a number of reasons why you want round doorknobs instead of levers, one of which is security, as levered doorknobs are trivial to turn from the outside of the door.

Secondly, just because everyone has access to every website on the internet does not mean you need to build your website for everyone. If someone says their website is targeted at a specific group, they build it for that specific group. You wouldn't tell a formula 1 engineer to raise the suspension on the car he's building so it can clear speedbumps in the parking lot.

Again, The core concepts of the article are common-sense, but the tone and specifics don't resonate with me.

<comment><USER3> >I generally agree with the author's statements, but the analogies to cars and doorknobs to me were just inaccurate. There are a number of reasons why you want round doorknobs instead of levers, one of which is security, as levered doorknobs are trivial to turn from the outside of the door.

Wait, what? I can't find anything about door levers having this kind of security risk. This kind of sounds like voodoo security where "worse UI = better security, because fewer thieves know how to use it".

>Secondly, just because everyone has access to every website on the internet does not mean you need to build your website for everyone. If someone says their website is targeted at a specific group, they build it for that specific group. You wouldn't tell a formula 1 engineer to raise the suspension on the car he's building so it can clear speedbumps in the parking lot.

Sure, but most sites aren't narrowly targeting people who can see and who have the latest hardware as part of their core reason-for-existence. News sites certainly aren't, and yet their mobile and screenreader experience is cancer.

<comment><USER32> >Wait, what? I can't find anything about door levers having this kind of security risk.

I specifically remember this talk: [https://www.youtube.com/watch?v=rnmcRTnTNC8](https://www.youtube.com/watch?v=rnmcRTnTNC8)

at around 18 minutes in he shows one of his employees(?) use a long bit of wire to pull the lever and open the door in a matter of seconds.

<comment><USER3> He shows the _result_ of it, yes, but it's not that easy to have a wire go through a small hole and reach up to grip something and pull. Most outside apartment gates operate on that assumption.

<comment><USER32> There are a handful of videos where other pen-testers show the process from start to finish, and the space needed to get the wire through is not as much as you think.

<comment><USER3> Getting the wire through isn't the problem, it's controlling it afterward. Not surprisingly, the 90 minute video you linked didn't find time to show that part.

</comment></comment></comment></comment></comment></comment><comment><USER33> The last time this went up, someone made a comment about disabilities being relatively rare. I wanted to add a point here:

In the United States in 2015, 11 percent of noninstitutionalized adults reported having a disability (National Council on Disability (NCD). The Current State of Health Care for People with Disabilities).

Disability in mobility and in cognition were most frequently reported (5 percent). Data from the 2009 to 2012 National Health Interview Survey found that 11.6 percent of United States adults 18 to 64 years of age reported a disability (defined as serious difficulty with hearing, vision, cognitive ability, or mobility [walking or climbing stairs]).(MMWR Morb Mortal Wkly Rep. 2014 May;63(18):407-13.)

That makes disability more than 5x more common than being a natural blonde.

</comment><comment><USER34> This whole conversation baffles me. The web is a sloppily-evolved designed-by- committee sofa-bed, nobody will ever feel completely happy with it, and it shouldn't be any other way.

Most of the time I work on "web applications", where the difficult part is managing the _necessary_ complexity of the domain model and the user interfaces. JS and framework-happy architecture isn't perfect (not even close), but adding constraints like "the application must weigh less than a megabyte" or "the application must provide basic functions (?!) without JavaScript" turns what can be a fairly serious project into a clown-car pileup.

There's a faction of web people who want web applications to compete feature- for-feature with native apps. I'm closer to that camp for historical reasons, but I also understand that compromise on application features is completely worth it if the benefit is an (even partially) "open" platform for applications to build on.

But then there's this other faction of HTML purists who see the "true" web as necessarily document-based, declared with markup, typeset with CSS, and compatible with absolutely every computer system of the past 30 years. This makes perfect sense if you work for a magazine and see the web as a platform for open (and often static) content, and I'm sure some of them do understand the difficulty and the value of compromise, but I _never_ hear that.

So now it's 2018, the "beat native apps" camp and the "documents for all" camp talk past each other through the years and nothing really changes. Maybe some people are in _both_ camps and suffering from cognitive dissonance, who knows.

But there are good reasons why web applications don't do what Photoshop does, and good reasons why Photoshop doesn't even try to provide copy-and-pasteable URLs for every unique application state. There are good reasons why "serious" declarative application frameworks (like XAML) are a terrifying mess, and good reasons why building a CMS from scratch in C++ would be insane.

</comment><comment><USER12> This starts off a bit get-of-my-lawn, but is a fantastic article with some very important points. Do yourself the favor of finishing it.

</comment><comment><USER35> Regarding the invention of the internet, they should have mentioned:

[https://en.wikipedia.org/wiki/Minitel](https://en.wikipedia.org/wiki/Minitel)

</comment><comment><USER36> Dear old lady shouting at clouds,

The web is not about me. But the websites I create are not for everyone. They are for my users.

My users are professionals, on desktop, with a mouse and keyboard.

Knowing who are my users allows me to do better design. I make the best experience for THEM. Not for you, nor for all your friends using different hardware.

It doesn't mean I don't care about loading time or how things are displayed on the screen. It means I do so knowing in which environments it will happen. And yes, it might means you will be excluded.

<comment><USER37> As the article mentions, what you're really saying here is that "my website is not for poor people, or disabled people, or even people who are trying to kill some time before their bus arrives". Is discriminating against these people ok with you?

<comment><USER10> >> My users are professionals, on desktop, with a mouse and keyboard.

>> Knowing who are my users allows me to do better design.

>> I do so knowing in which environments it will happen. And yes, it might means you will be excluded.

Obviously the poster here is more than okay with this. They're explicitly stating it will happen, and it's part of the plan.

The problem is when it's not part of the plan.

Imagine the author is writing an internal web tool for a corporate enterprise environment.

Imagine all of those computers and devices are standardized, and the software will only run on these devices on an intranet.

The previous poster's point is valid here. We know the users, the users are professionals, we know who they are, and we know what environments we'll be deploying in.

Therefore, of course, beyond accessibility, of course the poster wouldn't care about people trying to kill time before the bus.

<comment><USER38> Exactly this. I would even hazard that the majority of developers are working on things for intranets in a narrow corporate context where, if it can run on non-standard gear, that's an added liability with no significant business benefit. Businesses are only moving away from their decade old Flash and "IE only" web apps because the marginal security risk combined with maintenance burden has begun to outweigh the costs of new development.

</comment></comment></comment></comment><comment><USER39> The end result of this line of thinking is software guilds. Professionals being more accountable to their guild than to their boss. And the guild deciding who can and can't be a programmer.

It gets worse. In order to deliver on those promises, the guild now has to decide what framework to use, which UI elements are worthwhile. We're politicizing our jobs, and the only way to solve political problems is with government. Enter the web programming guild.

<comment><USER40> The flip side of this is: currently, most engineering fields require you to have some kind of professional certification (eg. a PE) from an industry "guild", eg. the ASCE. Software engineers don't really have a functional equivalent. We demand that professional engineers build our bridges, but we'll pretty much let anyone build our software. At some point, changing that may be the responsible thing to do.

<comment><USER39> I'll be the first one to get my guild card, but I really hope we think this thing through.

</comment></comment></comment><comment><USER41> Why do developers always get blamed for the state of everything? Developers love creating efficient, optimized solutions. Developer happiness is rooted in a feeling of fulfillment that comes from creating a good product.

There are many parties involved in designing the web, and developers aren't typically viewed as the subject-matter experts on how the UI of the web should work -- just on how to implement what's already been decided.

<comment><USER42> Do they? I know several developers that love crafting incredibly intricate and clever solutions that show off how good they are at functional programming/algorithm design etc.

One place I worked at had an API with an "unfixable" 120ms delay on every request that persisted until someone ripped out the beautiful ORM system and replaced it with 3 SQL queries.

<comment><USER41> You're absolutely right, many developers seem only to want to pigeon-hole a particular use case into the newest framework or technology they want to learn. I guess it depends on the developer.

</comment></comment></comment><comment><USER43> >It is this flirty declarative nature makes HTML so incredibly robust. Just look at this video. It shows me pulling chunks out of the Amazon homepage as I browse it, while the page continues to run.

This is actually really really bad. HTML renderers should have been designed to immediately fail when incorrect. This allows developers to more easily write correct and robust code rather than making the browser be robust. If the web were designed this way, you'd have a world where only correct html is written.

Also its not like we are not engineering a war machine here. Machines like the warthog are designed to keep functioning when components are destroyed. This is not necessary for html as we are not sending our html into a war zone. Sections of your html are not actively being removed/destroyed by users.

The author later compares html to javascript. Seriously. Javascript is a whole different ballgame. Javascript is bad because there are many hidden states of failure that aren't apparent. In HTML there are only two states, failure or success. If HTML failed as soon as it's incorrect, you will know immediately. Nothing is hidden. In javascript, incorrect logic can lay buried until a specific use case is hit.

That being said, he mentions stuff about the pyramid model for the web which is fine. I can agree with having javascript as the tip of that pyramid.

<comment><USER10> >> If the web were designed this way, you'd have a world where only correct html is written.

You'd also potentially be looking at a web that is far more unstable and crash-prone if you essentially treated a browser like a compiler or the like.

<comment><USER43> The creator of the html page will typically look at the website before he publishes it, so unlikely that someone will publish incorrect html code. It's not like html has branching logic so there's no hidden crashes, everything is explicit similar to the safety you get with type checking.

javascript is actually bad for the same reasons. It tries to correct your mistakes by doing type coercion making a null + 1 + 'blah'= "null1blah"

</comment></comment></comment><comment><USER44> > Despite what Tim Berners-Lee claims, the Web wasn't a single invention 1. > Yes, we know that one man says that he invented it (grudging thanks to Tim), > but he did so on the back of a thousand other technologies

He got that right.. Wish the media would do the same

</comment><comment><USER45> "email@example.com" \- that's really not necessary now is it?

</comment><comment><USER46> Most of projects are shitty. Because devs are failed at reusing abstractions, which lead to increasing complexity as project grows. Reusing abstraction into useful libraries is what devs should do, not features implementation.

</comment><comment><USER47> Dear writer, I am forwarding this to my product lead, and going back to Jira.

</comment><comment><USER48> Excellent talk, and we need more of this. Look at downloading and image instead of installing something on a raspberry pi. Next thing I expect is needing docker to install a calculator.

</comment><comment><USER49> Sheesh the format of this article is dreadful.

</comment><comment><USER50> Clickbait title, but I'll support anything that encourages empathy toward users.

</comment><comment><USER51> Hear, hear!

</comment><comment><USER52> from [http://slashdot.org/comments.pl?sid=5025417&cid=46736661](http://slashdot.org/comments.pl?sid=5025417&cid=46736661)

> The internet was our garden. And a beautiful garden it was. Sure, some fed > agency created it, but let's face it, they used a fraction of the lot and we > didn't really care for their supersecret bases they had littered about. > There was so much empty space in between! And that lot we cultivated. We > built a few nice trees and in their shadows we relaxed, we planted beautiful > roses and yes, a few fruits and vegetables because, hey, it's always better > if you grow it yourself. And ... heh, well, yeah, we had a few corners here > or there where we grew that "special weed", ya know, but nobody really gave > a shit, it was just us.

> We were pretty good gardeners. Well, you pretty much had to be in those > days, if you didn't know your way 'round with rake and shovel, you didn't > really get much out of it. Still, we were quite happy with it. So happy > actually that we thought we should share that. I mean, there's so many > people out there who don't even know just how great the garden is! And we > invited them in. They looked around and, well, most of them didn't quite > "get" it. Sure, it was nice, here or there, well, if you're into botany, > that is, but it's kinda hard to get around and find your way through the > jungle, and using a machete wherever you go, phew, hard work! But a few of > them stayed. They didn't quite know what they do, but we handed them a few > saplings and some seed and some actually managed to learn a thing or two > about gardening. Sure, of course a few smartasses tried to steal our stuff, > but we usually didn't have much of a problem to whack them with our shovel > and get our stuff back. And, heh, yeah, we, too, went into each other's > yards and played some pranks on each other, painted their roses black and > the like, but it was all in good fun! And hey, they sure liked our ... ya > know, "special stuff". They still had no idea how to grow it, but they were > quite willing to help us share everything with everyone, as long as they got > their share, too. And, well, why not, pass the blunt!

> That was about when the corporations noticed that, hey, where did all the > people go? They took a look at the garden and they went batshit crazy. I > mean, sure, we knew that it's great, but we never saw anyone go so insane > about it. They saw it as the next big thing to make money with, and we > laughed. Money? With this? Dude, you can't make money out of a system based > on freedom and sharing! Everything in here is free. Yeah, in _both_ ways.

> True. You can't make money in such a system. Unless of course you change the > rules. And changing the rules, they could.

> I can't help but think that this must be how the natives of the US felt > after they were "discovered". Because we had to face that there are suddenly > areas in what we considered OUR garden where we couldn't go anymore. Worse, > something that was the staple of our culture, going to a guy who did > something great and asking him for a sapling of his wonderful tree. Became > anathema. Instead of you SHOULD imitate and build on top of mine, the new > creed was you MUST NOT. This rule, of course, did only surface after they > themselves took from our gardens what they could possible rake together > quickly. You might understand our utter disbelief and of course outrage when > we noticed that turnabout is not fair game.

> Well, we have had our share of trolls and nuisances before. Long before we > already had to deal with people who trampled through our gardens or were a > general pest. Our solution was simple, we took our superior gardening skills > and whacked them from here to next week with our shovels 'til they either > learned to play nice or left for good. This didn't work out so well this > time. No, not because they had the better gardeners. But they didn't need > to. They had a much more powerful weapon in their arsenal: The law. First, > they ensured that the laws would benefit them, and then they used it against > us. And despite how despicable it may be, we have to admit that it is quite > efficient to have others take care of your battles, especially when you know > that you cannot win a conventional war.

> And now we're sitting here in what's left of our once beautiful garden. The > once mighty jungle has been tamed and civilized, what used to be interesting > and a land for explorers is now divided into lots that you may buy instead > of simply use. You can get there easier now... well, if you prefer using > long winding roads to a direct route, but the long winding roads are > necessary so you pass by all the billboards that block your view to what's > really interesting. Of course you may not step anywhere, only where you're > allowed to, and don't even think about taking anything, rest assured it's > for sale, not free.

> So we're sitting here now, at the edge of something we once knew as > beautiful and free. We're looking at it and we wonder what we did wrong. > Where did we fail? And I can only come up with one solution for when we try > something like this again: Don't invite the masses in. Keep it to yourself. > It's the only way how you can really keep it. And the only way you can do > without a camo net over your herb garden.

</comment><comment><USER53> Seeing the responses to this post just further adds to my conviction that the web is dead.

You can't rely on websites being futureproof or adaptable to different situations.

You can't rely on content being accessable to everyone. Nor can you count on content being available forever anymore.

Sites are blocked or throttled by ISPs and governments. Sites are expected to censore they're content. Even search results are being censored.

You can't trust in even the most basic assumption of privacy or anonymity. Everything you do is being tracked and sold.

So many social networks require your phone number. So many sites need you to login or need your email.

It's all one big get rich quick market.

</comment><comment><USER54> Very negative and condescending article in my view. Why would you spend time and money optimizing for a tiny percentage of users? Also they always underestimate the amount of power you gain by using frameworks like React and the amount of features and interactivity required when building modern web applications.

I'm not going to spend weeks hand coding some progressive enhancement in vanilla JS so some angry blogger can view my stuff in a console based browser with no JS.

It's like these people think that developer time is an infinite resource. Old woman yells at cloud indeed.

<comment> maze-le >> Why would you spend time and money optimizing for a tiny percentage of users?

I also didn't like the tone of the article. And some arguments were pretty far fetched if you ask me. But this is actually a very valid point. Its not very hard to optimize websites for accessibility -- but its almost never a hard requirement except for government websites.

Oh and, one thing I found particularly interesting about this site:

\</comment></comment><comment>-

90 requests

442.57 KB / 444.68 KB transferred

Finish: 4.43 s

<comment><USER55> Well, the page really loads in three requests, minus the images. It lazy-loads the images and player afterward (and drops them into the page without reflowing). It looks like the the images come in document order, too, so the visible part of the page is fully ready to view, images, included, before all the images load.

Something is a little screwy with the page though -- the main HTML page, which is 27K, takes two seconds. Some infrastructure somewhere could be running/configured better.

</comment></comment><comment><USER56> > people turning off JS (Yes people do this. Yes it's totally valid, and their > right as a user).

Fine, and they can go somewhere else. I'm sorry but I'm not about to consider this TINY percentage of users the same way I don't consider the TINY percentage of people accessing sites I work on from horribly outdated browsers.

The next sentence applies to web APPS, not blogs/news sites/etc.

People that say websites should gracefully fallback to non-JS web app when a user accesses the website with JS disabled are crazy. FULL STOP. PERIOD. You either end up dumbing down the entire experience for everyone OR maintaining 2 websites. Neither of which is financially sound for the vast majority of companies/developers given the percentage of people who don't use JS.

<comment><USER57> A similarly tiny percentage of your users are blind. Another tiny percentage are dyslexic. How many different tiny percentages can you justifiably invite to "go somewhere else"?

<comment><USER5> For a business, at least in the United States, this is basically a financial projection problem. Unlike brick and mortar stores, there is no requirement to make web content accessible to handicapped people.

<comment><USER58> Why does their need to be a requirement? Making a website accessible to individuals using screen readers is the right thing to do; it shouldn't need to be mandated.

<comment><USER5> I'm not saying there does need to be a requirement.

Businesses are not charity. If it doesn't make financial sense to make their website accessible, then they won't unless they're forced to. I'm making no value judgments, this is simply the reality on the ground.

<comment><USER59> > Businesses are not charity […] I'm making no value judgements

… except that you appear to adjudge a negative financial value to accessibility compliance, when in fact the opposite is true.</comment></comment></comment></comment></comment></comment>


Ask HN: Why does my keyboard always get dirty around the letter T? - <AUTHOR> I've been noticing this for years: I've had various laptops, and with each of them dirt accumulates around the sides of the letter T, or mostly around the RTY-FGH letter group.<p>Is there an explanation for this? Have you experienced something similar? <comment><USER2> Is it because it's the keys your forefingers touch - and they are what you use when eating food with your hands?

</comment><comment><USER3> Just had a look at my keyboard and yup</comment>


Ask HN: what is the best Hacker News client for iPad? - <AUTHOR> I am trying some from Apple Store, but I did not find a really good one. <comment><USER2> the web browser?

i can't think of a single "app" which is better than a mediocre web site.</comment>


Division Worksheets for kids - <AUTHOR> http://division-worksheets.com

<comment><USER2> Cool division worksheets for free. Kids learn division step by step.</comment>