Pure UI | Hacker News Reader

Pure UI

rauchg.com

138 pointsdismal221 comments

I'm still waiting for a component economy that could keep up with e.g. Delphi's VCL. Right now, it's either big UI frameworks or stuff you've got a hard time integrating (e.g. they download half the internet, require 28 properties to connect/style). Pure rendering model (i.e. independence from data) alone doesn't cut it.

From what I can tell VCL was simply the "pioneer" of what afterwards became "the bog standard approach" from VB to WinForms, Qt, Gtk etcpp. Essentially an OOP class hierarchy with everything inheriting a root "Component" class, most of them wrapping win32 / OS "prim components" C API, coupled with a visual editor with a layouter / component placement / Properties pane.

Now, stuff like this abounds in the Web space but will never feel as "lean" because there's no comparable "underlying-OS-provided-component-primitives". If you insist on such a route without "downloading half the internet", you're stuck with HTML's Form primitives --- not rich enough. If you avoid "28 properties to connect/style", 90+% of web-savvy adopters are gonna balk and bark "where's all the well-known CSS props I should be free to apply?". If you ditch shared stylesheets and expose CSS through a per-component Properties Pane --- in a naive tool, consider the generated HTML, not a sane idea.

Look, these "big UI frameworks" for the most part strip down during builds (with modern web-dev tooling) to the only-what's-used essentials --- certainly for the JS parts, hopefully for the CSS parts too (though not sure this has ever been a real problem to begin with tbqh)

Its never going to work like that for the web, because web browser/client producers aren't interested in parcelling out pieces of the pie - its an all-or-nothing approach in the client wars, and we, 2nd-tier programmers hoping to profit on top of the platform, simply have no control.

So, its kind of cannibalistic in my opinion - as soon as an approach rises to the level of adoption, it becomes cannibalised by the very providers of the resources required to sustain itself - the web client vendors.

I, also, look for the same things you do. I don't think its going to happen with the web - we're lock-stepped into fooling ourselves that 'one standard will fit all' when really its 'one standard will deplete your budget, and then you will be left to fund the other standards if you want to ship - otherwise, gtfo and die'...

The only hope is that a model of software development emerges that is not dependent on the client software wars producing a clear winner. Perhaps the more people build their own custom clients, the more we're likely to gain the "component-izable ideal" you postulate. One can hope ..

Timestamp: July 13, 2015

This should be noted in the title.

Other than framing it in the language of React/FRP, is this substantially different from template engines? Templates are functions from parameters to markup/UI; they're just written in (usually custom) markup languages instead of Javascript. If a template isn't a pure function of its parameters, then surely you're doing it wrong?

PS: I've used several template engines which have an "inheritance" feature, which might refute my point. I never used such features, as they seemed to be shoehorning cargo cult OOP into situations where it's not appropriate. On the other hand, having one template include another for some sub-component acts exactly like one function calling another.

How was the view counter made? It's cool to see it increase in realtime.

It uses Firebase i think

Yes there's an open firebase websocket connection that emits the count.

example payload:

{"t":"d","d":{"b":{"p":"views/2015-pure-ui","d":514866},"a":"d"}}

If you are interested here is source code for the blog views. https://github.com/rauchg/blog-views

Thanks! I have actually been looking for some simple examples of ZEIT microservices and this happens to be a very nice one.

I came here just to compliment the counter. Very cool.

Just a heads up, the http://primercss.io/buttons/ link is broken for me.

I'm not sure but this sounds like the writer has unknowingly stumbled upon react.

Unknowingly? He mentions React by name.

This was written in 2015, when React was far less popular. Guillermo clearly decided to bet big on React after this- his company Zeit produces next.js, one of the nicer React frameworks out there.

(Can somebody add [2015] to the title?)

Also, the author is advocating a UI model that has pre-existed React, it was just popularised by React.

You could argue that Elm is actually closer to what the author is advocating.

Totally. I would argue that React was successful not because of the declarative programming style that it enables, but because it integrates so easily into the imperative JS ecosystem.

I would argue 'integrates so easily into the imperative JS ecosystem' is not a differentiating factor over all the other JS frameworks, so its declarative programming style is far more likely to be the reason it is popular (and in my experience/opinion, this is absolutely the case).

If you just meant popularity vs Elm however, then sure.

Because others "did not"? Other framework didn't need a new language to be usable.

Immediate mode UIs have been around forever, actually. They just need a bit of finesse to be made efficient.

Too much focus is on the tech in this thread, I personally read it as outlining an approach similar to Bret Victor's[0]. React or whatever is a mere implementation detail.

[0]: http://worrydream.com/#!/LearnableProgramming

yikes, my bad!

Reply on news.ycombinator.com