
HEY’s UI is 100% HTML - polyrand
https://twitter.com/sstephenson/status/1272608117604397063
======
judofyr
I think one understated advantage of serving plain HTML is the reduced surface
of things that can go wrong. Once you see that the server has sent a "200 OK"
response you know that everything is good and the user will see the content
(okay, you still need to worry about the CSS and images loading).

In contrast, with a single-page application everything is asynchronous. Have
you handled all possible error cases and race conditions? Have you thought
about all of the possible immediate states (e.g. one remote call being super
slow might cause the UI to be inconsistent/confusing)? And all of this logic
is running on the client. And that client might also be out-of-date (if they
left the tab open). So much complexity!

Another side-effect of server-side rendering is that it forces you to make it
performant. I've seen so many SPA with a mind set of "oh, this data isn't
critical so it doesn't matter that it takes 2 seconds to load; we'll just put
it behind a spinner". Over time this has a tendency to cause applications
which does massive amount of slow remote calls to different servers/services
and multiple spinners in all components. Good luck trying to use these on a
mobile phone in transit… Once you put all of the content inside a single call
to the server you can't get away with this and you preemptively need to care
and focus about performance.

There are of course many advantages to using SPA, but for me I don't think it
will ever give me the same _calmness_ as with server-side rendering where I
can see all requests in the last 24 hour being successfully responded in <X
ms.

------
smt88
This likely doesn't mean what you think.

His full thread contradicts the headline[1]. They heavily use several JS
libraries, including Turbolinks.

As far as I can tell, they actually mean that pages are fully server-rendered,
rather than having presentation and data served separately and assembled in
the browser (i.e. what people now call Jamstack).

