
Pure UI - dismal2
https://rauchg.com/2015/pure-ui
======
mhd
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.

~~~
dualogy
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)

~~~
mmjaa
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 ..

------
thephyber
Timestamp: July 13, 2015

This should be noted in the title.

------
chriswarbo
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.

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

~~~
dkris
If you are interested here is source code for the blog views.
[https://github.com/rauchg/blog-views](https://github.com/rauchg/blog-views)

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

------
slimpdx
Just a heads up, the
[http://primercss.io/buttons/](http://primercss.io/buttons/) link is broken
for me.

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

~~~
evv
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?)

~~~
beefsack
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.

~~~
evv
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.

~~~
allover
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.

