In web design, everything easy is hard again - <AUTHOR> https://frankchimero.com/writing/everything-easy-is-hard-again/ <comment><USER2> There is a difference between web design and web application development. If you are a designer making brochure sites for small business, you don't need the modern frameworks and toolkits, and you are over-engineering it if you use them.

Everyone needs to take a step back and ask why they are building a web site in the first place. My local hair salon really just needs a brochure, and maybe a scheduling widget. A doctors office would need to add on a payment system. Both of which can be achieved by pulling in a script to use a 3rd party solution, while the core web site can remain plain, static HTML... done in Notepad, if you want to get really simple.

When you step up to needing some actual functionality, there still is a line in the sand where a few PHP scripts will do the job, and can just be pushed up to a shared web host.

When you cross that line, THEN you need modern tools. And many sites will need to go there. But a boutique design firm should be able to go a long way without, and probably could just hire some devs if they do land a project large and complex enough to need that level of code.

Just because you can go complex doesn't mean you should.

<comment><USER3> _> There is a difference between web design and web application development._

His essay isn't really about documents vs apps.

It's about documents vs documents. Or more accurately, he's lamenting about docs_simplesyntax vs docs_complicatedsyntax.

He shows an example of easy HTML syntax[1] that harkens back to "simpler times" in the olden days:

      <html>
      <head>
      <title>My First Web Page</title>
      </head>
      <body>
      My First Web Page
      </body>
      </html>

The problem with that is people want to author documents (not apps) that are _more complicated_ (prettier, aesthetically pleasing column layouts, gradient backgrounds, drop caps, dynamic resizing of frames, and so on) that require more knowledge than his "hello world" type of simple HTML.

Even a web "document" like the wikipedia page on The Beatles[2] requires quite a bit of complexity and advanced HTML knowledge. I've been writing HTML on and off for 20 years and I'd have to do quite a bit of googling and stackoverflow research to replicate that wikipedia page.

