[malandrew]

We haven't yet decided how to handle the problem for which progressive enhancement is but one solution.

IMHO progressive enhancement is an anchor and those who have pushed for it for years are false prophets.

Instead I think we should focus on mapping routes to state (documents) so that an entirely different site (one resembling the original web) is shown instead.

I'm the first employee at the company and AFAIK also the only person at the company that browses with javascript disabled by default (ironic, isn't it?), and one of the things that most excites me about the API-ification of the web with thick web clients, is the possibility to create server side frameworks that a static representation (basically pure HTML and minimal CSS) with javascript for famous apps. If the user has javascript enabled, it would completely replace the content in body with a rich app. If not, they have the glory of a motherfucking website [0]. IMHO, progressive enhancement was a huge mistake and we instead should have been make two sites all along: (1) super duper interactive apps/sites for the newest and best browsers, and (2) stupidly simple sites/documents that would be browseable by old browsers, screen readers and hopefully even lynx[1].

Making a site serve two masters is more work and results in a poorer compromised experience for all. Apps and documents are built on fundamentally different abstractions and trying to find an abstraction that can accomplish both is a pipe-dream.

If you've never tried lynx, you should. It's a shame something like that is still not possible. Do a `brew install lynx` if on OS X, and when it's finished installing, type `lynx` at the prompt. Once there, type `g` to go to a specific URL and then type www.google.com and see what it's like to browse use google with lynx.

Developers should support disabled and disadvantaged users because it's a noble goal, but even if they don't do it for that reason, they should remember that Google, Bing and DuckDuckGo are some of the most active blind users on the web. Making a site work in lynx makes it work with screen readers and google.

For now, we don't have a good solution for this, but we're noodling on the problem and aware that it does matter.

[0] http://www.motherfuckingwebsite.com/

[1] http://lynx.browser.org/

[2] http://dashes.com/anil/2012/12/the-web-we-lost.html

[AdrianRossouw]

> I'm the first employee at the company and AFAIK also the only person at the company that browses with javascript disabled by default (ironic, isn't it?), and one of the things that most excites me about the API-ification of the web with thick web clients, is the possibility to create server side frameworks that a static representation (basically pure HTML and minimal CSS) with javascript for famous apps.

This is absolutely exactly what I am talking about, and what I am dying to get back to. I find the idea of the content actually being the content, in a straight one paragraph/aside/article after another... with no floats or what not.... I find it completely fucking liberating.

I was absolutely blown away when i discovered that this is how you do responsive layouts in famo.us :

    if (contextSize[0] < 480 || contextSize[1] < 480) {
        dimensions = [2,8];
    } else {
        dimensions = [8,2];
    };

How much time and energy was spent to build non-turing complete declarative DSL's that are all just there to try and avoid writing that single if statement?

I'm authoring lots and lots of content these days, and I just want to get on with writing the content, and then be able to add stuff like interactive figures, that only kick in when needed.

I also prefer links to lynx. I use it on my open pandora now and then, and whenever I am on a remote server.

[malandrew]

I'm one of the two tools engineers at the company and what we're building is a few months from being released. Since I'm on tools, I didn't actually work on the responsive layout stuff, so I won't really be able to your questions about how we did that in detail.

What I can say is that what you're seeing are basically constraints and if you define lots of constraints, you can then use a constraints solver to help you automatically lay out your app on different devices based on rules you've defined. We're only beginning to explore these ideas at the moment, but we're definitely open to suggestions in the meantime.

If you're curious to know more about constraints and layout, check out the links below.

Regarding the notion of authoring content and then adding the whizz bang later, we're definitely interested in solving those problems, but it's going to take a while to get there. Ultimately, I think it's going to take an approach similar to what ember did, where you take a routes first approach. Once you have your routes, you then create the parts that determine what content/data needs to be show based on those routes. Once you're that far you, can then work on two layout strategies: one rendered by the server as static HTML and one that is rendered on the fly in clients with javascript enabled. My hope is that people are super lazy about the static HTML site, basically doing as little design as possible, leaving the final design looking more like the web before frames even existed; i.e. one long scrolling document with anchors jumping to the content you want, and reverse anchors taking you back to where you just were. I'm even curious if we could get back entirely to document oriented design as a fallback instead of some weird unusable frankenstein we get today when designers eager to make things rich and interactive also attempt make the same design support legacy browsers and the visually impaired.

[0] http://gridstylesheets.org/

[1] https://news.ycombinator.com/item?id=7353944

[2] https://developer.apple.com/library/ios/documentation/userex...

[3] https://harlanhaskins.com/2014/03/02/laying-out-ios-uis-in-c...

[4] https://news.ycombinator.com/item?id=7330683