HTML is the Web - <AUTHOR> https://www.petelambert.com/journal/html-is-the-web <comment><USER3> I pretty much agree with all the article. Back in 2001, when Web Standards were on the rise, people used to validate their HTML code. It was shown as a badge of prestige when you had 0 errors. Semantic HTML was a hot topic and most of the developers I worked with were a sort of HTML taliban. But the popularity of frameworks helped developers forget the basics and concentrate more on learning how to get the most out of these projects. If we also sum that I don't see true impact on SEO by having the best HTML I think it's pretty clear semantics and validation isn't relevant anymore.

When people ask me why SEO isn't working. Well, try to see the first results on Google, and check their code. Most of the times you will see worsen HTML validation and semantics trumped over better (not perfect), not mentioning the first page is mostly paid ads. Google is not like back in the 2000s. Things has changed.

<comment><USER4> All my webpages had the valid xhtml badge!

[https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg](https://commons.wikimedia.org/wiki/File:Valid_XHTML_1.0.svg)

I still have a hard time un-learning `<br />`

<comment><USER5> Opening can of worms: did you serve them with any of the available XML MIME types? If not they worked simply because of the bug in the browsers (SHORTTAG means a different thing in HTML compared to XML) and all XHTML code served with HTML MIME type would be littered with ">" if browser treated it right ;)

<comment><USER6> I once toyed with the idea of serving XHTML page as application/xhtml+xml, but the fact the browser (back then, not sure about now) will just display XHTML error and doesn't render anything was a deal breaker for me.

<comment><USER7> By "the browser" you mean "Internet Explorer". The only browser that couldn't handle XHTML.

<comment><USER8> With XHTML any syntax error completely aborts rendering, there is no fallback - the browser will display a native error page instead.

<comment><USER7> Has nothing to do with what I said. IE couldn't handle XHTML until IE9