1\.
[https://mobile.twitter.com/sstephenson/status/12726081176043...](https://mobile.twitter.com/sstephenson/status/1272608117604397063)

~~~
MrGilbert
Yes - the headline here is missing the important part:

"HEY’s UI is 100% HTML _over the wire_ "

~~~
antris
If there's Javascript on the site, then surely the JS code goes over the wire
too?

~~~
smt88
I don't have an invite and can't check, but whenever the UI changes, it looks
like the _only possible effect_ is swapping the <body> tag out for a new one.

Obviously if JS is disabled, this will just navigate to a new URL and load an
entirely new page.

But if JS is enabled and the new <body> tag does not contain any <script>
tags, then the only thing going over the wire is HTML after the page loads the
first time.

~~~
toddh
How can you replace just the body tag without some javascript to set the html
and ajax to get the html?

------
systemvoltage
People say they don’t like the idea of a page refreshing. But, I like it. I
like using old school forms without JavaScript. I think we should build apps
without JS, just forms and pure HTML.

~~~
thdrdt
Well I mostly agree this should be the first steps in building an app.

But there are a lot of areas where interaction with JS shines over form posts.

For example a form where a choice determines the next steps in the form.

This could be done with simple form posts but then you loose your scroll
position or at least it will jump because anchors are not at the same position
as your scroll position.

I believe JS is overused and most of the time Single Page applications could
be Multiple Page applications with JS where it is needed.

~~~
systemvoltage
I agree with you. Perhaps plain JS to do basic things.

------
eXpl0it3r
Since I've never heard of HEY, here's the site:
[https://hey.com/](https://hey.com/)

It's basically an email provider, but with different features and interesting
ideas on how to manage emails. Don't understand why they can't provide an
actual elevator pitch on the landing page, but have you read their long-winded
message and then you still have to click on "How it works", scroll some more
and read some paragraphs just to get an understanding of what it's all
about...

~~~
AnonC
I had an eye on this service once in a while from the time it was announced.
Now I see that it’s still not open to the public (without an invitation), but
I found the pricing information. _It’s $99 a year!_ That’s huge for me for
email (I consider Fastmail to be very expensive with its standard plan at $50
a year). There’s no information on if/when custom domain support will come to
Hey. I don’t know if it supports aliases and how many are given at what price.
I don’t know if it supports standard IMAP. The advertised features look nice,
but all those are (obviously) dependent on a web browser or their upcoming
apps.

So it’s some stuff that I didn’t know I wanted in email (I do appreciate some
of the features), with no information on what I’ve always wanted from email.

~~~
juststeve
I’m pretty so IMAP is a confirmed “no” from DHH. I kind of understand that the
IMAP protocol may hold back the design of Hey, but This is likely a non
starter for me.

------
stunt
Modern browsers got insanely faster to render "plain HTML". I think you should
have a strong reason to manage DOM on client side with JS frameworks.

I saw a cookie-wall built with React recently. That's just wrong in my
opinion.

------
xlii
I never personally used Turbolinks but I heard rather unflattering opinions
about it. Basecamp/37signals has a long history with Rails so probably they
know its ins and outs.

Is it feasible to work as - let's say - solo developer in the startup?

~~~
welearnednothng
It absolutely is. Turbolinks’ bad rap is from earlier days and was partially
due to just a different JS landscape where certain patterns relied on a hard
refresh to not have memory leaks as you change page, or other odd behaviors.

I was one of many devs that would always setup new Rails projects without
Turbolinks. Last year, I started a new product at work with a slim team and an
eye on simplifying our tech and processes. This included giving Turbolinks and
Stimulus a try.

Long story short, it was simple and straightforward and has a notable impact
on perceived performance after the initial page load. We had a great
experience with it.

These days with Turbolinks 5 it’s quite straightforward. There are some
gotchas, but the readme covers various edge cases pretty thoroughly.

Since that project, I’ve gone solo and am working on my own commercial
endeavor - and while I’ve been building large scale SPAs since before they
were called RIAs, my new product is sure enough using Turbolinks (+ Stimulus).

My understanding is that Turbolinks 6 is coming soon that should be better,
still.

------
cryptos
Probably interesting in this context is ROCA, Resource-oriented Client
Architecture. The basic idea is to deliver HTML and beeing RESTful, while
using JavaScript only to enhance user experience ("Progressive Enhancement").

However, one practical problem with this approach is that HTML forms currently
only support POST and GET, although PUT and DELETE were needed in many
scenarios. Without JavaScript the only solutions are using POST for everything
or using POST + hidden form field with the desired HTTP method and rewriting
the request on the server side.

[https://roca-style.org/](https://roca-style.org/)

------
paulus_magnus2
I'm looking for a _easy_ way to introduce programming to my kids. In my time
Pascal was the way to do it. There was an integrated IDE, one click build,
simple syntax, ways to output text and graphics. User interface / forms had to
be built from scratch though. Interfacing with mouse meant using interrupts.

Nowadays??

\- Java swing: Java is pretty straightforward but I could never get the
layouting engine to do what I wanted.

\- .NET windows forms. Same as above except using c/c++/c#

\- web development. The modern build pipeline with transpilation, gulp, nodeJS
etc is way too complex. Perhaps plain HTML + plain CSS + plain JS would be
possible to grasp by a kid.

\- Android?? In theory we get an integrated entry into developing full stack
applications in pretty much one language (Java / Kotlin) + some XML. The
layouting is problematic again. Easy tings that can be done with visual editor
+ mouse are achievable. More custom layouts quickly enter into the same
layouting engine magic we had in Swing, CSS.

~~~
lxdesk
I say, go back to basics - literally. There are still many "games BASIC"
languages around. Some are attached to or reproduce retrocomputing
environments like QB64, FreeBASIC and BASIC8(plus a plethora of modern BASICs
that target old platforms, like Altirra BASIC, BasiEgaXorz, batari Basic),
some are pretty modernized like Cerberus X and AOZ Studio. The thing they all
have in common is that they get the tooling and deployment challenges out of
the way pretty quickly, and they abstract out enough functionality into APIs
that you can start doing flashy things quickly.

For writing a GUI app, look to Python and TK or wx. Those are not too awful to
get started with(well, TK particularly, wx is cluttered with boilerplate). Or
for a form-editor approach, Lazarus - the current open-source successor to the
Pascal lineage.

------
milansuk
Just to be clear. If I turn off JavaScript, will the site work?

~~~
fnordsensei
Yes, it sounds like the JS used is for progressive enhancement, not for
critical functionality.

------
pictur
why do people praise this site so much?

~~~
jlelse
There's a lot of hype and I don't understand why too. They don't even offer
custom domains yet.

~~~
hejja
because basecamp has a cult following

------
antris
How do you know a website is pure HTML? The developers will tell you about it.