[1] [https://frankchimero.com/writing/everything-easy-is-hard- aga...](https://frankchimero.com/writing/everything-easy-is-hard- again/images/notepad.gif)

[2] [https://en.wikipedia.org/wiki/The_Beatles#Controversy,_final...](https://en.wikipedia.org/wiki/The_Beatles#Controversy,_final_tour_and_Revolver)

<comment><USER4> I agreed with you until you mentioned that the problem stemmed from _people want[ing] to author documents (not apps) that are more complicated..._ , thus implying that to make "pretty, fancy" web pages you need to complicate the process of creation: I totally disagree with that premise and think that it's entirely possible to create complex looking and behaving web pages without complex code or processes.

However, for the sake of convenience (mostly), people have accepted the use of 15 different toolkits as the normal prerequisite to creating websites. Why add a one liner JS script in the head when you can npm install it, etc...

Writing html and css like the old days is just as possible today as it was back then, and you now even have better tools to do so (Html 5, CSS 3). It's just a matter of actively choosing to do so.

<comment><USER5> GOOD! Thanks, I needed that!

For the Web pages for my startup, I just started with what I wanted the pages to look like. Then I calculated where everything should be. I looked at this as a special case of _layout_ in word processing, e.g., D. Knuth's TeX.

Then I turned to HTML and saw tables. Okay, the HTML table constructs are nice, sorry D., nicer than in TeX. So, I decided to use tables.

I heard about CSS, but I saw only a little need for that. Eventually I wrote a few lines of CSS. So, sure, I discovered that I could have separate CSS files, but that seemed like a way to slow the upload to the users. So, I just copied the CSS into the HTML code of the relevant Web pages.

For the rest, I saw how to use the Microsoft .NET ASP.NET to create and send the pages with the appropriate _dynamic_ content, e.g., the results for the user.

I heard about JavaScript but saw no big need for it and so far have written not even a single line of it. Eventually I discovered that somehow ASP.NET writes a little JavaScript for me, maybe having something to do with cursor positioning -- maybe convenient and nice but not really necessary.

For the page designs, they are simple -- high contrast, large fonts, simple parts and pieces easy to understand right away, each page exactly 800 pixels wide, no icons, pull-downs, pop-ups, roll-overs, or overlays. There are some links, but each one is just a word in English.

The pages all have both horizontal and vertical scroll bars and should still be usable in a window only 300 pixels wide. So, the pages, without change, should look good on everything from a smartphone to a high end desktop. The user just needs a Web browser up to date as of maybe 10 years ago -- so, there should be no compatiblity problems. And, there are no user IDs, passwords, logins, or use of cookies! JavaScript is optional!

There really are some really simple, really successful Web pages on the Internet. So, sometimes simple can be good enough!!!

</comment></comment></comment></comment><comment><USER6> html, css, and jQuery work just about exactly the same as they did a decade ago, nothing stops you from using tools you already understand.

If it was up to facebook then react would be the only framework used on the web; problem solved right? In reality, there are different tools for different needs and if you don't understand the specific problems a tool was made to solve then of course you're going to find it confusing.

Just because a tool exists doesn't mean you have to use it. These tools were created to solve specific problems that the creators encountered, if you don't have that problem or don't like the solution then why did you pick the tool?

The most baffling part is the strange sense of entitlement as if people releasing their work for free on the internet is a _burden_ to some because now they have to decide if they should use this free option.

If you want ES6, typescript, flow, components, css modules, SSR, hot code reloading, "universal" code re-use, postcss, bundling, automatic-code splitting, dead code elimination blah blah blah then that's on _YOU_. Don't blame the tools because you are enticed by their capabilities but not willing to understand why and how they work. If you don't care about that stuff then problem solved: don't bother with them.

<comment><USER7> > blah blah blah

The real problem here is that all these comp sci "geniuses" want to make a name for themselves with a "real" project and so they create all these garbage tools (compilers, pre-processors, etc) that make things worse by introducing and encouraging more complexity when just using plain JS would work better.

A lot of them are Java/C++ people with no experience in web development who see the simplicity of JS as a flaw and want to recreate the s--tshow they are used to working with because the complexity makes them feel smart and special.

That is just human nature though. The same argument has been going on for decades between C and C++ people. Nothing new here.

<comment><USER8> JavaScript static typing, promises, and modularization via imports are very useful—you just pay for them with a compile step. If you don't want those features, don't pay for them.

</comment></comment></comment><comment><USER9> I completely share the thoughts of the author of this article. However, I'm not sure if his proposed solution would work for most people. It's not that I want or like to use npm etc. - I'm forced to use them as it's the new default way of working with almost anything useful in today's web development work. An alternative would be to start from scratch - and then reinventing all these things again, making another full circle.

There could be another solution. A lot of today's complexity of the web stems from the fact that we're trying to design (web) apps using (HTML) documents. It's like building user interfaces in Word (without VBA). You can, but there are much better ways to do it. Why not to define a set of APIs for creating GUIs? Yes, I mean something like XUL which failed because nobody except Mozilla cared. Make it standard, make it easily themeable, and we can finally throw away this mess of ugly hacks used now to create intricate GUIs for which we have dedicated widgets on the desktop and which we have to reimplement on the web, with mixed results.

<comment><USER10> I disagree with the often-heard premise that HTML is a somehow inferior tool for creating GUIs that we somehow ended up with despite better choices beings available.

Yes, native GUI frameworks and widget toolkits like Swing, Qt, Cocoa and MFC have their place but it's precisely the nature and features of HTML (most notably: The link) that enabled most of the innovation we've seen on the web.

If building web apps was just about recreating the desktop experience but on the web doing that with HTML indeed would be a fool's errand. However, web applications today are so much more than their desktop equivalents from the 80s and 90s both in terms of what's possible with them and as to how accessible they are to developers.

Sure, developing a web app today is not as easy anymore as "View source", edit and see what happens but it's still a lot more accessible than developing desktop-style applications.

In my opinion, instead of throwing the baby out with bathwater and replacing HTML with something else (which frankly and fortunately won't happen anyway because let's face it: HTML is here to stay for some time whether you like it or not) we should try and think about how to make web development easy and accessible again.

I think tools like StackBlitz ( [https://stackblitz.com/](https://stackblitz.com/) ) are good first steps in that direction because they allow you to quickly try out and prototype stuff without having to care about setup and tooling.

What I'd love to see is the web equivalent of the C64 BASIC prompt, which provided you with an empty canvas to create something with right away.

<comment><USER9> > However, web applications today are so much more than their desktop > equivalents from the 80s and 90s both in terms of what's possible with them > and as to how accessible they are to developers.

Could you elaborate on that? From the point of view of the user, an app from the 90s works much faster than Google Docs. From developer's point of view, using a visual widget in an app was as simple as dropping it on a form, and then setting some properties if needed, either visually or via code. Nowadays you can do it with Lazarus and it will generate code for different platforms.

Look at this from another angle: The fact that the most powerful web company today with some of the most brilliant minds can't create spreadsheet software that would work equally fast as its desktop counterpart already says a lot about the tools we're using. Some people can't acknowledge it and miss the point completely and say "browsers are slow", trying all possible optimizations - but these are all hacks, not solutions to the underlying problem.

<comment><USER10> Yes, the 90s app is faster but can it consume and provide data over a network? Does it afford collaborative editing? Sharing data with others?

You can now even use Google Sheets for creating web applications much like Excel has been used for creating desktop applications.

Lazarus and Delphi in general certainly are great tools but they're also limited in terms of what types of user interfaces you can create with them. There probably aren't many faster ways of creating single-user CRUD applications but once you have to roll out an application to multiple users who are supposed to use the application over a network and in a collaborative fashion things start to look different.

As for the other angle I consider Excel (and the concept of spreadsheet software in general) one of the single most remarkable pieces of software created so far. Creating a fully-fledged spreadsheet application is no small feat. Then, let's not forget, Google Sheets is free whereas Microsoft makes significant revenue with their Office products, which would explain their motivation to create the best and fastest version of their product they possibly can while Google seems to be trailing behind.

<comment><USER11> > _Yes, the 90s app is faster but can it consume and provide data over a > network?_

Yes, AFAIK, though I haven't used the features much.

> _Does it afford collaborative editing?_

That's a new one, but probably less difficult to bolt on top of a desktop app than to make a desktop app in a browser.

> _Sharing data with others?_

Yes! Current model is actually a _huge regression_ here. On the desktop, you have a file system. You can share files. In the cloud, each application defines its own half-assed abstraction over data storage, and you're limited to what the service allows you and/or the company was bothered to implement.

The problem with the web application is, unfortunately, a mix of multiple big issues. Browser becoming a worse-is-better incrementally evolved runtime for applications. A shitty technology (JS) used as the main language of said runtime. User-hostile business practices that became easy - and thus popular - to implement on the web. And the very popularity itself, which sucks out oxygen from more sane areas of computing and tries to port bad engineering everywhere.

<comment><USER10> > You can share files. In the cloud, each application defines its own half- > assed abstraction over data storage, and you're limited to what the service > allows you and/or the company was bothered to implement.

proposal-2-final-new-FINAL-draft-02-2018.docx isn't exactly sane data-sharing. With desktop environments you could use a version control system for that but that hardly ever happens in a consistent manner.

You can create walled gardens both on the desktop and the web. That's a question of ethics not technology.

<comment><USER11> > _proposal-2-final-new-FINAL-draft-02-2018.docx isn 't exactly sane data- > sharing_

It is, when you can freely move it onto a USB drive, or attach to an e-mail, an IM message, or transmit over countless other systems that have no relation with Microsoft Office.

> _You can create walled gardens both on the desktop and the web. That 's a > question of ethics not technology._

Yes, but that's pretty much a tautology. Technology is all about making stuff easier, and web is pretty enabling when it comes to walled gardens and other unethical conduct.

Ultimately, the web is what _killed_ end-user open source. A web application is an ultimate anathema to both open source and free software - you don't get to run the program as you like, you can't inspect it in any way (even if it's "open sourced", you can't verify if this is what really runs on third-party server), you can't distribute it, you can't modify it, and to top it off, you no longer own the data you work on with said software.

<comment><USER9> > Ultimately, the web is what killed end-user open source. A web application > is an ultimate anathema to both open source and free software - you don't > get to run the program as you like, you can't inspect it in any way (even if > it's "open sourced", you can't verify if this is what really runs on third- > party server), you can't distribute it, you can't modify it, and to top it > off, you no longer own the data you work on with said software.

On the other hand, there are many people who are aware of that and are actively using, developing and promoting the so-called "self-hosted" solutions - that is, completely free and open software that is in direct competition with closed web apps.

Have a problem with a commercial, closed solution? Look here: [https://github.com/Kickball/awesome- selfhosted](https://github.com/Kickball/awesome-selfhosted) Still haven't found what you need? You're always free to create one on your own. So you can't really argue that it is the web that "killed" end-user open source as it's very much alive, from VLC to WordPress.

<comment><USER11> Holy shit, that list is big! Thanks for it.

</comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER12> >simply npm your webpack via grunt with vue babel or bower to react asdfjkl;lkdhgxdlciuhw

>[...]

>I had to install a package manager to install a package manager.

And that's coming from a designer, not a programmer.

A few years ago I had to take over a project that required installing something like 6 different package managers, 2 build systems, and a dozen different languages (counting things like jade and coffeescript), including dependencies that somehow required conflicting versions of the same libraries! (It took building pieces of it on 2 separate VMs and then merging them to get it to work.) All to build what turned out to be a simple little web site that in the end was basically 12 static pages and a simple form. That doesn't make things way easier.

When I started programming, the key important things were to focus on getting the data model accurate, getting the business logic correct, validating input properly, and producing the desired output. Now that is maybe 5-10% of our workload, the other 90+% is dealing with dependencies, build tools, frameworks, 57 layers of generic abstraction, and all the fragile interconnections and leaky abstractions and compatibility issues between all of those things needed primarily just to simply display a page of content or handle a CRUD form.

Sure, they're beautiful and interesting from an intellectual standpoint, and when they're working properly, they do make things that were once quite difficult a lot easier. But they also add a lot of complexity, require a lot of maintenance, and make the simple things much more complicated. Often, it's as if we're flying a squadron of helicopters down to the corner store to get milk (because isn't that cool and fun?!), and by the time the operation's completed and we've returned home and got all the helicopters repaired, we realize that we forgot the milk, or it's already spoiled, or we ended up with a potato instead.

I do love playing with the new toys. React is really cool, a lot of the new stuff is interesting. But all those layers, all that indirection, all that distances us from the domain data and business logic can make it a lot harder to solve real problems and produce real value. Sometimes I just want to build something and not have to deal with all that mess.

<comment><USER13> One of the best things about working for myself is that I write all my web stuff in vanilla JS.

While I occasionally make errors, they are easy to identify, understand, and debug because the native features of JS are well-understood by modern browsers.

Sometime in the last decade, modern web development moved on without me. I can no longer recognize what people are doing with all of these package managers and why they are doing it.

I guess from a corporate stand point, it makes sense. You'd want your developers to be like widgets or sprockets, easily replaceable. Hot swappable. Otherwise these guys might build Daedalus-like spaghetti-code mazes and no one will ever be able to replace them.

As a one-man operation, I'll stick with vanilla. It's easy to understand and it works forever.

<comment><USER14> Sure that works, especially if you tend to write more web sites than advanced web applications. But that is true for back end as well, a one man operation can write Python or Java in a style and using libraries from 10 years ago and it would work perfectly fine. But depending on what they are doing they might not be as productive as they could be.

If you want to try for example React it is incredibly easy to get started. Just if you want to check out what the fuzz is about.

[https://reactjs.org/tutorial/tutorial.html](https://reactjs.org/tutorial/tutorial.html)

<comment><USER15> This made me chuckle, since modern Python and Java styles are very, very similar, if not identical in places, to those of 10 years ago. Some of the libraries have changed, but many are the same as well. Shoot, I can still run Python code I wrote 10 years ago on the latest version (yep, that means something originally written for Python 2.3 _can_ run fine on Python 3.6).

And no, that doesn't make Python and Java old hat or redundant.

<comment><USER14> You can run 10 year old JavaScript as well, no problem. But Java written today is pretty different from Java written 10 years ago and the Java frameworks are very different.

My point is that you can write code in the style from 10 years ago in any stack but for some reason people seem to take pride in it in the JavaScript world just because they cannot be bothered the actually learn modern development. Not to mention they tend to exaggerate the difficulty of getting started. Compare the tooling, build chain and language features of a JavaScript stack with for example Java. It is not like the JavaScript one is more complicated.

You don't need something like React if you are doing a simple web page but a lot of people ARE building more advanced web applications these days and then it is probably best to just suck it up and learn a modern stack because the old ways of development is not really suited for it.

</comment></comment></comment></comment></comment><comment><USER16> Did anybody notice that the 1997's Hello World example [https://frankchimero.com/writing/everything-easy-is-hard- aga...](https://frankchimero.com/writing/everything-easy-is-hard- again/images/notepad.gif) still works? Open the most easy built-in text editor on your system (even on Android one should be able to do that, isn't it), save it, open it with your browser locally.

In some aspects, the evolution of the web is similar to what the C language ecosystem experienced. It was dead simple in the beginning --- however the "Hello World" is still the same! Today's users are more demanding in terms of user interfaces and you will not go far without libraries. Same story with building modern "reactive" websites.

I personally like that CSS got more powerful, it allows us to build modern websites without JavaScript. That wasn't possible 20 years ago.

<comment><USER17> 20 years ago was 1998. CSS _was_ the modern thing. JS was called DHTML and was used for mouse trailing bouncing balls. XMLHttpRequest debuted natively in IE6, which was released in 2001, before that, it was ActiveX and nobody used it.

You did create modern sites with CSS, without JS.

<comment><USER18> The days of the CSS Zen Garden. For me, the good old times.

[http://www.csszengarden.com/](http://www.csszengarden.com/)

<comment><USER16> Indeed! CSS Zen Garden was my holy grail 15 years ago.

</comment></comment></comment></comment><comment><USER19> I think it has a great deal to do with abandoning something simple not because it's not good enough to do the job, but because of fear of being left behind, fear of becoming irrelevant in a world where "new and improved" is introduced at an ever growing frequency.

Sure, improvement is a good thing, but the question I think we sometimes forget to ask ourselves is when does the cost involved in certain technological improvements (more learning curves, higher process complexity, energy required to stay on top of the rapidly changing technologies and tools etc.) start to become higher than the benefits produced by the so called improvement.

I've been in this field long enough to see how many times hype beats common sense, unnecessary complexity beats simplicity, and emotion beats logic (heck, I'd bet it's a common theme outside the technology sector as well) but I'm optimistic - the bottom line is that things are improving and even though things sometimes seem circular, it's more of an upward spiral.

</comment><comment><USER20> > There's a voice in the back of my head saying we're stuck in a loop and it's > repeating. We've completed a lap on a cycle which will go around forever. > Another approach for layout will come along five years from now, it will > probably resemble floats, and not knowing how to clear a float will bite me > in the ass for the second time in my career.

This is what I feel like everytime I try to keep up with web tech... For crissakes, the last training I went to had a session on Razor Pages, which set off my PTSD from years of doing ASP.NET WebForms, back before we decided that was a really awful, painful way to do things.

</comment><comment><USER21> This is an excellent piece of writing. The aphorism "Go slow and fix things." is brilliant. I'm stealing that.

I implore people reading this thread to watch this Alan Kay video from 1997, where he rather predicts (albeit perhaps implicitly, if not explicitly) that we will reach the situation we are in today.

[https://www.youtube.com/watch?v=oKg1hTOQXoY](https://www.youtube.com/watch?v=oKg1hTOQXoY)

There is a quote from the talk which rings true with many of the comments here "HTML on the internet has gone back to the dark ages, because it presupposes that there should be a browser which understands its formats"

I have found the odd nit with the article:

"In one way, it is easier to be inexperienced: you don't have to learn what is no longer relevant."

I think he might mean _unlearn_ , but it's a bit ambiguous. :-)

<comment><USER22> That talk is truly awesome. Thanks.

<comment><USER21> I'm glad you found it useful. Here's a related bonus link :-)

[https://www.quora.com/Is-there-a-programming-language- thats-...](https://www.quora.com/Is-there-a-programming-language-thats- effectively-a-successor-to-Smalltalk/answer/Alan-Kay-11)

Dr Kay has been loudly telling us for a long time that we are on the wrong track whilst having already delivered a complete alternative. One can only wonder what his perspective feels like.

</comment></comment></comment><comment><USER23> This is so true and I'm certain it's related to the noticeable downgrade in web performance and usability over the past five years. So many sites are flabby and slow now because they're retrieving countless packages from CDN's, each time of course with a ssh handshake, etc etc. You can see endless retrievals flashing on the bottom bar, sometimes literally never stopping, as the site keeps doing one thing after another to anticipate what you might want to do, load new content, or whatever. I find the web only barely enjoyable to use anymore. Even the simplest things seem to blow up now, e.g. very often I get "not found" for the Google homepage. Huh? That one's probably on me somehow, but I'm not doing anything different that I know of, but what has changed that I know of is the extreme increase in complexity of internet delivery and programming. And I will just vent one more pet peeve. Not EVERY part of a web page needs to pop something up in your face when you put the mouse over it. Thank you.

</comment><comment><USER24> Actually that's pretty much what I would expect if I tried to build interactive applications on top of a declarative document format whose standardization was co-opted by the largest advertisement company, while working with novices straight out of last week's coding bootcamp eagerly reinventing the wheel out of their lack of experience and mentoring.

</comment><comment><USER25> By chance I ended up at the Berkshire Hathaway (Warren Buffets company, more like mega-conglomerate) website today.

[http://www.berkshirehathaway.com](http://www.berkshirehathaway.com)

If that site is good enough for one of the worlds most valuable corporations, maybe we're just massively over-doing the entire web?

Side note, I laughed really hard when I saw that they had a god damn ad hard- coded on the page hahaha. That's how you end up one of the richest investors of all time, waste nothing.

<comment><USER26> I came across that site probably seven years ago when I was going through Fortune 100 websites and looking at how they were approaching mobile web design, and I had a good laugh at this one. Glad to see they still haven't changed. :)

</comment></comment><comment><USER27> This is my experience of web development, every time I return to it.

I'm really not an expert in web dev, but it _feels_ like web dev has been badly engineered.

JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don't know much about programming language design, so they can't see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.

If you recognise JS as a terribly designed language, then the last thing you would imagine doing is widening its use. But that is exactly what node.js does. You should instead isolate JS and minimise its use. So red flag - something has gone wrong here.

It also feels that many web ecosystems have an over-inflated sense of self- importance. This has led to many competing frameworks for the same tasks, that try to do everything. Things are not pythonic. There appear to be an excessive number of package managers involved. There were already plenty of package managers out there - inventing new versions of existing tech makes it harder for everyone and is usually a red flag that someone somewhere is making bad decisions.

I need to build a website soon and I'm dreading the front end. At the back end I can use range of solid and well designed languages and technologies, but at the front end I feel like I've got to choose the least poor of a bunch of crazy options. If anyone has advice on how someone who prefers rigour, simplicity, elegance, and decent PL design over the latest trend should approach web dev that would be massively helpful. "Sane web dev to minimise the impact of the Web Dev CSS/JS disaster on your life" would be my favourite O'Reilly of all time.

<comment><USER28> Modern JavaScript is not a very badly designed programming language. It's a good, productive programming language. Most of the quirks can be disabled with a linter, and optionally a lot safety can be brought in with typing (using e.g. TypeScript).

On the other hand, many developers don't know much about programming and JavaScript, and therefore tend to have unjustified criticism of the language.

JavaScript was a perfect choice for Node.js. It's event-driven design is a perfect fit for a performant web server. Python would have been a bad choice, because it didn't support asynchronous programming when Node.js was created. Furthermore, using the same language in the backend and frontend will reduce context switching, enable code reuse and generally speaking improve implementation efficiency.

<comment><USER29> this is all wrong, sorry.

modern js is still js. the fact that linters are _required_ to keep code sane is proof enough. typescript is a different language, i'd wager it doesn't count, even though i agree it's a considerable improvement.

au contraire, many developers know exactly what programming in js looks like, especially compared to other languages. i used to think that c++ and boost compilation was crazy. now i look at glorified web pages with 200MB+ of dependencies and wonder how we got there.

i agree that js was a perfect choice for node.js, because it was the only choice for node.js - to use the same language that runs in the client. that doesn't make it a good - or even sane - choice in the greater perspective. python was and still is a good choice - twisted was used to create async services before ajax was a word. you can also take a guess from where the promise/deferred pattern took at least some of its inspiration.

<comment><USER30> > wonder how we got there

I fully blame the virtually non-existant standard build- and module system in C/C++/JS for a lot of the current problems.

This is one of the reason I really want to learn Rust. Compared to make/npm/gulp its infrastructure looks heavenly.

</comment></comment></comment></comment><comment><USER31> >Easy is hard again

>JavaScript is a very badly designed programming language (yes, even in its modern form), which I think has caused a lot of problems. Many JS developers don't know much about programming language design, so they can't see how bad it is, and they make matters worse by not trying to abstract or use JS in a way that reinforces good PL design methods.

I attribute much of this to the cargo culture that always dominated the webdev space. I lost count to how many seasoned devs (5+ year) I met who were telling me that "Framework A" is faster than vanilla JS and DOM with which they were built with, or array methods are for some reason faster than loops without function calls.

Another weak side of JS today is it being driven by "design by committee" and attempts to treat the patient by measuring the average body temperature of all patients in a hospital.

I put to doubt the level of basic CS proficiency of most JS framework authors. Some times they try to appear smarter than they are.

</comment><comment><USER32> Web apps are broken and always have been. The whole model was designed to serve and display static hyperlinked documents, not to recreate Excel in a browser.

The lure of web apps was serving them from a centrally controlled location thus eliminating the problems that existed with pushing out and updating software on many computers.

However, that problem was solved many years ago and I point to iTunes as that inflexion point. It's been easy to push updates to desktop clients for years so the main problem web apps were attempting to solve hasn't been a problem for, like, 15 years.

The ultimate irony... The phone app eco-system and how it dwarfs mobile web apps.

</comment><comment><USER33> Choice quotes:

> Directness is best in my experience, so a great photo, memorable > illustration, or pitch-perfect sentence does most of the work. Beyond that, > fancy implementation has never moved the needle much for my clients.

> Last month, I had to install a package manager to install a package manager.

...

I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we're there now on the web.

<comment><USER34> If I want to install Pip, Maven or what-have-you, I'd be using apt.

<comment><USER35> You don't install apt, it comes standard.

<comment><USER34> The point is that I'm using a package manager to install a package manager, which is supposedly bad.

</comment></comment></comment></comment><comment><USER36> When I worked in embedded systems and systems programming a decade ago, it was totally normal to spend over a day getting your computer set up after joining a new team.

Sounds exactly like what the author describes here, so what changed? What changed is that the browser became a popular application platform, forcing frontenders to deal with the stuff everybody else has been doing for decades.

I'm not saying this can't be improved, and there's a huge difference between projects in that respect. I know teams where getting up and running is a matter of installing node, yarn, and running a "yarn install" and It Just Works.

But the thing is, build tooling is hard and it always has been. This has little to do with web design, except that designers used to have the comfort to be able to ignore it. And that's harder with single-page web apps.

<comment><USER37> He's exaggerating. You can download a cli tool that lets you create a react or vue web app with Babel, webpack, hot code loading, etc in one command. It just works. I know because I just did it and built a large app from it . I think I added 3 lines to my webpack config to proxy api calls to me real web server. It's magical to code on the fly and I think people have a short memory or aren't old enough to remember hand coding make files and waiting 20 minutes for your app to compile and link.

Frameworks like vue.js are elegant as all hell and js has the lowest getting shit done to ceremony ratio of any language I've ever used.

Sure there's a few gotchas. Try using c++. Now there's a minefield.

</comment></comment><comment><USER38> I've almost never touched web development, but as an active HN reader I have at least passing familiarity with almost all the terms used in the article.

So, honest question: can a person fully understand how modern HTML/CSS work without diving in the source code of one of the browser engines? Because as a developer, if I was forced to use such a complicated technology, grooming source would be my best guess at making any sense out of it.

<comment><USER39> As as web developer the most important skill to learn is to let go! You fix it for whatever browsers the client uses and forget about the rest.

<comment><USER40> I suspect your parent comment isn't talking about browser compatibility. I suspect it is about learning enough CSS/HTML to write up a page for one browser without feeling like [venetian blind gif].

[https://imgur.com/gallery/Q3cUg29](https://imgur.com/gallery/Q3cUg29)

</comment></comment></comment><comment><USER41> I have found lately that many web things today are based on fads and they have found their way into the standards. In the past, standards were developed through engineering and computer science. Today it's based on fireworks, explosions and emojis. Speed trumps quality. Do not want to think is the motto or slogan.

If there is a framework or library I can use then, great, I don't have to know how it works so I won't bother seems to be the mantra today. Which, in my mind, reminds me of "All in the Family" scene where Gloria is talking to her friend. "Daddy said girls don't have sex, only boys do." Friend: "Then who do the boys have sex with?" Meaning, if no one is doing the thinking, who is going to write the code?

<comment><USER36> I wonder which recent new web standards you think are fads. Push notifications? Offline web apps? Multithreading? async/await?

<comment><USER41> Not a fad but an example of what I mean (and the only one I can think of this early in the morning). "box-sizing". This seems to have been created because people are unwilling or unable to understand the standard "box model". People find box-sizing is easier for them but it is not necessary as it only combines already available and well understood sizing properties.

Worse, many even use the '*' hack to apply it to every element on their site which should make one question forcing browsers to do something browsers don't do natively.

iirc, there was, or is, even an effort to make emojis part of the standard!

I hesitate to give any example at all because every person who doesn't know the box model will downvote my post for the very reason I gave in my original post.

<comment><USER42> Box-sizing is not a good example of a standard that was poorly engineered: it actually _fixes_ a poorly engineered standard instead.

I understand the box model, which is precisely why I think one should not have to perform mental padding calculations just to know how wide an element will be on screen. Content box sizing (the original standard) also makes CSS less composable (since the results of combining multiple classes are harder to account for). Ergonomics are a very important engineering consideration.

The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode) so does "use strict"; these are concessions one has to make when a platform evolves over 25 years and must remain backwards compatible.

<comment><USER41> I said nothing about poor engineering.

>one should not have to perform mental padding calculations just to know how wide an element will be on screen

This, and the paragraph, falls directly into my comment about not wanting to think or do the work.

>The <!DOCTYPE html> tag also forces the browser to "do something it doesn't do natively" (enter standards mode)

Bad example. Using a doctype was not originally required and was only forced into being by Microsoft not following the standard. Technically, one does not need a doctype at all but we were forced into using it so browsers know you want to be in "standards mode" and not "quirks", but this diverts from the topic.

<comment><USER42> My "poor engineering" remark was a response to your original comment stating that "In the past, standards were developed through engineering and computer science."

Re: "not wanting to think or do the work": why would _anyone_ want to think more or do extra work that is not required, except perhaps for fun? Computers were created precisely to automate and abstract away mundane tasks (such as adding padding measurements mentally). Only at Google/Facebook scales the extra bytes/CPU cycles added by setting box-sizing for all elements might perhaps make a difference. For everyone else the maintenance, time benefits of reducing the mental overhead imply on actual reduced costs, since you can ship your page/app faster.

<comment><USER41> My remark was in regard to my first statement about standards following fads but that does not mean the standard is poorly engineered.

My main point, again, falls back to people wanting things done for them because they don't take the time to learn how things works. They want things done for them and never learn the basics, the foundation of understanding. If one cannot figure out how to make an element a certain width using "width" \+ padding + border + margin because they never bothered to read the specification, or any of the multitude of online tutorials, where it is clearly explained that width is the containment area alone, then this is nothing more than plain laziness mixed with "give me teh codez".

</comment></comment></comment></comment></comment></comment></comment><comment><USER43> I've recently realised that most of modern day's web stem from the fact that it's _not a platform_. It's still just a barely functioning system to display text documents.

That's where all the complexity comes from: people are trying to build/collect the missing pieces of a platform, and then try to build their stuff on top of it.

And you can see it everywhere: from CSS (which still pretends that modularity doesn't exist or that complex constraints in layouts do not exist) to DOM (which hasn't seen a proper API design in years) to Javascript (whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest).

<comment><USER44> "(whose idea of a standard library is adding an underspecified `fetch` after 15 years of people writing wrappers around XMLHttpRequest)."

So true.

</comment></comment><comment><USER45> The whole thing is driven by all fields reaching the highest level of complexity their practitioners can understand.

Web design in not inherently complex, but it is filled with lots of talented and intelligent people because the pay is good and the conditions cushy compared to say gutting chickens in some factory. The only way to solve to the complexity treadmill is to drive out all the smart people.

<comment><USER46> We do have a tendency to make things as complex as we can, which if you are smart is too complex for the majority.

</comment></comment><comment><USER47> No it's not. You decided to make "easy" tasks complicated. Then rather than learning about new technology you wrote a blog moaning about it. Just stick the basics if that's what you want to do. No need for loaders or preprocessors if you don't want to use them.

</comment><comment><USER48> People should understand that html was a document markup language. This means the flow of text.

People are using it for applications too. Many websites are a combination of both:

A "frame" with navigational headers etc (application). And a document-view. This document view is what html was indented for.

The solution is to use this flex-box (which is simply tsacklayouts etc) for the application, and the document-flow for text.

edit: oh, and drop the javascripts

</comment><comment><USER49> I love the way that the the author, skirts totally over Javascript, and yet the threads here are full of mild skirmishing.

The closing paragraph is the nicest part of the article, mentioning the benefits of legibility.

I never disliked the mechanics of html table based layouts, col and row spans, what wasn't so nice was the attribute soup. That made reading the outlines of the html hard.

Back in the day we had tools like Dreamweaver, that had a visual design mode. It was quirky so people resorted to programming html in text editors. What's a real shame is that there wasn't a tool that matured to the point, where you could do a little of both.

The most interesting part about a website for me, is usually the content, and the rest is pretty much guff. The nicest thing about simple authoring is that it allows the on-boarding of everyone. Not just arty or programming types. This is why Facebook in part took off. Because it made publishing easy. Weeks, months and even years of development just to get to the point of publishing is rather wasteful. Many sites could simply use a template product.

Review the end result. Many web sites still just look not much more than, erm, web sites. And many don't work, or even convey or make the information that you simply want to consume easy to find and digest.

Loads of technology is thrown at problem, where a simple site map and text based content will suffice. And if a business isn't reactive to customer requests, or doesn't update relevant content - then a site becomes quite superfluous or even a liability.

</comment><comment><USER50> It's not hard to make websites, it hard to make _fashionable_ websites. It always takes effort to be fashionable, since it distinguishes your vitality from the dead and dying from yesteryear.

If it was easy to fake fashion, everyone would do it, and we'd lose the vitality signal. Fashion changes unpredictably, so it can't be anticipated. All this is a feature, not a bug, so it will never be "solved".

<comment><USER51> Love your comment.

</comment></comment><comment><USER52> As a back-end developer, I started off coding ~15 years ago, and hated the entire experience back then. Nowadays, as I look at the tools, frameworks and language enhancements, I'm so glad to be coding in 2018, and not in 2004. The things I can easily accomplish now, far exceed anything I could have done back then.

I've heard so many front-end developers/designers say the opposite about their field though, and I wonder why that is. If the newer tools/frameworks are just adding more complexity, or reinventing the wheel, couldn't you just choose not to use them? I suppose some might reply that you're forced to use these new tools/frameworks, because of dependencies on other tools/frameworks that you actually care about. But if that's really the case, and if this frustration is widespread enough, wouldn't people/companies have invested time and effort into supporting the classic-but-equally-good tooling?

As someone watching from the outside, I can't imagine a world where an entire industry is running in circles, creating churn devoid of positive value. Maybe I'm too optimistic, but I suspect that many of the complainers are suffering from rose-colored glasses. As a heavy web-user, I've noticed that the functionality and aesthetics of websites have improved _dramatically_ in the past 1-2 decades. The websites I see from the 90s and early 2000s, look like a joke today. I suspect that this improvement is only made possible by the new tooling and frameworks that exist today. That they are indeed more complex, but they still unlock new potential that would be too hard to achieve otherwise. That anyone who tries to use ancient tooling from 10-20 years ago, would find themselves unable to provide an equally good mass-market UX. If this is not the case, I invite someone to prove me wrong.

</comment><comment><USER53> When I'm thinking about bloated web frameworks and inefficient libraries, I often come back to memories of 64k demos released by groups such as Farbrausch. Here's what they've pulled off in 2000: [https://www.youtube.com/watch?v=Y3n3c_8Nn2Y](https://www.youtube.com/watch?v=Y3n3c_8Nn2Y) \- as somewhat of a "contrast", jQuery alone (3.0.0-alpha1, minified) weighs 84522 bytes.

Use (what you deem as) the right tool for the job. As to how we've got to where we are today, there are lots of reasons - but personally, I feel it's pointless to constantly talk about it. Whether things are more complex than they used to be is up for debate, it's entirely subjective.

It's natural for things to evolve given the rising popularity and increased demands - but they evolve organically. People flock to frameworks because there's abstraction, and the "dirty work" has been offloaded to a third-party. This saves people time and effort. It's a bet - frameworks come and go, maintainers disappear; that's just the nature of it.

</comment><comment><USER54> Addressing the points in the article:

"How do I put two things next to each other?" \- Just stick with flexbox. It's way easier than floats. If the older methods are easier, just keep using them no problem.

"Webfonts?" \- 10 years ago we were using "swfir" (flash) for custom fonts. Way harder than font-face. Loading fonts with @font-face doesn't need to be complicated: just serve the woff file and be done with it. There are some optimizations that can be done to make them load faster, but they're not always worth it.

SVGs are really nice because you don't need to deal with any resizing. A huge win.

Yes, raster images are a little harder because of high-dpi screens. Just send 2x resolution everywhere. Phones are where bandwidth really matters, and they're mostly high-dpi anyway. A 3x dpi phone getting a 2x image is still pretty good. Any of the more complicated solutions are just to make things slightly faster in some cases, which is often not worth it.

</comment><comment><USER55> I don't get all the ranting. I think the author would be better doing a research about the current technologies for doing websites (as opposed to web apps).

For websites I can recommend Bulma, it's an elegant base for modern websites. If you want to manage content for that website you can integrate Hugo an get into the world of static site generators.

If you really want to do anything more complex, there is Vue.js.

You can still use <table>s for layout if you want, there is nothing forcing you to use CSS Grid. But if you do learn it, you'll be able to produce more complex layouts with a little less effort.

There is a free course for that: [https://cssgrid.io/](https://cssgrid.io/)

I just moved my blog from WordPress to Hugo + Bulma and have been enjoying the journey all along: [https://lobotuerto.com](https://lobotuerto.com)

</comment><comment><USER56> Innovation often has casualities and the pace of innovation of the front end particularly has exploded in the last few years combine that with mobile uptake and we have a whole can of soup on our hands. At the moment it feels like we havent quite settled on a proposed standard of build tools and processes which comes across as daunting but imo is also indicative of not reaching the absolute peak. Underneath it all we still have the fundamentals of html css and js and that aint gonna change anytime soon.. I only hope some of the tools we have for layouts settle soon as the browser landscape and chasms are only getting wider as mobile devices and iot throws a whole new can of worms at producing cross browser compatible applications. In my instances that fact alone is choking the web.

</comment><comment><USER8> Much of the JavaScript ecosystem can be cringeworthy, but recent versions of JavaScript are far better than the days of ES3, and libraries like Babel are high-quality.

With modern improvements to XMLHttpRequest, the URL object, and JSX (actually quite easy to use without React), I suspect that creating a fast, modern website using only Babel, Yarn, and a few polyfills (mainly for IE) is quite easy and enjoyable. Of course, if you want a styled date field, autocomplete field, etc., you'll want to use a library, which may have its own dependencies.

As for CSS, everyone agrees that flexbox is a godsend.

<comment><USER57> "As for CSS, everyone agrees that flexbox is a godsend."

If flexbox is a godsend CSS Grid is God.

</comment></comment><comment><USER58> you still can write `<html><body><h1>hello world</h1></body></html>`, there is nothing wrong with it!

but once you have written a file-browser with an embedded editor in it or anything else at more complex level, you will consider using react and all the things. because complex things are complex.

again, for simple things you can easily use simple tools - maybe you should. but of course once you are using react day in day out because you need it for other things - you might just use it for anything because you are familiar with it.

</comment><comment><USER59> This is perhaps my favorite part:

" _If you go talk to a senior software developer, you'll probably hear them complain about spaghetti code. This is when code is overwrought, unorganized, opaque, and snarled with dependencies. I perked up when I heard the term used for the first time, because, while I can't identify spaghetti code as a designer, I sure as hell know about spaghetti workflows and spaghetti toolchains. It feels like we're there now on the web._ "

</comment><comment><USER60> It's rare that I say someone has truly nailed it, but the author has really nailed it. And while much of the critical response has focused on the difference between design and programming, I can say as someone who has been around the programming block (got started at age 9) that 99% of what he says applies equally well to modern application development and infrastructure.

</comment><comment><USER61> I'm spending my free time asking on web developer forums how to center something vertically.

</comment><comment><USER62> Maybe somewhat related: can anybody guess what the idea behind the images in this article is?

      <img src="/images/trans.gif" data-src="images/speaking.png">

trans.gif is just a 1x1px invisible pixel.

<comment><USER63> It's lazy loading the images - when the page initially loads, it only loads one small image (trans.gif), and the file specified in the data-src attribute isn't loaded until you scroll near to the img tag. Specifically, it's using this plugin: [http://luis-almeida.github.io/unveil/](http://luis- almeida.github.io/unveil/)

<comment><USER64> The given use of that on frankchimero.com is bad.

If I use uMatrix then even enabling scripts for the site won't show the images.

Moreover, if the javascript is turned off completely, the proper approach for the given task is having the

        <noscript

and the images properly specified.

One of the images is just a PNG of an emoji U+1F632 (my guess). Another of the emoji of the cake. He could have saved on these two completely.

That leaves us with the tile svg and the 170K PNG for the face of the author, which should obviously be a 40K JPG.

Finally, the img tags on that page don't contain dimensions, whereas it's probably(1) better to still have them: [https://www.computerhope.com/issues/ch001158.htm](https://www.computerhope.com/issues/ch001158.htm)

Given the topic of the post (the need to keep things simple when making web pages), I consider these observations relevant.

1) Probably as I'm not in the business and I don't follow most recent developments so I don't know if the arguments from computerhope.com are obsolete by the most recent standards or implementations, so all relevant technical information is welcome.

<comment><USER65> I kind of wish more sites assigned dimensions to `img` tags too. Unspecified or scripted dimensions make mess more often than not.

</comment></comment></comment></comment><comment><USER66> This speaks to me strongly, having done this many times: "I'm still not sure I understand it; I type clear: both and say a prayer to the box model."

</comment><comment><USER67> reminds me of [http://motherfuckingwebsite.com/](http://motherfuckingwebsite.com/)

<comment><USER68> yeah same here, many takeaways of the article are similar to [http://motherfuckingwebsite.com](http://motherfuckingwebsite.com)

to the uninitiated, I recommend also taking a look at [http://bettermotherfuckingwebsite.com/](http://bettermotherfuckingwebsite.com/)

<comment><USER67> Another of my favorites: [http://adventurega.me/bootstrap/](http://adventurega.me/bootstrap/)

</comment></comment></comment><comment><USER69> I read this article in reader view of the browser.

</comment><comment><USER70> I've just tried to copy paste the title of the article ... but it's impossible ... it's an image.

If after 20 years of web design and development you still don't get it, then everything easy is hard again.

<comment><USER71> Why would yo want to triple (I guess even more) your work just to have a semantic title when you can use an alt-text?

<comment><USER72> But there's no alt text. The code looks like this:

      <div class="section title">
      <h1>Everything Easy is Hard Again</h1>
      <img src="images/everythingeasy.svg" style="display: block; height:60vw; margin-left:auto; margin-right: auto;">
      </div>

And <h1> is styled in such a way it's not visible. This is bizarre.

<comment><USER73> Bizarre? The h1 is probably there for SEO or screen readers.

</comment></comment></comment></comment><comment><USER74> I still use tables.

</comment><comment><USER75> Well written and beautifully presented but these are complaints about progress.

> 'my limited needs...Simple, responsive layout'

As we all know, limited/simple in the requirements doesn't mean simple to implement. "I want this page to look the same on any size screen, whether viewed horizontally or vertically". OK. It's surprising it's as simple as it is.

> 'I thought implementing webfonts was a relatively easy procedure, but I > guess not!'

No, it is easy. If you want to read 90 pages of marketing-promo disguised as a guide to fonts, do so. But you don't have to. Go to google fonts, pick one, add the URL to the head of your webpage, done.

> We're a long way from the CSS Zen Garden where I started.

That way is still there. It's just slow and messy. You can still inline your CSS, use external css files. Whatever you want.

> Before, the websites could explain themselves; now, someone needs to walk > you through it.

Before, scrolling text and gifs were the cutting edge of web technology. Now we have Photoshop, online IDEs, real-time trading applications _in the browser_. This is magic. And magic isn't easy.

Furthermore, modern browser element inspectors provide an excellent explanation of what's happening on a webpage.

The web isn't static - as the browser advances we use new tools to handle the possibility as well as the complexity. But the old ways are still available. Although I'm not convinced that the 30 minutes of mental overhead getting to know npm and flexbox beats the mess of external resources, duplicate code and utter pain that was the web of the past.</comment>


Rejecting a job in Berlin after signing the contract? - <AUTHOR> I have accepted an offer in Berlin and they sent me the contract to start the visa sponsorship process.
Meanwhile, I'm negotiating with another company with better offer right now, but every step takes a couple of days and Berlin company wants me to sign the contract immediately.
The contract has a clause "This Employment Agreement may not be terminated prior to commencement of employment"
Does anyone know the consequences if I sign and bail a week later ?
The visa appointment in the embassy is 2 months from now anyway but they already assigned a case worker for me and I assume that costs money they may ask for. <comment><USER2> Tell the other company that you have an offer on the table with a clock on the offer. If they are your top choice tell them this and if you're the top candidate, they should find a way to move the process along for you.

Agree with what the others are saying about signing and then not going to work for company 1 might cause issues in the future, especially if you're looking to work in the same industry. If this company is going to sponsor you with a Visa, it's a significant commitment for them. I have personally never seen a company go after a person who signed and then moved in a different direction. I have know companies with a policy to never offer that person employment again.

</comment><comment><USER3> Never forget you're dealing with humans at the other end. You can always tell the person at the other end that you need time to consider and are not ready to sign the contract. You needn't offer reasons.

If they are serious about hiring you, they'll wait. Almost every time a company makes an offer they have a contingency plan for delays, rejections etc.

In any case, do not sign the contract until you are ready to sign to contract (heh, that should be obvious). Regardless of whether they can or will do anything if you bail later, it just comes off as being unprofessional. It is a waste of time and effort for both, you and them. You can be honest without being all out open about your reasons.

</comment><comment><USER4> We'd need the full clause for context, but from what you have provided it sounds like if you sign the agreement, you are also agreeing to commence employment with them.

I suggest that if you do not want to work for them, do not sign the contract. If you sign the contract and later renege, they can sue you for breach of contract.

</comment><comment><USER5> So, it really depends. (I am not a lawyer)

1\. Usually you have a probation period (Probezeit) in your contract which allows to resign with 2 weeks notice time for X months (usually 6 months), so you could resign right when you start. During that probation period also your employer could end the employment with two weeks notice. Your contract forbids resigning before you start, so you would need to resign on your first day.

2\. You can ask for nullifying the contract (Aufhebungsvertrag).

3\. Depending on your contract, there could be a penalty in the contract if you resign early.

I think option two, nullifying the contract is the most honest option. Just be direct with the company you have signed with that you have a better offer.

</comment><comment><USER6> Theoretically they could sue you and win damages, practically they probably won't, because damages won't be high.

But signing and then reneging is a serious faux-pas (unlike signing and quitting a bit into your probationary period), and if you intend to be in the general business area that this company is in, it may come back to bite you later.

</comment><comment><USER7> They assigned you a case worker without you signing the Employment Agreement ? That sounds a bit strange to me since you clearly don't have full commitment to this offer yet. How did you accept the offer ? Verbally or in writing ?

</comment><comment><USER8> No consequences. You can terminate it anytime you want, they can't until the end of the contract.

It's probably better to be upfront about your story.</comment>


A Closer Inspection of Tesla's Autopilot Safety Statistics - <AUTHOR> https://medium.com/@mc2maven/a-closer-inspection-of-teslas-autopilot-safety-statistics-533eebe0869d <comment><USER2> The author explicitly states that they believe that Tesla is correct to only include miles driven with autopilot enabled, specifically they say:

"I agree with Tesla's methodology on Autopilot mileage because the road conditions under which a partial autonomy system is rated for operation (highways, clear lane markings, etc) are systematically different from manually-driven miles."

But if that were the case you must also only include crash data from manually driven cars in those same circumstances. But the majority of automobile accidents do not occur on freeways -- which are the most autopilot friendly roads being driven.

We can't easily work out that traffic split, but we can do something else that should be just as effective:

Compare accidents per million miles driven in autopilot enabled cars, to accidents per million miles driven in regular vehicles. If autopilot does meaningfully improve driving safety, we should expect that the average for autopilot enabled cars to to be lower than other cars by a statistically significant margin.

If we want to get specific per [1] more than 50% of accidents occur at intersections, given Tesla's sample will dramatically over-represent intersectional crashes we could go extreme and say that their statistics should be immediately less than half the crash rate of non-autopilot vehicles. (this is an exaggeration, but given they're not being honest I don't really care)

Personally I'd also control for class of cars we're comparing -- I suspect the stats for high end cars are different from low are different from sports cars, etc.

[1] [https://www.fhwa.dot.gov/research/topics/safety/intersection...](https://www.fhwa.dot.gov/research/topics/safety/intersections/)

<comment><USER3> No, she is saying you shouldn't just count the miles where autopilot is turned on. Her reasoning is that you can't compare autopilot-on miles to regular cars because there is no comparable data for regular cars.

That might be acceptable if you compared Tesla autopilot capable cars to other luxury cars, where the only significant difference in safety is autopilot.

But that wouldn't account for things like: maybe certain Tesla safety features save a lot of lives but get canceled out by a very dangerous autopilot.

And she doesn't compare to similar cars.

<comment><USER4> > That might be acceptable if you compared Tesla autopilot capable cars to > other luxury cars, where the only significant difference in safety is > autopilot.

This is the comparison they should have done. Comparing with just the national average includes all the poorly maintained 20-year-old beaters being driven by teenagers.

</comment></comment></comment><comment><USER5> They would do better to look at the few serious autopilot crashes Tesla has had. They tend to involve the car driving straight into a large stationary object, in situations where a much cheaper car with a basic automatic emergency braking system (AEB) would refuse to collide and would just stop.

It looks like Tesla's over-sophisticated system which builds a live 3d map of the whole environment, too heavily filters out large non-moving objects, believing them to be things like overhead bridges which it can pass under.

It needs a supplemental and independent AEB system based purely on highly directional forward facing sensors which can confirm that the path ahead is clear. This is so cheap that it is becoming common on mainstream cars like Hondas and Toyotas. The current model S probably already has the sensor hardware onboard to enable this extra redundant safety system in software and save lives.

<comment><USER6> > They tend to involve the car driving straight into a large stationary > object, in situations where a much cheaper car with a basic automatic > emergency braking system (AEB) would refuse to collide and would just stop

Would it?

[https://www.wired.com/story/tesla-autopilot-why-crash- radar/](https://www.wired.com/story/tesla-autopilot-why-crash-radar/)

> Volvo's semi-autonomous system, Pilot Assist, has the same shortcoming. Say > the car in front of the Volvo changes lanes or turns off the road, leaving > nothing between the Volvo and a stopped car. "Pilot Assist will ignore the > stationary vehicle and instead accelerate to the stored speed," Volvo's > manual reads, meaning the cruise speed the driver punched in. "The driver > must then intervene and apply the brakes." In other words, your Volvo won't > brake to avoid hitting a stopped car that suddenly appears up ahead. It > might even accelerate towards it.

> _The same is true for any car currently equipped with adaptive cruise > control, or automated emergency braking_. It sounds like a glaring flaw, the > kind of horrible mistake engineers race to eliminate. Nope. These systems > are designed to ignore static obstacles because otherwise, they couldn't > work at all.

> "You always have to make a balance between braking when it's not really > needed, and not braking when it is needed," says Erik Coelingh, head of new > technologies at Zenuity, a partnership between Volvo and Autoliv formed to > develop driver assistance technologies and self-driving cars. He's talking > about false positives. On the highway, slamming the brakes for no reason can > be as dangerous as not stopping when you need to.

<comment><USER7> I don't work on these radar systems, but have played a lot with ultrasound for robotics. It seems possible these radar systems give almost continuous false positives. You could get a pretty strong return from potholes, slightly sunken drain covers, etc. Using doppler to reject any return that matches the car's own road speed just leaves the returns from moving vehicles. You can then track speed vs distance to sanitize that data. It becomes a tractable problem then to detect that the car in front is slowing quicker than you are. But telling the difference between a stationary car and a slightly misaligned bridge expansion joint is probably not trivial.

<comment><USER8> The Tesla has multiple different sensors, including ultrasound, radar, and cameras. Fusing information from the different sensors should help correct for such errors.

</comment></comment></comment></comment><comment><USER9> There is a factor that is never mentioned.

The actual "fleet" of Tesla (and of others experimenting in the autonomous vehicle field) is made exclusively of decently new and perfectly or nearly prefectly maintained vehicles.

Besides and before any other consideration, the way a modern, newish and well maintaind car handles (steers, brakes, etc., particularly in an emergency situation) is hardly comparable with the way the "average" car can do, think of unbalanced brakes, worn down tyres, etc., but also about the undeniable truth that your - say - 1998 pickup won't ever be as stable as a sports car.

Since there is no real data about the comparison term (all the other vehicles) status and capabilities (of both the car and the drivers), each and every comparison tends to be on favour of the Tesla for reasons that have nothing connected to the actual automation.

Even an "internal" comparison (Tesla's on autopilot vs. Tesla's on manual driving) wouldn't be IMHO much representative as drivers of Tesla are I believe - if not an elite - a definite group of people, not too young, not too old, possibly with an interest or passion about cars, while "the rest" will comprise just licensed drivers (possibly with little experience and with a tendency to risk too much), elderly people (possibly with slower reaction times).

<comment><USER10> The only elite thing about most tesla owners is they are richer than most other drivers.. It does not mean they are better drivers.

</comment></comment><comment><USER11> "Delaying the roll-out of partially-autonomous vehicles costs lives. This conclusion assumes that (1) automakers make steady progress in improving the safety and reliability of their partially autonomous vehicles and (2) drivers are comfortable enough with monitoring the partially-autonomous vehicles so that new sources of error associated with the transition to and from manual and autonomous control do not increase fatality rates."

In other words, if you assume (1) something which we can't actually know unless we have the ability to predict the future, and (2) something we already have strong reason to believe isn't true, then we must roll out partially autonomous vehicles as soon as possible and anyone who questions this is basically killing people.

<comment><USER12> The previous sentences are worth quoting as well:

>This model shows that rolling out just as safe or a little safer partially- autonomous vehicles by 2020 will save 160,000 more lives over 50 years than a scenario that waits until 2025 to roll out almost perfect autonomous vehicles. Delaying the roll-out of partially-autonomous vehicles costs lives.

Sure, rolling out autonomous vehicles will save lives if you _assume_ that they are safer than humans. But right now all the evidence points to autonomous vehicles being substantially more dangerous than humans. Waymo reports disengagements every 5,500 miles, and estimates that something like 10% disengagements would have led to a collision.

[https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/disen...](https://www.dmv.ca.gov/portal/dmv/detail/vr/autonomous/disengagement_report_2017)

And taken as a whole, self-driving cars have already killed one person with only about 10 million miles driven. It would take the average human driver more than 100 million miles to kill someone.

Edit: My comment refers to safety of level 4/5 autonomy, not the current Tesla Autopilot.

The real interesting question is whether it's worth it to deploy dangerous cars, risking today's lives to help save future lives. It's not that interesting to ask whether deploying hypothetically safer cars will save lives.

<comment><AUTHOR> Why do you think only 10 million miles have been driven with Autopilot? This article says a billion+ miles have been driven with Autopilot cars: [https://electrek.co/2016/11/13/tesla-autopilot-billion- miles...](https://electrek.co/2016/11/13/tesla-autopilot-billion-miles-data- self-driving-program/)

<comment><USER3> Autopilot isn't self driving. It's glorfied cruise control.

And Tesla's had two autopilot fatalities. And Uber had one.

<comment><USER8> Does the Uber one count in the same statistical category since it was a pedestrian? I thought those were there own category?

</comment></comment></comment></comment></comment><comment><USER13> It's good that there's starting to be more focus on whether partially autonomous vehicles are actually safer, but what about other aspects?

We have social networks now that have "terms of service" and who are kicking out people they disagree with. Is it too far out there to suppose that an autonomous vehicle will come with similar "terms of service"? What if the vehicle refuses to drive you to a competitor's store? Or to a political rally that the car company doesn't like? Or to a gun store? Or to a religious gathering?

Since most drivers control and own their cars, these are not concerns today, but they likely will be. It seems like these are bigger decisions to hash out than whether a car is merely safe. It doesn't matter if the car is safe, if it safely takes away your freedoms.

</comment><comment><USER14> Tesla has data on how much time their cars spend on autopilot. If Tesla wants to promote their crash rate, they need to disclose the raw data.

Total vehicle miles for vehicles with a system that only works right on freeways is guessing. The accident rate of interest is autopilot miles on freeways vs all vehicles miles on freeways. Here's the US data summary for all vehicles.[1] See table 35, which breaks out divided highway data.

The focus on fatal collisions is misplaced. There are far more non-fatal collisions, which provides much more information. Evaluating Tesla's "autopilot" is about measuring driving error, not crash survivability.

[1] [https://crashstats.nhtsa.dot.gov/Api/Public/Publication/8123...](https://crashstats.nhtsa.dot.gov/Api/Public/Publication/812384)

<comment><USER15> There needs to be at least some emphasis on fatalities. If autopilot reduces total collisions but increases fatalities, you might draw the wrong conclusion about its safety. It's early but from the incidents we know already, it seems like a decent probability that this is the situation that Tesla is in, lower crash rate but more likely for those crashes to be fatal.

</comment></comment><comment><AUTHOR> The Rand article says the most lives can be saved if Autopilot was rolled out after it was 10% better than humans. However, we won't have statistical confidence until billions of miles are driven. If we think this problem can be solved, we have to take a risk and go for it.

</comment><comment><USER16> One thing I don't understand about the current way autonomous vehicles are going is avoiding more of a "positive control" type of setup. I grant it's more complicated and it means you won't have it right away, but shouldn't we come up with some highway design standards that will make autonomous vehicles safer, then some signaling method to say "this is on" or during construction say "this is off"? It just seems a smarter more incremental way to go. That way you can engage "autopilot" only in conditions it's known to work under.

</comment><comment><USER17> Tesla's stats compare autopilot equipped Teslas against motorcycles. They are deflecting.

</comment><comment><USER18> "humanity could be ushered into a new economy where driving is a hobby, only for sunny days along clear roads with a view. The struggles and tedium of the daily commute could be handled by autonomous vehicles, traffic accidents could fall to nil, passengers could focus on working and relaxing in their mobile offices, and the elderly, disabled, and blind could have considerable mobility and autonomy."

Sounds remarkably like a world with good public transport.

<comment><USER19> "Good public transport" is an oxymoron.

The best you can hope for is public transport that will get you where you're going in time.

There's no public transportation that will provide privacy, consistent comfort, or even a seat. Never mind the most basic problem with public transportation—the other passengers. Any time you get into an enclosed metal box with an arbitrary number of random people, you roll the dice. You could have a quiet, safe ride, or you could end up with loud music, obnoxious body odors, food spilling on you, bags hitting you in the face, or someone vomiting all over the floor. Any long-time New Yorker has their fair share of subway and bus stories.

Public transportation is a vital part of any city. But it's not a "relaxing mobile office," it's not always easy or convenient for the elderly and disabled, and you can't have it as the only option.

<comment><USER18> well, you certainly can get some work done on a train once you figured out your commute in a way that will get you a seat. Grande, that is not an option for anyone.

On the other hand, what would the world look if we all used autonomous cars? Seems like we would end up with the same, or worse, traffic jams. If people were willing to share their cars, they would be a bit less. But remember any means of public transport uses less space than cars. [http://humantransit.org/2012/09/the-photo-that-explains- almo...](http://humantransit.org/2012/09/the-photo-that-explains-almost- everything.html)

<comment><USER20> > But remember any means of public transport uses less space than cars

I think this is indicative of the PR problem that transit advocates have and that the GP is trying to point out: the advocates keep focusing on moving people from point A to point B.

Transit advocacy always seems to be about X thousand passengers per hour and saving Y thousand square feet of real estate. Quality of life of those passengers doesn't get a mention.

Granted, creature comforts may not be all that high on everyone's priority lists, but I'm confident they are for many, especially as they get to middle age and have the financial means to vote with their wallets.</comment></comment></comment></comment>


The rise of alternate VC - <AUTHOR> https://medium.com/swlh/rise-of-the-transformers-db7887c26689 <comment><USER2> This is great!

<comment><USER2> Sorry wrong post</comment></comment>


Children Shouldn't Be Dying at the Border. Here's How You Can Help - <AUTHOR> https://www.nytimes.com/2019/06/24/opinion/border-kids-immigration-help.html <comment><USER2> The demographics of border crossers has changed dramatically over the last several years. We never used to have so many families and unaccompanied minors crossing.

I believe this is a direct result of the incentives we provide by allowing families to stay, minors to be provided free transport along to waiting relatives (who may be in the country illegally themselves), and ultimately the promise of deferred action and citizenship. But all of this is contingent on _having a child with you_ when you cross, or children crossing alone, which is totally ludicrous.

Over 50,000 unaccompanied minors in the last year have crossed over that we know of. Assuming these children are not being returned back home, they obviously need to be sheltered while their relatives are located and screened. This is an incredibly vulnerable population which has grown exponentially and therefore now greatly exceeds the capacity of the network of non-profits which used to provide temporary shelter and housing.

Parents in the US who leave their kids unattended in the car while they run in for groceries risk having their kids taken and being charged with child endangerment. Parents who cross into the US illegally with their kids get a free pass.

Even aside from the question of "first safe country" - we have a legal system for processing asylum claims, and historically (going back several administrations) the types of people crossing do not qualify because they are mainly _economic_ migrants.

The best way to stop kids dying at the border is to stop encouraging their parents (or coyotes) to take them there.

</comment><comment> core-questions Is there some reason why it is the responsibility of Americans or their government to provide for people that enter the country illegally? Parents are endangering their children's lives and committing crimes, contributing to a rising problem, and the biggest concern we're supposed to have is whether the children are comfortable enough?

I'm tired of this emotional manipulation. It's perfectly reasonable for a country to have a border and to defend it against illegal entry. To suggest otherwise is literally to attack the very concept of a nation and to eschew any sense of respect for the existing tax base.

<comment><USER3> Putting aside the lens of responsibility for a moment, the parents and kids are rational if in the sum of all things the grass is actually much greener on the other side of the fence.

Of course the nation with the greener grass is also free to exercise a rational value of preservation of position, especially if scaling isn't cheap or easy. In an increasingly disparate world nations may find themselves building more fences.

<comment> core-questions > in the sum of all things the grass is actually much greener on the other > side of the fence.

Sure, but this needs to include a risk calculation - how tall is that fence, and what happens when you don't make it over, versus other options like migrating somewhere else more local, or refocusing your efforts in your own community.

</comment></comment></comment><comment><USER4> We did not write angry letters to end nazi concentration camps. Any particular reasons we shouldn't all march on the camps and dismantle them?

<comment><USER5> They are not Nazi concentration camps. If the alternative is to effectively have an open border than I support the actions taken to detain and process illegal border crossers.

<comment><USER4> Did your relations apply for citizenship from home and wait a decade?

<comment><USER6> Push for immigration reform then, not lawlessness.

<comment><USER4> When the law is children imprisoned in cells sleeping on concrete floors bring on the lawlessness.

<comment><USER5> The children are victims of their parents' decision, not our government. Blame the parents.</comment></comment></comment></comment></comment></comment>