[https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in- ie9/](https://blogs.msdn.microsoft.com/ie/2010/11/01/xhtml-in-ie9/)

<comment><USER8> Sorry, but you're mistaken. The parent never brought up IE - he was referring to the fact that when serving XHTML with the correct mime-type (application/xhtml+xml), any error causes the page not to render at all. This behaviour is intended per spec and was the same across all browsers, not due to lack of support. It's called "draconian error handling", consequence of being XML, and was a major factor in the death of XHTML.

<comment><USER7> The death of XHTML was brought on by the then crop of kids who don't want to understand how computers work and want it all done for them with someone else's code cause computer science is too hard and they'd have to think and thinking is too hard.

While I often hear this "draconian error handling" about XML/XHTML by such people who then complain that a language compiler is just as draconian and real programmers complain when it's not and doesn't catch their every little mistake.

It's this lack of education and drive for the pursuit of knowledge and understanding that caused XHTML to fall out of favor and no other reason.

<comment><USER9> That's all well until you have external content (e.g. blog with comments or blog roll headlines). Many an enthusiastic Web author in the 2000s migrated off XHTML again. Not because getting it right is too hard (each fix for each problem is quite straight-forward and often trivial), but because when you have the choice between having a completely broken page/site until you have time to log on and fix it and having a miniscully broken part of a page that's easily ignored by a visitor, then the idealism was just too bothersome. Unfortunately, that's human nature. Also see: rms's principles as exemplified by his life-style and how many follow his example perfectly.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER10> The biggest takeaway is that HTML was originally designed to degrade gracefully. If your browser didn't support the intended graphical layout, it would still be able to extract the hierarchy and display a usable web page, even if you were using pure text (e.g. lynx). This kept the web accessible no matter what you were using.

These days, none of that occurs. Just try switching off Javascript (I use NoScript heavily to avoid invasive ad trackers). 75% of web pages don't load at all. Others completely mangle their layouts into an unnavigable mess. Only a very small subset of pages are readable. And these are just landing pages - pages that should welcome one and all to the site. Most of the time, unless I'm looking for something specific on the site, if it loads a blank or mangled page, I just move on. If everything's a dynamically-arranged
, the browser has no hope of making sense of it.

You can lead a horse to water, sure...

<comment><USER11> Web pages should be designed to load without js.

<comment><USER12> Web pages that don't show anything without JS are broken. Ones that show only a message about enabling JS are worse. It seems JS;DR was already a thing long before I felt the need for it yesterday, when I simply missed that article about synths at ableton.com because it was broken. [https://indieweb.org/js;dr](https://indieweb.org/js;dr)

<comment><USER13> What about web applications? I am the office champion of accessible web, but recently we made a web based game, in canvas. Without js, there's no game engine, so we had a noscript tag.

That synths article uses built in JavaScript synths (using audio apis). I agree the text should display without JavaScript but the purpose of the article (get hands on with synths) is eliminated without JS.

Basically, the web not only is a document delivery place, it's also the new Newgrounds. None of those games would work if you disabled flash, why should web applications (beyond ones that are simple documents) work without JavaScript?

<comment><USER14> If you like synths on the web, check this out.

[https://learningsynths.ableton.com/](https://learningsynths.ableton.com/)

<comment><USER13> Cheers, but that is the exact article we're discussing lol

</comment></comment></comment></comment></comment></comment><comment><USER15> I feel like many people here are misreading the OP as anti-framework and I didn't read it that way at all. Sure, there is an element of, "you don't need to immediately grab the nearest framework as the solution to _every_ problem", and that's something I personally agree with.

But the point I think the author is trying to make is that whether you do or don't use a framework, you need to understand the fundamentals. The fundamental language of a browser has always been HTML. JavaScript and CSS are great and came along in due time but before all that there was HTML. So whether you're simply marking up a document or building a full-fledged web app with React or Vue, you're doing yourself a disservice by not learning and using proper HTML.

<comment><USER16> Yes! It's about semantic HTML. For example, starting a Vue component with a
 or
 as root element.

</comment></comment><comment><USER17> As an experiment, I started [https://wordsandbuttons.online/](https://wordsandbuttons.online/) in plain hand-crafted HTML+CSS+JS (JS for the interactive bits only). Every page is self-sufficient, there are no dependencies, no dynamic data exchange, no HTML generators, - nothing. And it works so well, I don't really want any frameworks now.

It's perfectly malleable - I can make every page do exactly what I want it to. It's lean and fast - every page even with all the interactive plots, games and quizzes, and syntax highlighting, is still under 64K. And it doesn't accumulate technical debt. There are no dependencies, even within the project. An occasional bug from the past wouldn't bite me in the future.

At the beginning, I thought that typing the HTML by hand would be too tedious. But it's not. It is a bit boring, sure, but it's only like 5% of all the work so usually I don't really want to automate it.

And when I do, I just write scripts that handle HTML just like any other text. Works wonders for me.

<comment><USER18> It is truly astonishing how much people believe that they need frameworks.

Your site looks nice, but one comment I'll make about your coding style is that you (or anyone getting inspired from your code) should probably switch away from innerHTML as the default choice for DOM modification. In a lot of otherwise useful contexts it is an HTML injection hole. (For the record it doesn't seem to be a security issue for the kind of content you have made, but better kill the habit before it becomes a problem.)

For a while I used document.createElement and friends to generate injection- free DOM, but that style takes a lot more typing than innerHTML usually does. Eventually I made a tiny library for easing the job, and I haven't looked back since. I don't think anyone else uses it, but so far it is definitely worth it for the one happy user. [https://github.com/NoHatCoder/DOM_Maker](https://github.com/NoHatCoder/DOM_Maker)

<comment><USER19> I did something very similar back in 2006: [https://programming.arantius.com/dollar-e](https://programming.arantius.com/dollar-e)

</comment></comment></comment><comment><USER20> I recently used Semantic-UI ([http://semantic-ui.com/](http://semantic- ui.com/)) in a project. Semantic-UI is a web framework where "semantic" means there are human readable class names like

       <button class="minor red labeled button">

Compared to Bootstrap, Semantic-UI ships with high level "components" ("views", "modules", "collections"). And here comes the ugly: They all abuse HTML as if it was 2008. Div soup everywhere. Even lists have to be formatted as Divs, something I havent done since ages, something like:

...

...

It really felt as if the knowledge about semantic html tags got lost somewhere. Or the authors of this popular CSS framework have another understanding of "semantic". It doesen't meet my quality of structured HTML, thought.

<comment><USER21> Oh my! I didn't believe that code example you just gave, so I had to go look it up for myself. I'm astounded.

[https://semantic-ui.com/elements/list.html#list](https://semantic- ui.com/elements/list.html#list)

<comment><USER22> to be somewhat/slightly fair, the very next example talks about using a `ul` for the list.

<comment><USER21> But according to the docs that's "for convenience". Its semantic value isn't discussed.

So presumably the 'proper' way to do it, if you're not looking for convenience, is to use `div`s. /s

</comment></comment></comment></comment><comment> grey-area Web pages started as documents, and have gradually evolved to support ever more complex uses, so that now they are effectively a platform for application delivery (and a very good one) as well as for document delivery. Oftentimes web applications are a mix of both data delivery and data manipulation, so the line is not clearly drawn. This has inevitably created a tension between those who see apps as the only future, and those who see docs as the purpose of the web, and apps as an afterthought (a camp the author of this article falls into). I don't think it's useful to attempt to set up a dichotomy between Apps and Docs and pick a side. Very few websites are pure document stores, and very few apps don't require documents, urls for resources etc.

Personally I think the web should evolve to play to its strengths: Simplicity, Flexibility, Separation of data from code and from style.

It'd be nice if instead of trying to shove javascript into every hole because it happened to be bundled with browsers, we pushed browsers to bundle more runtimes for client-side work (a WASM standard library if you like), so that the web can continue to be a place where you can post about javascript on a server running arc software, and not care which technology the server or server uses, which can be swapped out at will. One of the great joys of web development from my point of view is not being tied to a particular language or ecosystem, because the web is heterogeneous.

</comment><comment><USER23> _A Web page is a document._

No it's not. It never was. Even a long time ago when websites were static things rendered by the browser once and then left alone there was _always_ a tree of nodes underlying everything. The only thing that's changed in the past three decades is that now when we make websites and web apps we often ship a little JS application that lets the user modify the underlying tree. _That 's_ what the web is now and HTML is just what we use to describe the initial state of the tree (and arguably it's the wrong language for that job, but hey ho). Using semantic markup is important for a bunch of things like accessibility, but you can't really expect the initial state of the page to stay the same after it's loaded, and software that renders things from the web has to deal with that.

If you're old enough you might remember that once there were no stylesheets. HTML wasn't just the content and structure, but also the _visual_ description. We used font tags. We used color attributes. We used spacer gifs. We don't do that now because it sucked. We moved forwards. The same is becoming true for HTML. Users demanded interactivity, and we gave them exactly that, and browsers turned in to things that run little applications rather than things that render mark up. The web has grown and evolved and moved on, and thinking of the web as "HTML pages" is _just plain out of date_.

That's not to say static content isn't still useful. It is. _Very_ useful. But static HTML pages isn't the web, and the single page application genie isn't going back in the bottle.

<comment><USER24> > We moved forwards. The same is becoming true for HTML. Users demanded > interactivity, and we gave them exactly that, and browsers turned in to > things that run little applications rather than things that render mark up.

As I like to occasionally point out in wasm threads, the browser was a thing that ran little applications all along, in the form of Java applets. I have yet to see an explanation of how wasm applets are a different approach to the problem, but they sure are a more popular one.

<comment><USER23> The difference is timing. Computers weren't really ready for applets back in the mid-2000s when Java was pushing to be the thing that made web pages interactive. The performance (in terms of download speed, start up, and actually running them) was usually pretty horrible. Now the hardware has caught up it's the language that's the bottleneck, so WASM might prove to be a decent idea.

Also Java tried to be a gateway out of the browser to the OS, and that's just a terrible idea for security. WASM isn't trying to be that, and hopefully it never will.

</comment></comment></comment><comment><USER25> I couldn't agree more. HTML is so basic that you have no excuse to not do it in the ballpark of right (accessibility can be tricky and right is not always completely clear, but in 90% of cases you should have a good idea). Using a solid css reset solves most of your visual issues with using semantic elements/structuring following proper standards. Use the reset and then write css however you want to. The current state of the web (being nothing but an advertising platform for the most part) is what is driving a lot of people to other protocols. A return to sanely structured CONTENT over pretty/fancy/neat/whatever looking would be, in this writers opinion, a wonderful thing. I know in a perfect world we'd have both, but that is not how things have played out for the most part. Maybe the next thing, that replaces the web eventually, will get it right. :-/

</comment><comment><USER26> Unpopular opinion... but I think this is a too limited view of the web. My contrary opinion is that the _actually_ important feature of the web is the URL, and the important feature of the browser is that it provides a sandboxed platform for running untrusted code without a builtin "walled garden moral police".

It would be nice if operating systems would be exactly that, but for some reason "commercial" OS vendors are not able or willing to provide a safe "native" sandbox completely uncoupled from curated app stores.

The ability of a browser to be a document viewer with a very limited layout system should be implemented in an optional layer on top of a bare bones browser.

Again, this should all be provided by the underlying operating systems (click an URL and instantly run cross-platform applications in a safe sandbox), but for some reason we didn't get that. It's the same with Electron apps by the way, those wouldn't exist if operating systems would come with cross-platform UI frameworks that are actually better than the unholy mix of HTML+CSS+JS. But Microsoft, Apple etc... had decades to get their act together without delivering.

<comment><USER27> I'm inclined to disagree, but I guess the real problem is that webpages on the internet are being forced to serve both purposes.

Paradigm 1 - interconnected, hyperlinked web of text-and-content-based documents: open, accessible, amenable to indexing and tooling and so forth.

Paradigm 2 - delivery vehicle for cross-platform, full-featured, somewhat- security-sandboxed, applications.

I agree with the article that it's sad if Paradigm 1 is trampled to make way for Paradigm 2, just because (as you point out) we haven't been able to develop a viable alternative. In theory these could coexist, but the point of the article is people are being trained in Paradigm 2 and try to use it for purposes that are much more suited for Paradigm 1.

Just as sad, Paradigm 1 is more oriented around decentralization, giving power, options, and information to the user; Paradigm 2 is often exploited for lock-in, control over user's decisions, collecting information about the user, etc.

<comment><USER28> I think what the author is saying is that paradigm 2 is built _on top of_ paradigm 1 and if you can't do #1 right, then by definition _neither_ can be right. It's astounding the number of interview candidates who are super-fluent in JS but can't tell you to save their lives why it's a bad idea to put a click handler on a div. React will die (It's already started to) and we'll migrate back to the actual Web at some point and for my money it can't happen fast enough.

<comment><USER29> > It's astounding the number of interview candidates who are super-fluent in > JS but can't tell you to save their lives why it's a bad idea to put a click > handler on a div.

Go on?

<comment><USER30> Putting a click element on a div is transparent to accessibility systems. And no, it isn't possible to consider an element with an onclick the same as a button, because events bubble, which means the element with the event listener isn't necessarily the element being watched for a click. IIRC there even used to be a "good practice" where people would attach a single click handler at the root and use it to dispatch events based on the `event.target` instead of attaching a separate handler to each target.

<comment><USER31> React does that, they call it synthetic events, but it's hidden from the developer. In jQuery it used to be called event delegation, made it easy to handle events on dynamic elements without the need to constantly attach/detach handlers.

</comment></comment></comment></comment></comment></comment><comment><USER32> So, frontend tooling is freeing developers from mundane tasks and cognitive overhead at the cost of not strictly following standards and recommendations. The tooling could be improved to more closely follow standards, but maybe those standards ought not be followed? Maybe the standards need to evolve with real world use. DIV has broader applications than what a committee envisioned. Sites are running, business is accomplished, goals are met while not strictly adhering to antequated standards.

If I make a tool with an intended use but the world uses it in another unanticipated way, and they're happy about doing so, then that is a very fortunate accident. I then shape the next iteration of my tool around real world use.

</comment><comment><USER33> Someone I met recently met who delegates work to web developers for a living had this to say about JavaScript frameworks: They are very seldom necessary for a job, and their main function is to create more work for more developers to get paid.

As an "old school" designer who writes HTML and CSS by hand, with JavaScript for progressive enhancement, I found myself agreeing, and it reminded me of this, from back in 2001: [https://www.thenoodleincident.com/tutorials/box_lesson/why.h...](https://www.thenoodleincident.com/tutorials/box_lesson/why.html)

> The idea of HTML et al is a document markup language that would grow. Its > architects saw we were going digital and sat back and took a long view. A > very long view. They laid the foundations for a language that would work > with all the conceivable technology of the time, and would be expandable to > the unconceivable technology that would follow. So that documents would > never be unretrievable due to age. Ever. A browser in 2050 would be able to > read a 1994 document. And in 2094. And so on. They made a stand of cultural > importance to the world.

The slow, less usable feeling of JavaScript-heavy websites — my current personal website included — has remained a constant, and I mourn the reduced usability of View Source as a map for learning, lost in the forest of DIVs and obfuscated JS in much of today's World Wide Web.

<comment><USER34> I'd argue the opposite point, the problem with static websites is that they were bad at capturing state. That is what lead to the bloat of JQuery messes in websites and inefficient parsing of the HTML tree. Now that developers have so many platforms to target in so many ways, having a consistent way of state to permeate through websites reduces work.

Don't take me wrong, I love crafting my website 20kb of CSS over static files. Always sign me up for a static site, but for complex websites, where interactivty and state are needed, it's important to have these frameworks.

</comment></comment><comment><USER35> This is the kind of thing that drove me away from frontend development a few years back. I explicitly ignored the learn-the-javascript-framework-du-jour attitudes.

On a project where I was doing frontend work, I just tried to think about the semantics of html elements and http requests, and reason my way through the tasks from first principles. I really enjoyed doing that actually, and don't regret it. But it didn't teach me angular which is what the frontend people at that company were using at the time, or probably any of the other ones.

I hope to venture into frontend land again, because I think it's a valuable skillset, but I hope the next time I do things will have settled into something a bit more sane. When I find a layer of a technology stack that seems to have been misused or misunderstood, my tendency has been to stop at that point and dive into a rabbit hole trying to understand what is going wrong and how to fix it.

</comment><comment><USER36> Idk, on the one hand, HTML is what made the web great as an easy medium for self-publishing. This has now mostly been driven ad absurdum by CSS, the expectations towards super-stylish content, and hence centralized platforms a la github, medium, etc. I mean I'm pretty ok at CSS, but the amount of hacks and stuff you have to do for even the most basic layouting and typographic stuff outside your regular markup is just mind-boggling, and not something you can call reasonable by any measure (including Flexbox and Grid and whatnot). OTOH, coming from print, there just was no blueprint for declarative, interactive, responsive web pages [1] so some concessions had to made wrt to evolution of the web. I always thought of JavaScript as a mid-term measure to try stuff until such a time when we could, from hindsight, integrate declarative UI features into HTML. But that hasn't happened, and HTML has essentially stagnated instead relative to JavaScript and CSS. What we have is this unholy HTML-CSS-JS trinity hardwired into people's heads with strong opinions on which goes where a la "semantic" markup, but absolutely no logical or scientific base for back up. It's all fun until you realize we're going to loose most digital content of our decade, and a once-strong medium for digital communication (markup, HTML) has been overtaken by corporate interests, nerds seeking an intellectual challenge because they can, feature creep and misuse of the web to counter a software crisis, self-sustaining web economies and generational churn, and other unintended consequences.

[1] technically, there was SGML and HyTime, HyperCard, Xanadu

</comment><comment><USER37> As much as I like the sentiment, in my opinion HTML is very much a means to an end - that end being delivering content to your end consumers.

I was very much behind the "separation of concerns" brigade (with respect to HTML/CSS/JS) a few years ago, but the invent of React/Angular etc. and the "component driven architecture" has seen an end to that.

It's a shame - from my perspective, new entrants into the front-end market lack much of the knowledge I'd regard as fundamental even a few years back (most saliently for me TypeScript/ES2015 obscuring JS's prototypal inheritance) - but its also understandable.

</comment><comment><USER38> > My big concern is at the bottom of that technology pyramid. The lowest > common denominator of the Web. The foundation. The rhythm section. The > ladyfingers in the Web trifle. It's the HTML.

This is perhaps an annoying pedantic answer, but I feel like this discounts what HTML actually _represents_ , and what the Javascript libraries operate on, which is the DOM, bypassing HTML syntax often completely. The HTML, fundamentally is a representation of this Document Object Model, and if we're to be essentialist, HTML's success relies on good fundamental ideas of _what kind of document it generates_.

I do, however absolutely agree that the semantic representation of a document is important, and HTML's ideas of what a good representation of a document looks like really do shape the success of the web. This is why in very successful frameworks like React for example go so far as to implement their own pseudo-HTML transpiler that turns HTML-like representations of DOM nodes into DOM construction calls.

That said, I think there is a certain kind of essentiallism echoed in this post that goes along the lines of 'everything can't just be
s with classes' and I agree with that, but I don't think it has to do with writing more HTML-like DOM trees as much as augmenting the DOM to integrate more modern representations of DOM operation. I hope that in the future, systems like React leverage something similar to Custom Elements to truly represent their functionality in the DOM tree, as God intended ;)

</comment><comment><USER39> I always chime into these articles with the exact same sentiment: this is a business problem, not a developer problem.

Developers love simplicity and semantics. But when a UI gets to a certain level of complexity (I say 10 interactions per page) then semantics get hard to maintain or translate.

I'm building a recommendation engine for a client right now. Lots of wooshes, whirring and moving parts, a good amount of items don't directly translate to semantic HTML elements. It's not clear if my app should have
 tags,
 tags or  tags.

And again, when a developer has to manage that much complexity, then it's a-ok to breakdown or lose semantics in exchange for comprehensibility. Pretty much any trade-off is ok for comprehensibility. And making my users pay the 500kb React tax is a-ok with me, because I'm not superman and it's only 500kb. One un-optimized image can be that size. It's worth it for the project to be maintainable and reasonable by the next person.

And one day when the business stakeholder decides that people on your education site don't need badges, or that quality content matters more than gamification, then we can dial these interactions back and make the web sane again.

<comment><USER40> Since the article's main point is that you should use semantics as much as possible, it's probably better that you used the "wrong" tag when choosing between _
_ or _
_, than using the wrong tag and choosing _
_s for lack of not even having asked the question "what should this be?".

While rewriting what's already out there may be a business decision, choosing between what HTML tag to use when changing/writing new ones, is completely business agnostic.

<comment><USER41> There are plenty of apps out there where you cannot apply HTML document semantics or that would be a waste of time (money) doing so.

If using canvas or web-assembly would be easier/possible than using HTML tags for a rendering layer, nobody would ever disturb the HTML document designers with this div "soup" :)

Semantic HTML serves 2 purposes: lets search engines correctly index your content and makes it easier for a human to edit this HTML directly. Other than that, there is no other reason which requires semantic HTML.

True accessibility is achieved through other means.

</comment></comment></comment><comment><USER42> > If you're writing code that renders things in a browser, this is your job.

Nitpick: I write code that renders things in a browser. I do not touch HTML. I use GL/D3D/Vulkan and C++.

I'm not really sure what point I'm making, perhaps that the author might want to consider the other parts of the web/web browsers.

Edit: to clarify, I work on the lowest level of browser's rendering stack.

</comment><comment><USER43> The author is right, but this comes off very much as "old man yells at cloud" to me. Sorry.

<comment><USER43> Let me give slightly more context. As a developer, I'd love to use div less often. However, I feel like the promise of the "semantic web" fell short. And "web components" as a first-class HTML citizen isn't really there. So React/Vue components are the best we've got even though they're actually just divs and spans at the lowest level. I want the web to be semantic and componentized. But it's not there yet and this is the best we've got.

<comment><USER44> You can use React/Vue and still write semantic HTML, no?

<comment><USER43> I mainly work in React. You can write semantic HTML up to a point. Things like article, section, header, footer, etc. are supported. But if you wanted to make up your own tag and expect it to act like a div, I think React would complain that it doesn't understand that tag.

That's what I meant by "the promise of the semantic web". As I originally understood it, you could make your own custom tags that describe the intent of the document. You wouldn't be bound by what the w3c or browser vendors blessed. Any tags that were unknown to the browser would be treated mostly the same as a div. Web components occupy a similar space.

<comment><USER45> That does not match how I think of the semantic web at all. For example:

> make your own custom tags that describe the intent of the document

If you make up your own tags for everything then to a visitor (human, bot, indexer or otherwise) it describes nothing, since those tags only have that meaning on your site (and worse, they have different meanings on other sites). Semantic web or RDF or Linked Data or whatever you want to call it is not about describing your document within the context of your document, it's about making sure your document is understood in relation to all the documents that link to it and all the documents that it links to.

<comment><USER43> I looked up what the semantic web actually is and you're right. But at the same time, I was surprised to find that it's all properties! The tags are all divs and spans!

I guess the semantic web is orthogonal to this discussion. My apologies. I guess it's another buzzword that was thrown around for a time. In that case, assume I meant web components whenever I said semantic web.

</comment></comment></comment></comment></comment></comment><comment><USER46> The problem is bigger, IMO. Frontend is generally a disgrace for this profession. Biggest projects are a mess that would never see the light of day had they been backend-related. Babel, React, Webpack are maintained far worse than libraries having 10% of their userbase in languages like Python. JS is a fucked up language and we all know it. You couldn't done any worse if you tried to. Until we as a community will not stop tolerating this bullshit, problems will be solved using 2000% more memory/cpu/io than they actually need.

</comment><comment><USER47> Nobody is claiming HTML is not necessary. It's just not sufficient.

<comment><USER48> And CSS. Not sufficient for what? If you want to make a full-fledged program with a weird custom interface instead of a website, maybe don't try to use the browser as a virtual machine?

</comment></comment><comment><USER49> Taking a linguistic perspective, one can analyze HTML usage through the lenses of prescription and description.

Prescriptively, HTML was designed to be used a certain way. "Proper" use of it supports a variety of use cases beyond graphical browser-based publications and applications.

Descriptively, there is no "right" or "wrong", "proper" or "improper".
s and s are often enough because they get The Job™ done, for some critical subset of all "jobs." It is true that web scraping and machine parsing of content becomes harder when tags aren't applied semantically, and that text- and speech-based browsing is more difficult. It would seem that those needs are simply not substantial enough to the commissioners of web development work to warrant the extra attention and care, especially in the hyper-competitive, sink-or-swim environment of tech startups.

It is (nominally) what it is (actually).

The real problem is a lack of exploitation and education of the secondary applications of semantic HTML and how it fits in with related technologies (HTTP headers vs <META>, URLs and fragment identifiers, microformats and CSS semantic class naming) by product designers. This would naturally drive developer interest. In the meantime, those who do understand these things can continue to devise solutions orders of magnitude more efficient or effective.

</comment><comment> amw-zero This way of thinking just isn't aging well. HTML is the view part of the web, and it turns out users want more application-like behavior and developers want to build applications and not websites. Caveat, this is still only true for some applications. Static HTML is still fine for certain applications. Just never the ones I work on.

It started with AJAX and now we've converged on single page apps, which are effectively native clients where the target platform is the browser. There is simply a real demand for rich client UX and you can't get that with pure HTML. Which is no surprise because it wasn't designed for that. It was designed for sharing textual documents, as the article proclaims. But is that an accurate model of an application? I don't think it is. The web has evolved to support more than just hyperlinked documents. Good or bad, that's why people want.

</comment><comment><USER50> > _It's all about what gets consumed by the consumer._

It's not about the _what_. It's about _how_ it's delivered and consumed.

One could provide a web-like experience using any number of proprietary technologies. It's only "The Web" when you _deliver_ that experience in an open and standards-based way, and consumers _consume_ it using their standards-supporting client of choice.

Podcasts are another great example of "The Web". What makes a podcast a podcast isn't what gets consumed, but _how_ it's delivered and consumed. You can post an audio show on proprietary platforms that require proprietary clients, but those aren't podcasts any more than a web page saved as PDF is still a web page. If you can't play it in a podcast app, it's not a podcast.

</comment><comment><USER51> The new approaches to HTML/CSS run directly counter to the specs sometimes.

Take Bulma for example. They provide styles for titles and subtitles, but their examples use h1 elements.

See: [https://bulma.io/documentation/elements/title/](https://bulma.io/documentation/elements/title/)

Why is that a problem?

This is explicitly addressed in the HTML 5.2 specification.

> h1–h6 elements must not be used to markup subheadings, subtitles, > alternative titles and taglines unless intended to be the heading for a new > section or subsection.

See: [https://www.w3.org/TR/html52/sections.html#headings-and- sect...](https://www.w3.org/TR/html52/sections.html#headings-and-sections)

As the author suggests, they don't understand the tools they're using.

<comment><USER45> I'm not a fan of bulma, but that is not a valid complaint. If you give a `h3` the class `title is-1` it will look like their example `h1`. If you add a `h1` without any classes it won't even have any of the styling of `title is-1` unless you add the classes.

If anything they are purposely decoupling the styling from the semantics to make it more obvious which one you are choosing (although the example could make this more clear).

</comment></comment><comment><USER52> > It's about usability and accessibility. If you don't think the semantic > structure of your Web page or app is important then you're essentially > saying "Well, it works for me in my browser, ship it".

I'm interested, how close to reality is this view of front end devs?

In my day job, it's difficult to get through a project without encountering WCAG 2.x or some other accessibility criteria. Which usually forces you to be more semantic in order to avoid having to be more explicit using aria to tell screen readers etc what your special version of HTML means. Is this so uncommon? This comes up as a contractual obligation all the time in educational products, is this not the case in most other sectors?

<comment><USER53> > I'm interested, how close to reality is this view of front end devs?

It rings true to me. Accessibility isn't really on the radar of many of the developers I've worked with, and managers want business reasons to justify the extra effort that WCAG compliance would require. I didn't start thinking about/pushing for it until I saw a talk at a conference last year.

Education, banking, and government sites are mandated by law to be accessible in the US, but outside of that there's no guarantee that anything will be accessible, what I've seen?

</comment></comment><comment><USER41> > I'm a 'frontend of the frontend' kind of guy. My expertise is in HTML and > CSS,

There are 2 different things: documents and applications. These days you can find IDEs running in the browsers, excel spreadsheets, terminals and all other things which are not HTML documents. Yes, you cannot use

 to style an output of terminal `$ tree ` command. This is why you see
 soup when you examine HTML of the web terminal output.

As web-assembly becomes more mature, I expect developers to abandoned the HTML/CSS scene and leave it to HTML document template designers so there again can be a clear understanding when you have to use HTML.

</comment><comment><USER54> This is what happens. We keep abstracting away. It's amazing how far removed we are from machine code. It's even more amazing that something as simple as HTML was abstracted.

</comment><comment><USER55> There are four types of web sites: static sites made using HTML, dynamic web sites that use both HTML and JS. The third type however is web apps, that like dynamic sites use the DOM, but no HTML! And the fourth type is web apps that only use the Canvas eg. no DOM! So its possible to make a web "site" that only has a script element, and the only DOM interaction is to append the canvas element and add event listeners.

</comment><comment><USER56> Agree. Most of Frontend Devs doing React or Vue, don't know the major aspects of a frontend. Although they are speedy, the quality is low.

</comment><comment><USER57> Unfortunately, a lot of people don't care...

</comment><comment><USER58> It's kind of funny to think about how web was supposed to be extensible with 'type' attribute for script and style tags,but everyone forgot to implement anything other than 'text/css' and 'application/javascript'. Why did it happen?

<comment><USER59> VBScript and Dart were a thing, but they were vendor-specific. Netscape had Javascript Style Sheets in the 90s, where you get the full power of a PL for styling. Then you had Java and Flash through plugins, but they weren't first class citizens with the DOM. However, Sun and Netscape did originally intend Java to be embedded in Netscape alongside JS, but it didn't happen, so Java went the plugin route.

People have tried, but getting the rest of the world to agree is the hard part.

</comment></comment><comment><USER60> this resonates. I interviewed a front end enginner last week who had a few years of experience, so not completely junior. He had been working with React most of the time.

we did a simple live coding challenge that didnt require React. Only some javascript to output some html in the document. They were confused because they couldn't do `return <div>hello world</div>` and couldn't figure out how to instead simply do `return "<div>hello world</div>"` (jsx vs a string of pure html).

It was pretty painful to see but also made me realise how Vue and React can make life easier but seems to get people to know even less how underlying things are working.

I guess it's the fate of all technologies.

</comment><comment><USER61> > In descending order of importance it's the HTML, the CSS, and the behaviour.

I would argue the behavior is more important if the website does anything else other than just show articles.

A beautiful site with no behavior is useless; an ugly site with functioning behavior is not.

<comment><USER62> Behavior and features are two different things. Behavior is more about basic interactivity, like clicking or scrolling. Even websites that just show articles require some behavior to work.

</comment></comment><comment><USER63> Are there really people out there who know and understand Vue or React, but not HTML?

I always found Vue and React to be not good enough abstraction layers - <USER2> still need to tweak and fiddle with the layer below from time to time to make anything work properly.

<comment><USER64> I read the article as "HTML is more than just
 and  \+ CSS", rather than "HTML is the Web" (whatever that means).

</comment></comment><comment><USER65> What is the point the author is making? That the knowledge of HTML is going away? That's obviously false.

> And it is becoming increasingly clear to me that there's a whole swathe of > Frontend Engineers who don't know or understand the frontend-est of frontend > technologies.

I would need some data on this, since it sounds like this claim is backed by anecdotes. None of my co-workers struggle with this and there's lot of frontenders in our company. Semantic HTML's usage is now baked into VS Code in a tooltip.

Yes, every web developer should be at least moderately good with HTML. Can we agree on that? Good :) Learn a bit CSS and now you have superpowers.

HTML only provides the LEGO blocks for the web, but the web is much more than that. It's an interconnected network of information with rich media. What matters is the information persistence, quality and accessibility.

<comment><USER5> I would not consider knowing "a bit of CSS" as knowing and understanding frontend-est of frontend technologies. Alas, there are more than enough cluches available in the form of variouos frameworks so throwing enough stuff at the wall fill finally make some of it stick hence replacing the need of knowledge and understanding.

<comment><USER65> We are talking about HTML. It's really-really easy and I don't think there is a problem at all that the author claims.

<comment><USER51> It's easy to use. It's not easy to use well.

</comment></comment></comment></comment><comment><USER66> No, HTML was the web. We are building web applications now with Javascript. I hope that Web Assembly will end the need to write any HTML tag ever again in our web apps.

<comment><USER62> Which GUI library would you use instead of HTML?

</comment></comment><comment><USER67> back in 2005 I recall losing a bit of faith in humanity, when a subcontractor who was asked to turn a design into markup and "not dare deliver pages laid out using tables" (as it was still quite common back then), delivered a pixel- perfect design, where even those pages that literally had tables displaying information, were laid out with stacks of divs...

</comment><comment><USER68> I recommend everyone that writes HTML to check out Pug (formerly Jade). It makes writing HTML so much easier when it comes to handling classes, attributes, nesting, readability ... well, basically anything. It transpiles to HTML and when using the pretty flag (-P) you can ditch pug anytime if you don't like it and work on the HTML output again. And please tell if you do the latter (and why). I still wait for the person that I recommended Pug to and preferred to keep writing vanilla HTML afterwards.

</comment><comment><USER69> The web has become a compilation target.

Vue -> HTML, CSS, JS

<comment><USER70> That's more literally the case with web assembly. With Vue, I guess I still see it as a form of transpilation.

<comment><USER45> WebAssembly does not replace CSS or HTML unless you render everything to a `<canvas>` which would loose most of the benefits of the web.

<comment><USER70> I understand that. But wasm sure does fit the description of "compilation target for the web".

<comment><USER45> For logic, yes, but not for visuals, interactions, or anything that needs to interact with anything besides itself.

So it might be "compilation target for JS engines", but it sure as hell isn't "compilation target for the web". The web is so much more than just running logic in a browser.

That might come in the future, but it sure isn't the present.

</comment></comment></comment></comment></comment><comment><USER71> My take is; everything will always get more complicated and you can write your nice simple articles but it will not help.

</comment><comment><USER72> Web Assembly, it might not become everything I hope it does, but it has the potential to be a game changer.

<comment><USER45> WebAssembly does nothing for for CSS or DOM. If WebAssembly would change any of this we would just start using `<canvas>` five years ago like flipboard did for a while: [https://engineering.flipboard.com/2015/02/mobile- web](https://engineering.flipboard.com/2015/02/mobile-web)

The Web, when properly used (and perhaps also when it's not) is much, much more powerful and useful than just painting on a screen and running logic underneath.

</comment></comment><comment><USER73> > Search engines need to read your content, not enjoy your swoopy animations > or fancy gradients.

Great way to get your audience ("back end of the front end" engineers and full-stack devs) on side, by trivialising the work we do as adding pointless fluff. Actually in most of my work, the JavaScript is the essential part of the app, and whether it is perfect HTML or not is not a high priority.

</comment><comment><USER30> Gosh please use the correct elements when you make a webpage, even if you're in react vue jsx whatever. It makes browsing the web so much easier for people using accessibility tools, and as the author of this article says, it's very easy to do. There are even automated tools to help test accessibility, with pa11y and lighthouse being the most popular.

</comment><comment><USER74> HTTP is the Web. HTML is just the superficial face of the web.

<comment><USER48> HTTP has been misused recently though, applications that really have nothing to do with HyperText Documents using it as a communication protocol when a lower level protocol would have been more appropriate...

</comment></comment><comment><USER75> <custom-html></custom-html>

<comment><USER51> You could actually do that with XHTML, and it was perfectly valid.

</comment></comment><comment><USER76> HTTP is the web, not HTML.

</comment><comment><USER77> Get on with your jobs. HTML aint ever goin away.

</comment><comment><USER78> I don't need to know HTMl to become a Frontend Engineer. It's the same like, i don't need to know Assembler to be a C programmer.

HTML is the compiled format which browser could understand and run, it's not for human to produce/read it.

We need more powerful tooling/language/framework/library just like what we see in React, Vue,...

<comment><USER79> That's a very narrow view. Machine code is ran in one context – the CPU – with the compiler worrying about this one context. Meanwhile, HTML is parsed by much more than a browser.

Like the article says, there is literally zero drawback to being slightly more semantic. In fact, semantic HTML probably improves your own code, making it easier at a glance to see what components do.

<comment><USER80> > Meanwhile, HTML is parsed by much more than a browser.

Any examples?

<comment><USER81> Bots and email clients. Microsoft word. Libre Office.

<comment><USER82> and anyone still using an RSS reader. Anyone sharing something on Facebook or other social media, _me_ when I'm trying to write an app to do something interesting for which there is no existing API.</comment></comment></comment></comment></comment>


Considering Rust [video] - <AUTHOR> https://www.youtube.com/watch?v=DnT-LUQgc7s <comment><USER2> I've just "incompleted" my first Rust project: a Minecraft server. I gave up due to the protocol, not Rust. I finally learned the damn thing after spouting its hypothetical advantages all over the internet. My overall conclusion was correct, but the reasoning incorrect. The borrow checker is an amazing pair programmer, but that's not the primary reason I'm having genuine fun.

Rust is a systems language that _is a pleasure to build._ This "how to build on Mac/Windows/OSX" is a non-issue and should be a non-issue. Solving how to build something is an utter waste of time and is complete bullshit.

Please, for the sanity of the rest of us, stop using C build systems. They are just unbelievably terrible; people have tried and tried, but you can only do so much with a fundamentally flawed bad idea.

<comment><USER3> Couldn't agree more. I often have to install programs from sounce, and dynamic linking, header files/include paths, etc. make the C build system extremely unreliable. It's often more of a trial and error process ("which library is it going to be missing next") than a methodical one. I've spent countless hours hunting down why libfoo.so isn't loading correctly, or why some random function is undefined at the compile stage.

</comment></comment><comment><USER4> > Jon Gjengset

> The Rust programming language has become a serious contender in the space of > "systems" programming languages, and has recently been adopted by many of > the tech giants for "serious" projects. In response to this, more companies > are now considering whether they too should add Rust to their tech stack. > This talk hopes to help you make that decision. We go through how the > language compares to many current alternatives and what the language has to > offer, but also what it's primary drawbacks are and its long-term viability > prospects.

[https://jon.thesquareplanet.com/slides/considering- rust/expo...](https://jon.thesquareplanet.com/slides/considering- rust/export.pdf)

<comment><USER5> Jon has been working on a reasonably large Rust project called Noria[1], "a new streaming data-flow system designed to act as a fast storage backend for read-heavy web applications".

I found his Rust live coding sessions on YouTube[2] to be an enjoyable introduction to Rust.

[1] [https://github.com/mit-pdos/noria](https://github.com/mit-pdos/noria)

[2] [https://www.youtube.com/channel/UC_iD0xppBwwsrM9DegC5cQQ](https://www.youtube.com/channel/UC_iD0xppBwwsrM9DegC5cQQ)

</comment></comment><comment><USER6> I've been getting into Rust lately and really enjoying it so far. Coming from JavaScript, It can feel a bit verbose at times and I'm still trying to get an intuitive grasp of ownership but it feels like a really small cost compared to say C/C++. A nice bonus is that it has very good support for WebAssembly/Node.js which makes it easy to start using Rust for some JavaScript modules without having to re-write the whole codebase. And finally, the community is still very noob-friendly.

<comment><USER7> I felt the same, coming from JavaScript and Python. Then I realised "verbosity" is actually "the language demanding you be crystal clear about what you're asking and that every code path is covered."

I just can't go back. Typescript gives me most of this. But Python feels just awful to me now. It's like an entire kind of cognitive load is being eliminated from my day.

<comment><USER8> I've had some luck with Mypy, but it's still very bolted-on. Even getting the type checker to find dependencies installed on your system is nontrivial. But this sort of tedium is just par for the course with Python.

</comment></comment></comment><comment><USER9> I'm 20 minutes in and he's spending a lot of time talking about how Rust gets correctness right.

Are there any anecdotal stories about how Rust programs have fewer errors?

Facebook, for example, rewrote Messenger with ReasonML:

[https://reasonml.github.io/blog/2017/09/08/messenger-50-reas...](https://reasonml.github.io/blog/2017/09/08/messenger-50-reason)

And it had a lot fewer bugs:

"Messenger used to receive bugs reports on a daily basis; since the introduction of Reason, there have been a total of 10 bugs (that's during the whole year, not per week)! *"

<comment><USER10> anecdote incoming!

In my previous gig, we had a premium website hosting platform, and our incoming clients would usually want their old inbound links to keep working. Over time, this meant a few hundred thousand autogenerated rewrite rules in Nginx. This was causing Nginx to use about 10G of memory, so restarting it, which we had to do every time we added a redirect, was an issue.

I replaced this with a small reverse proxy written in rust that loaded all of the redirects from postgresql into a cuckoo filter. Adding a redirect was an INSERT, followed by a NOTIFY to let the proxy know to add the redirect to the filter.

Putting it all together took about 2 weeks of swearing at the compiler, but it never had an issue in production, and used about 1M of memory, while adding less than 1ms of latency, or about 4ms in case of a filter hit. Cuckoo filters can have false positives, so if a redirect was found, we still had to check in the db table before returning 301.

As far as I know it's still working fine, and I use rust whenever I can.

<comment><USER11> Interesting! Any chance you can share a few tips to get started doing the same? (eg any crates to use or other tips). I'm currently looking for a rust learning project and building what you described really hits the mark!

</comment></comment></comment><comment><USER12> Rust is interesting, so I decided to include it in a 3 language prototyping project. I wanted to experience how it is to code for these languages, compared to the outcome. The project was dead simple, read 2 files concurrently and match lines by id's. Data was a bit unstructured, some lines would go unmatched, some would be duplicates, and report on that while deallocating memory for processing large filesizes.

Ruby: Quick fun building the classes and methods. A bit trial and error on dynamic errors. Processing was 40x slower than golang implementation though, so felt a bit discouraging after the fact. But was fun language to prototype OO in! Nice for quick'n dirty projects.

Golang: I didn't find need for OO or interfaces, so simplified for processing code mostly. The language helped in this regard, as it is quite imperative- driven. Golang was the fastest language to develop in, and showed Ruby version to be a bit over-engineered.

Rust: Never coded in Rust before, I searched SO for most relevant code examples and patched it up from several examples. I didn't go into the deeper end of things or optimize anything, but instead spent 90% of the time writing naive processing code while battling the compiler. If I'd been proficient, perhaps no battle, but this required the longest dev time and processing was noticably slower than Go, though not by a factor.

From this short anecdotal experience: Ruby for quick'n dirty fun or OO modelling. Golang for prototyping _and_ initial versions. Rust for where _you know_ you need safe parallellism and special optimizations. Right tool for the job!

<comment><USER13> For me, Rust also fits "fun language to quickly prototype type system in", but I've been hacking in Rust since its 0.* days; if I were to try to do it in Ruby/Go which I've barely ever touched, it would sure take me way much longer.

If I were to compare Rust to Python/C++ which I'm proficient in, Python would be the fastest because there's zero setup time, tons of quality packages and notebook environment; C++ would take a lot longer due to having to set up builds, and due to lacking stdlib and ecosystem.

</comment></comment><comment><USER14> Even as a fan of Rust I've become exhausted by these posts. Surely everyone on here must at this point know what Rust is and roughly why people use it?

<comment><USER9> I don't think Rust has reached wide acceptance yet.

Sure there are companies that use it, but I bet you'd have a hard time convincing your manager that Rust is widely accepted in industry.

Anyway, I certainly appreciate all of the posts.

<comment><USER14> Not widely accepted in industry, but widely accepted (or at least known) among HN readers

<comment><USER15> Which is a very small percentage of people in tech. In my network Rust is still very new to unknown in some tech companies. I will say Go is more the language that emerged.

<comment><USER14> Yes but we're not talking about the prevalence of these in general, just on HN

</comment></comment></comment></comment></comment><comment><USER16> Can somebody please explain why Rust has so much buzz right now compared to scala?

Scala is a strongly typed, very-well vetted, functional programming language in the JVM. It pretty much has everything going for it. It's even adopted by twitter.

<comment><USER17> JVM, garbage collected, doesn't have zero overhead abstractions.

Might as well ask why Scala didn't take over from C++.

<comment><USER16> I don't know why you'd be dismissive of that comparison. Scala is more like Rust than any other language he discusses.

<comment><USER18> Because performance is a P0 concern to a lot of people. Rust (and C++) has performance as a primary goal, Scala does not.

<comment><USER16> Did you even watch the video? The guy is comparing rust to things like Python which is a pretty silly comparison, relative to scala.

<comment><USER19> Everybody knows python, few people know Scala. Isn't that enough of a reason?</comment></comment></comment></comment></comment></comment>


Show HN: Flynx – Browsing on mobile just done right - <AUTHOR> http://flynxapp.com/

<comment><USER2> If you're going to use fake accounts you just created to comment and upvote your submission (12 points in 7 minutes, and each commenter's account has 1 karma), don't make it painfully obvious.

<comment><AUTHOR> We are sitting in an event where these guys are presenting in India. Delhi. @TLABS

NOT A SPAM

<comment><USER3> I'm afraid it has the same effect. Anyone is welcome to join Hacker News. But when a group of people do it all at once, just to promote one product, that's not ok.

</comment></comment></comment><comment><USER4> Makes life much more easier. How many tabs can I open on it ? I've tried opening 3 links.

<comment><USER5> It allows you to open 4 tabs right now.

</comment></comment><comment><USER6> Amazing stuff....makes life easy by opening links w/o opening a new tab on browser :) :)

<comment><AUTHOR> It indeed is. Floats like a chat head.

</comment></comment><comment><USER7> This looks really smooth. Congrats a shipping a great product.

</comment><comment><USER8> Wonder how is it different from Link Bubble ?

</comment><comment><USER9> Cool product. Is it free?

<comment><USER4> No. Costs $50 / month ... lol .. just kidding. Its absolutely free

</comment></comment><comment><USER10> very good browser turned out to be very useful for me :)

</comment><comment><USER11> what actually floating browser means how does it works?

</comment><comment><USER12> seamlessly useful ;)</comment>


Why Cities Aren't Ready for the Driverless Car - <AUTHOR> http://www.wsj.com/articles/why-cities-arent-ready-for-the-driverless-car-1461550001?mod=e2fb <comment><USER2> > Similarly, unmanned vehicles might proceed at speed through an intersection > where a stop sign has been removed by college students or knocked down the > night before by an impaired human.

But so would human drivers. In fact, a self-driving car may actually do better in this scenario because it would have metadata stating that the last 3,000 times a car encountered this intersection, there was a stop sign here.

<comment><USER3> It seems to be really hard to get people to compare driverless cars with real humans, and not imaginary perfect drivers.

For another example, there's the nigh ubiquitous question of how to handle ethical dilemmas, like a crash where you have a choice between crushing a nun and crushing a baby carriage. Nobody ever seems to consider the fact that human drivers will almost never consider the ethics of the situation when choosing an outcome, and in fact probably won't deliberately choose any outcome at all, but will merely brake and steer by reflex.

<comment><USER4> If you're ever driving in a situation where it is possible for a nun or baby carriage to jump in front of your car without any warning, you should be driving at 30km/h (20mph) or less. This gives you a stopping distance of approximately 1 car length, so stopping is always a better option than trying to steer around an obstacle. It also means that any collision with a pedestrian is highly unlikely to be fatal.

Of course, having automated cars driving at 30km/h through the suburbs is going to piss everybody off, but that's better than dead babies.

<comment><USER5> I'd wager a driverless car can afford to go a little faster, given its reaction speed is likelier much, much faster than anything a human can put out.

In fact, a driverless car may be capable of estimating its own stopping distance given road conditions and other measurements, account for some margin of error, and then use that to calculate how fast it can go down a road, while still adhering to the posted speed limits.

<comment><USER6> If the human in the car isn't impatiently driving it, they'll probably be happier with a slower, safer, and more comfortable ride while they fiddle with their phone or do work on their laptop. Speed has no business, frankly, on residential drives. I don't think it even helps you get anywhere much faster -- it's more about venting schedule anxiety onto your gas pedal.

<comment><USER7> _Porsche shoots past at 30mph over speed limit._

"He won't get there any faster"

(Yes, he will. It's pretty simple to work out exactly how much faster actually)

<comment><USER6> 55 in a residenial zone? WTF?

</comment></comment></comment></comment></comment></comment></comment><comment><USER8> Guys here's my prediction on this.

Cities will become completely Undriveable and possibly off limits to cars once the majority are self driving.

Here's why; pedestrians will know that all cars will stop for them and people will just start crossing anytime they want and even start simply walking in the street. There might be some jaywalking enforcement attempts but ultimate they'll fail.

What do you guys think?

<comment><USER9> I think we _know_ (i.e. 90% of the time) that people will stop for us if we walk out in front of them with ample notice and conditions... It's more from a norms / politeness perspective that we don't; it's simply not accepted that you can just walk into the road when you want to get across because (most of us) we don't want to be judged by others for behaving recklessly, either by the driver we're forcing to stop or the other pedestrians.

There will most often than not still be people in these driverless cars that we will irritate, and pedestrians that we fear will scorn us. However, I think you make a good point about non-passenger vehicles. Perhaps we will be more likely to walk out in front of an unoccupied Uber that we know will stop for us on an empty street where no one will judge us — but this won't affect the busy streets / scenarios where it's most important that I mention above.

Interesting prediction, nonetheless...

<comment><USER10> I go out of my way not to step in front of a car if it is on a trajectory that would hit me. It's a "never trust the driver" mantra.

These aren't busy city streets where I'm making that choice, but I'm not getting to the point where I'm being considerate of the driver, I simply don't want to create the situation where I am dependent on their noticing me.

<comment><USER11> I do the same, but will walk as if I'm about to (as long as I'm in a crosswalk, where drivers are supposed to yield to pedestrians). I can stop walking way faster than drivers can stop their cars, so they basically have to lose the game of "chicken" or be willing to run over pedestrians in crosswalks. Only once they've visually committed themselves to stopping do I take that last step into the path of the vehicle.

It's a little douchy, but goddamnit, California law says I've got right-of-way in crosswalks. When you're holding a mutex, what you do is get rid of it ASAP and get out of the way.

<comment><USER12> "California law says I've got right-of-way in crosswalks"

That's for the safety of the pedestrian in order to avoid confusion and make liability strictly fall on the shoulders of the party with the 2 killing machine.

Regardless of my legal right-of-way, though, I try not to be a jerk about it.

<comment><USER11> If you're about to cross a crosswalk, you're contributing to the attentional noise that drivers have to deal with. IMHO, just get out of the way so that fewer people have to make sure that they aren't going to hit you.

<comment><USER12> I generally agree that doing a dance entering the crosswalk is unhelpful, but there are lots of cases where you can stand back and wait to enter the crosswalk in order to avoid making a car slam on its breaks.

<comment><USER13> >making a car slam on its breaks

If you need to "slam" on your breaks to let a pedestrian cross, you are driving too fast.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER14> Did the author actually ask the makers of self-driving cars whether these are real problems? Many of the problems listed in the article seemed relatively easy to solve (compared to the difficulty of building a self-driving car).

<comment><USER15> Henry Petroski is well known for writing about the history of civil engineering failures, so perhaps he's just extrapolating from his experience?

</comment></comment><comment><USER16> Articles like this feel like they were ripped from another century.

"Why cities aren't ready for the horseless carriage."

... Sure, they may not be. But that doesn't mean that change will stop, or that they have to be ready overnight. It means that we'll have to deal with these things eventually, and I'm betting it's sooner rather than later.

</comment><comment><USER17> I actually had a long discussion about this with an Uber driver the other day. Given that this article predates that discussion, I would imagine he was sourcing a lot of his arguments from this article.

My position in this discussion is that yes, infrastructure improvements are necessary, but they'll be relatively straight forward in the US, as basically every city in the US was designed to support automobile traffic.

Self driving cars are going to have a much tougher row to hoe in Europe and Asia, where city infrastructure predates the automobile by centuries/millenia

<comment><USER18> >My position in this discussion is that yes, infrastructure improvements are necessary, but they'll be relatively straight forward in the US, as basically every city in the US was designed to support automobile traffic.

This is not to say that it's impossible, but US cities barely manage to get the infrastructure upgrades and maintenance they need now - Google et. al. have a lot of money, but I'm not confident they can play bureaucracy well enough to get some of the infrastructure improvements necessary for either large fleets of SDC's. I admit, the idea of replacing all the individually owned cars on the road with a fleet of summonable automobiles is very appealing; it just seems like there are a lot of intermediary steps that are less about technology and money than they are about politics and personal interests.

</comment></comment><comment><USER19> I've wondered several times, how could a human on the road interact with an autonomous car? For example, if a lane is currently closed and alternate traffic is in place on the other lane, how can a traffic cop instruct the car to stop there for a while and then proceed to cross a double white line and move in the usually-wrong direction? Or, how can you explain a car that a bridge is blocked and it has to take the next one?

</comment><comment><USER20> >And in cities where it is customary for human drivers to anticipate the red light turning to green by inching into the intersection prematurely, will the driverless automobile allow for the custom?

I can't believe they are describing this as a custom rather than a dangerous behavior born of impatience. I grew up in a place where people did this and it only took one close call with a clearly drunk driver flying through a red across the intersection in front of me to make me stop for good. Why would anyone design a self driving vehicle to emulate this behavior?

</comment><comment><USER21> I'm more optimistic that the NTSA will rise to meet the challenge because there is so much benefit and momentum (thank you Elon Musk) to making them work.

My favorite article on the subject[1] extrapolates how much impact autonomous vehicle technology will have. I'd actually be pretty surprised if it hadn't come across the desks of the GM executives involved in the half a billion dollar Lyft investment[2]. The Obama administration seems to be making a real effort to lay the groundwork for the necessary infrastructure and regulatory resources[3].

Also, if you haven't read/watched this, don't pass go: [http://www.bloomberg.com/features/2015-george-hotz-self- driv...](http://www.bloomberg.com/features/2015-george-hotz-self-driving-car/)

[1] [http://zackkanter.com/2015/01/23/how-ubers-autonomous- cars-w...](http://zackkanter.com/2015/01/23/how-ubers-autonomous-cars-will- destroy-10-million-jobs-by-2025/) [2] [http://www.bloomberg.com/news/articles/2016-01-04/gm- invests...](http://www.bloomberg.com/news/articles/2016-01-04/gm- invests-500-million-in-lyft-to-bolster-alliance-against-uber) [3] [http://www.usatoday.com/story/money/cars/2016/01/14/nhtsa- de...](http://www.usatoday.com/story/money/cars/2016/01/14/nhtsa-detroit-auto- show-autonomous-vehicles/78792868/)

</comment><comment><USER22> I have to complain that the WSJ's title is completely backwards. Petroski's article is about the sensible topic that _self driving cars aren 't ready for the typical real-world chaos_. In fact he glossed over Audi's "99% of the trip was autonomous" claim -- that 99% was on freeways which while hard, are well structured.

I can't wait for self driving cars for a jillion reasons but I am dismayed when advocates claim that the infrastructure must change to support them. That's completely backwards: our tools should support us, not the other way around.

<comment><USER23> That is a losing game. Years ago, I worked on a DARPA project that would let radios opportunistically use available frequencies instead of fixed ones. Doing this with a totally uncooperative environment, relying only on the wits of the software, is _really hard_. Like still in development after more than a decade hard. Like Microsoft and Google gave up on solving an easier problem hard.

Self-driving cars in an uncooperative environment is probably an order of magnitude harder than that. Demanding that they work in an uncooperative environment results in a problem that is probably intractably hard.

<comment><USER24> >> Self-driving cars in an uncooperative environment is probably an order of magnitude harder than that. Demanding that they work in an uncooperative environment results in a problem that is probably intractably hard.

That's why I'm skeptical of self-driving cars becoming widespread in the U.S. in the next decade. Driving in an unknown environment over millions of miles of roads is going to be a huge challenge if the infrastructure doesn't change, but I can't figure out which political party is going to support the massive infrastructure project. The early adopters of this technology are probably going to be transportation companies. Democrats are going to have a hard time advocating for spending money that throws truck and taxi drivers out of work. And good luck getting Republicans to spend additional money on anything.

I hope that google and/or the car companies pull it off, but I don't think that we should hold our breath waiting for the world to adjust to self-driving cars. The hardware and software will have to do 99% of the work.

</comment></comment></comment><comment><USER25> I just don't think that we as a society are ready for the driverless car. We are not ready to give up the freedom and the semi-anonymous nature of driving. I know you'll that with ubiquitous cameras that we are already being tracked, but that is different from the continuous, high-fidelity tracking that will be in place on these cars. I trust neither the private companies nor the government to keep this data secure. I expect that within my driving lifetime that I'll be forced to choose between lower insurance (for driverless cars) and driving myself. That makes me sad.

And consider, if you will, how this can become the modern version of "Red Barchetta" if you did choose to keep driving yourself.

<comment><USER26> You can have self driving cars where you can turn the system on and off like you can on the Tesla S. That would work for me. I can't see them banning human driving in a hurry.

<comment><USER25> Not "banning" but you will pay higher insurance. Then we'll have a society where only the wealthy can drive their own cars for pleasure.

</comment></comment></comment><comment><USER27> The author naively assumes that driverless cars are going to be replacements of human drivers in most ways. This is an extremely ignorant view that lacks a lot of imagination. Everyone actually working on driverless cars has been thinking of all these potential gotchas for years and have been designing and engineering with these gotchas in mind.

</comment><comment><USER28> My prediction (I'm well aware this is worthless, as nobody cares about random- internet-guy's predictions enough to follow up) is that there will be a handful of cities that will try their best to orient themselves around self driving cars, and like the cities before them that tried to orient themselves around cars, they will fail. Most of the fanciful predictions from self- driving car futurism are incredibly naive and fail to take into account basic facts about how cities function from a systems perspective.

1) _Traffic will disappear because cars can stop faster and travel close together_. At best there are a tiny minority of driving scenarios where driving closer together or stopping quicker are the system bottlenecks. Rush hour traffic is not one of them. At best, you will drive faster on highways, but that will just get you to your exit faster, where you will spend more time waiting than you used to because intracity bottlenecks haven't changed. Traffic lights will still continue to make tradeoffs between latency and throughput, and self driving cars can't take away that tradeoff. And cars will continue to drive slow enough to stop for typical city obstructions (like cyclists, pedestrians, etc.), even if they have a few milliseconds faster of a reaction time. And you're still going to have typical rush hour volumes of people coming from multiple different places converging on a single area.

2) _Haven 't you seen the simulation where self driving cars don't need traffic signals anymore cause they can drive right through without stopping or hitting anybody?_ Guess what, it's a simulation...one that conveniently ignored almost every other relevant factor about how the world works. Like pedestrians. Dogs. Joggers. Cyclists. Handicapped people. Gridlocks that happen due to bottlenecks on perpendicular streets. Street protests. Weather conditions. In fact, the only way this idea feasibly works is if you are in a remote intersection in the middle of somewhere so unimportant that it doesn't have any other obstacles or traffic types, in an area where non-driverless cars are banned. And guess what...those situations get along quite fine with traffic lights.

3) _But you won 't have to circle around the block endlessly to find parking!_ Actually, your situation isn't much better, and if you see a rise in commuting by cars it could get much worse. Your traffic lanes will be continuously blocked by people getting in and out of their cars. Think of the airport arrivals and departures loops...nobody there has a need for parking, and yet still they are a traffic nightmare because everybody is either getting in a car or getting out of a car, and you have cars blocking traffic looking for _their_ specific passenger, and you have cars circling around the block anyway because there is nowhere to stop legally.

I could go on and on. Traffic is the external manifestation of a system that is far more complex than streets with a few bad drivers clogging shit up. It is a manifestation of the interaction between cars and non-cars, economies and the humans that contribute to them, all with different goals and objectives, all trying to use a shared but very scarce resource. It isn't going away. Ever. The best you can do is find ways to move more people through it faster, and from that perspective the geometric reality of an automobile is grim. No matter how optimized for ommitting the driver it may be, a car will always take up exponential amounts of space compared to public transit systems.

But that isn't a reason to not pursue them. They should still be pursued on safety grounds alone. They just won't answer your prayers for a traffic-free city.

</comment><comment><USER29> Why I'm Not Ready for the Uninformative Headline

</comment><comment><USER30> The one thing the author doesn't seem to be taking into account is that the cities are much easier for them to change as needed. The infrastructure is more dense and (usually) more orderly designed, and access to electricity to add beacons, as well as access to all kinds of networking resources already in place for traffic work is pre-existing. Augmenting cities for self driving cars is going to be the bunny hill compared to augmenting the interstate highway system to them.

<comment><USER3> Automated interstate driving is nearly a solved problem already. My car will easily go for hours hands-off on most interstates. The only infrastructure you need is clearly marked lines, which already exist on most of them. There's no way that cities are easier to change as needed, when interstates don't need to change in the first place.</comment></comment>


Ask HN: Would you be willing to pay for ad free "Facebook" and how much? - <AUTHOR> <comment><USER2> I would not. I am 44, so I remember what life was like pre-internet. I have considered how I have kept in touch with people over the years, what my relationships were like, what made me happy, all these things... and I have come to the conclusion that Facebook has been an almost completely negative experience across the board.

I have claimed my name, simply because it is a common one, and I don't want to be denied some future job because of something a namesake posted. That that is even a concern is a large part of what makes Facebook awful.

Now, all that being said- I still think that something like what we call social media today _could_ be a positive experience. I just don't think any of the current platforms are there.

</comment><comment><USER3> Maybe. It depends on what kinds of guarantees they'd give around use of my data. I don't really care about seeing ads per se, I care about invasive tracking and data harvesting.

I think I might pay $10/year to use Facebook without them looking over my shoulder.

<comment><AUTHOR> By ads free I meant their core business would be about not tracking you and only providing services of showing you content your friends publish.

Like you said it depends on what kinds of guarantees they'd give around use of data. How guarantees _can_ you give?</comment></comment>


Gilt Groupe Valued At $1 Billion  - <AUTHOR> http://online.wsj.com/article/SB10001424052748703730804576313330486181732.html

<comment><USER2> "In addition, its core discount-fashion business is coming under pressure from the recovery in the luxury business."

Interesting, I hadn't thought of gilt as being counter-cyclical until now, but it definitely makes sense.

I wonder how companies like they and wine.woot will survive once luxury brands aren't hurting so much. Will they keep these deep discounts around to build buzz, or cut the cord?

<comment><USER3> From what I've heard from the company, the merchandizing for the fashion business has been under pressure for quite some time. Their early growth was mostly limited by having goods on hand. Now the lack of product distinction and lower margins are making it a tricky business to run.

Personally, it was a great concept that's been successful many times, but I do find this valuation a bit too close to something like "round up to the nearest billion" to make sense. Further, they've wasted a lot of time lining up their technology to make the new product sites work well and internationally (i.e. serving up in Japan was a mess organizationally). It's quite silly to see them posture like this but I guess it comes with their ridiculous attitude over there.</comment></comment>


Show HN: My book on PHP 7 - <AUTHOR> https://leanpub.com/php-7 <comment><USER2> If you make a free sample, you better include something more than just a short introduction. When I found an interesting book in a bookstore, I usually open it in the middle. This way it is easier to get idea how the author writes and what his style is.

"A brief history" and "What's new..." I can find such things on the Internet and rewrite them. Everyone can rewrite, right?

So, what I mean is, you have to win your potential readers by your style, your ability to explain things and so on.

<comment><AUTHOR> Thank you for the great advice! You're right, I definitely should update my sample.</comment></comment>


Things no one tells you when you start a newsletter - <AUTHOR> https://chrisshort.net/things-no-one-tells-you-when-you-start-a-newsletter/ <comment><USER2> Seems like Substack was built to solve the problems that the author mentions. Curious how good a job it does - it seems to be gaining traction lately.

I have been considering it as an alternative to Medium, although Medium does have the best distribution story out there so far.

Am also curious how many DevOps'ish readers are using IE6 to read his website. :)

</comment><comment><USER3> Interesting about the advice not to have "weekly" in your newsletter, due to the implied deadline.

I'm curious how this plays into other advice I've read from content creators, that delivery consistency is key. And that the cadence you should finalize on should be something like N-1, where N is the amount of content you can consistently produce in a period. That way you have a pipeline and a backlog to allow you to take time off, or be sick. You can create 20 webcomics a month? Great, find 3 days a week to publish. 20% overcapacity seems to be a good number based on multiple sources I've seen from mostly solo producers, and it allows them to be consistent while not burning out.

</comment><comment><USER4> This feels like 4-5 random ideas that don't really fit together, combined into one post.

DNS and good source IPs are mentioned and it starts off as if it's going to be fairly technical, but then talks about ideal cadences, and some guy called Gareth. Then markdown and Hugo?

Good writing, but I would suggest more thinking about what your point is and then making it.

<comment><USER5> I disagree. If you've run a mailing list of any reasonable size before you'll quickly run into the same experience the author had: you have to get good at a lot of disparate skills in order to keep the list from falling apart, either due to user attrition or technical reasons like spam traps and engagement metrics.

The OP didn't pitch this as an exhaustive reference of every issue that can come up, but it's a good sampler of the kind of problems you have to deal with, and stuff that most people wouldn't even think about.

</comment></comment><comment><USER6> I'm sure someone would tell you, if you subscribed to their newsletter.</comment>


An Eavesdropping Lamp That Livetweets Private Conversations - <AUTHOR> http://www.wired.com/2014/04/coversnitch-eavesdropping-lightbulb <comment><USER2> Wired,

If you are here reading this, please don't require a certain orientation for my iPad. I will not be bullied by you full screen popup telling me to rotate when I was getting along just fine before your interruption. I don't want your watered down Internet on my mobile device.

Thanks.

<comment><USER3> I received that msg too. I don't know if you saw the tiny close box in the top right, but it dismissed the message and I was able to read the article.

<comment><USER2> I didn't. I have seen too many mobile "optimized" sites that make me more frustrated than it's worth it to view the content so I just went back a page. This is similar to the sites that paginate articles on mobile and make it so that each page "view" is in the browser history requiring a back press. It's hostile to the competent mobile web browsers.

</comment></comment></comment><comment><USER4> Are there more technical details?

> It screws into and draws power from any standard bulb socket.

Interesting, is this a common Rasberry pi capability?

> Then it uploads captured audio via the nearest open Wi-Fi network

How does this part work? Are they preconfigured for nearby networks? Even most public wifi channels require basic user authentication, even it they aren't password protected.

Edit: found the github repo [https://github.com/brianhouse/Conversnitch](https://github.com/brianhouse/Conversnitch). I don't see anything regarding connecting to WIFI automatically, they must be preconfigured for each location. Also this project is 7-8 months old.

</comment><comment><USER5> Normally I'm all for provocative art projects, but I can't help being entirely put off by this one.

<comment><USER6> Same here. To be perfectly honest I'd feel like sucker punching these artists if it were my convos.

</comment></comment><comment><USER7> There was a time when such products sent their messages to IRC.

Now everything sends Tweets, which ironically, can leave a bigger digital trail from whoever set up the account in the first place and then anyone who may view / follow it.

IRC leaves a smaller trail and is easier to set up a bouncer to read from.

I bet plenty of today's hackers have never been on IRC or read bash.

<comment><USER8> That's kind of the point of tweets, "leaving a bigger trail" in the minds of people who read them than IRC messages (that can be said and then vanish away in the sea of chatter or get swallowed by the low signal/noise ration never even getting to be read). By actually having to subscribe to someone be notified of the tweets you increase your signal to noise ratio and you tend to actually read most of the messages and most importantly _to share them_ in a different way than just throwing them away to drown in the sea of noise of a chatroom.

Now, to have this bigger "social/communications/memes trail" you also have a bigger digital trail that can be used to find and target people, but you need to pay a price for anything.

To me IRC has always been an instant-messaging and conferencing tool and I never understood how people could have communities in that chaos or even use it for things like technical discussions and project management. That's what mail groups were for back in the day (and still are, thank god!).

<comment><USER7> I mean for spying tools. The C&C is much easier with IRC, just have keyword triggers. You don't have to have all the hassle of the Twitter API, IRC is just a byte stream.

As for the wider IRC. I've not found it a problem then again I've been in channel for nearly 20 years. My client is in channel 24/7 so you only miss as much as you want to.

OTOH in that time I've gone from icq -> MSN -> googletalk -> facebook chat. As IM support comes and goes from the big players as they get bored with it. The only thing that's changed in IRC in that time is SSL transport.

</comment></comment></comment><comment><USER9> Bruce Schneier touched base on this, too. He noted how simple it would be for non-artists (i.e. spies, criminals, the IRS) to develop the exact same capabilities.

[https://www.schneier.com/blog/archives/2014/04/conversnitch....](https://www.schneier.com/blog/archives/2014/04/conversnitch.html)

</comment><comment><USER10> Those tweets feel completely made up to me.

<comment><USER11> At the very least they've definitely been run through a middle-man at some point. So what they've done is put a microphone in a library, grabbed whatever audio is on it, voice recognition'd it and then cleaned it up, and uploaded it to Twitter. And hidden it inside a lamp. _shrug_

<comment><USER12> They are not even using software for voice recognition. Instead, they are paying people pennies an hour to do it on Mturk.

</comment></comment></comment><comment><USER13> Isn't this the same as the rumor mill?</comment>


If can self fund, why not just hire project managers and not partners? - <AUTHOR> Has anyone who has self funded done this approach while in incubator:
Hire freelance project managers to manage freelance  programmers to create and complete the projects.
This is approach I am taking.  I have struggled finding a co-found w/ desire and skill I need and I was thinking do I really need a cofounder, when can just use freelancer at 1st?
I have the passive income and some saving to boot strap for a while until working prototype is created and I am able to make a effective video  pitch of my product, so I can get accepted into some of these launch conference.  Then, with some networking and hopefully some early angel investors on board, I can find others who can have equity in the startup if they are willing to put some skin in the game.  This will give me much more time to find the right people to join my team and allow me to have something to show that maybe worthwhile for an eager tech entrepreneur, looking for a good  idea to be a part of the team.
I have wasted a ton of time just looking for potential co-founder.  time to get the show on the road.
I would appreciate any mentoring  or input  from veteran startups that followed  a similar path.  Thanks <comment><USER2> I've had experience in every configuration imaginable -- except having a cofounder.

What I found is that farming out work is effective, but it also introduces a lot of friction into the customer/product development cycle. Somebody you pay just isn't going to have the passion you are, they are going to do exactly what you tell them (and sometimes not much else), and they very, very rarely help you get a grip on which way to go.

My conclusion is that self-funding and bootstrapping as a loner is probably best until I absolutely must bring somebody else in, at which time I plan on using an intern. That way I have no illusions about what I'm getting in the deal.

I think you can do it. I would just be careful.

<comment><AUTHOR> Thanks so much for the input dave. I am learning the hard way that some freelancer do as little as they can for as much money as they can. I am hoping to get to point that can find some quality interns to do some of work load. my biggest issue is find a quality IT project manager to manage the outsoruce project. That will take someone I will want I can work with and trust and will to give equity into the company. Hopefully I can get into some of these tech conference and meet people like that.

</comment></comment><comment><AUTHOR> HOW DO I edit title so it shows it is an "ASK HN"?</comment>


Google does not want rights to things you do using Chrome   - <AUTHOR> http://www.mattcutts.com/blog/google-chrome-license-agreement/

<comment><USER2> Great - that clarifies it. End of story. Now can we clear some room on the HN front page for some real news ;)

</comment><comment><USER3> The reaction against the EULA is way overblown. It sounds like an astroturf FUD attack against Google by corporate opponents who realize that Google just hit one out of the park.</comment>


Startup and entrepreneur visas around the world - <AUTHOR> https://futureworkpresent.com/startup-visas/ <comment><AUTHOR> Based on the success of Silicon Valley, an increasing number of countries are trying to make it attractive for startups to be based within their shores.

They do this through startup visas, special programs and economic zones - here's a list of them.</comment>


Elf on the Shelf Preps Children for the Surveillance State - <AUTHOR> http://eagnews.org/prof-elf-on-the-shelf-conditions-kids-to-accept-surveillance-state/

<comment><USER2> As a guy with a much younger sister (11F) who has had an elf on the shelf for 2 or 3 years now, this article literally made me laugh at my desk. If you use your elf on the shelf in this way, I do agree it is slightly creepy. IMO, you should use it as a fun thing for kids at an age where they sort of realize the santa and all the christmas stuff isn't real, but is a fun thing to do; where it is a "lets take pictures of the silly thing the elves did last night while you were sleeping!" Most kids slowly start to realize it is all fake and fun, and at that age it becomes fun to play with the elves as family activity. When my sister first got one, she expressed that it was kinda creeping her out and without having to say out loud that santa isn't real etc., they let her know that it was all just fun and games. I have one that was "assigned" to me as well and honestly find it a blast taking pics with my roommates and I with the elf and sending them to my sister/little cousins. In fact I took mine on a christmas themed barcrawl and we had a blast taking pics of the elf with beers and in hilarious places.

But even if a parent is using them explicitly as a "the elf is watching and will report back to santa", while that is creepy, the step they are taking that it prepares children for the surveillance state is the stupides thing I have ever heard. You are taking a ridiculous step trying to extend what the elf on the shelf experience CAN BE with bad parents to psychologically/subconsciously preparing kids to be OK with the government spying on them as adults.

Even if you were to take that step, I would guess most parents don't use elf on the shelf in that very serious kind of way. It is honestly shitty parenting if anything.

</comment><comment><USER3> There's a nicer alternative called "the Kindness Elves".

[http://theimaginationtree.com/2013/11/alternative-elf-on- she...](http://theimaginationtree.com/2013/11/alternative-elf-on-shelf- tradition-kindness-elf-kindness-elves.html)

This page links the Kindness Elves to Christian stuff, but it's obviously easy enough to ignore that.</comment>


Phonebloks' Thunderclap campaign happens tomorrow at 10AM - <AUTHOR> https://www.thunderclap.it/projects/2931-phonebloks

<comment><USER2> Glad to see Motorola is adopting it, as impractical as it may be.</comment>


My Next Adventure - <AUTHOR> http://textslashplain.com/2015/12/23/my-next-adventure/ <comment><USER2> Kind of wish these sorts of career moves PR releases were announced like transfers/signings for professional athletes.

<comment><USER3> "Google has signed Fiddler engineer Eric Lawrence to a lifetime deal in what one source familiar with the negotiations said is a fairly ordinary hiring.

"We are excited to add Eric to our lineup," Masko Askov said. "He is a talented player who we feel can make significant contributions to our Chrome team."

A company spokesperson would not say how much Google paid."

(in all seriousness, congrats to Mr. Lawrence).

</comment></comment><comment><USER4> Sounds like a blast, good luck. I concur with the "dumbest person in the room" advice.

<comment><USER5> * I prefer second dumbest in case we need a fall guy

</comment></comment><comment><USER6> Interesting that Eric Lawrence didn't choose to go back to Microsoft. Though given how much vitriol he directs on Twitter at MSFT and the IE/Edge group he was part of, I imagine neither he nor they wanted him back...

<comment><USER7> I'm not sure going back ever seems like the right move. You aren't necessarily opening yourself up to more opportunity in most cases, returning to a former employer, and as your comment indicates, you may find things have changed in ways you don't like while you were gone.

<comment><USER8> I've not seen too many cases where people going back has succeeded. It is certainly a different sort of relationship post partum.

</comment></comment></comment><comment><USER9> Philip Su mentioned in the article runs the London Facebook office. I am just glad Eric is not joining that one :)</comment>