Hacker News new | ask | show | jobs
by AdrianRossouw 4429 days ago
> 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.

1 comments

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