[piazz]

Noteworthy how they tout the success of their "magic" frontend stack made with vanilla JS, lack of a trendy framework, etc. But if you use the app, the UX is fairly laggy, requires frequent refreshes, all the animations and interactions are off - the list goes on and on. It's noticeably subpar (and I like Hey).

Seems to me that the proof is in the pudding wrt their stack, but it's probably not what they wanted to prove. I would take a well tuned React SPA over this any day of the week.

[chapati2301]

Unfortunately have to agree. I really wanted to love HEY, and while it’s certainly not super laggy or anything, I’m not overwhelmed with the “magic”.

Ran into a host of inconsistencies already, changing between imbox/feed/papertrail on iOS also feels very “unnative” in the sense of not fluid.

The Basecamp folks have always been JavaScript skeptics (my perception at least) so I’m not totally surprised. And while the “magic” may apply to the simplicity of their front end implementation, that’s unfortunately not the same as a magical user experience where in 2020 I do expect a more fluid feel.

It’s quite apparent that often it’s just replacing one HTML block with another without too much thought about transitions.

[chvid]

From the twitter feed: "React is so 2019. HTML + minimum JS is 2020"

Ok. Just as long as you don't get stuck in 2010 :-P

Something like a web email-client really lends itself perfectly to a pure client side JavaScript application. Use the browser's cache facilities to cache the client side javascript and save server resources by avoiding server side rendering. You don't care that much about initial load time. Or search engine visibility.

[Axsuul]

The iOS app is native and not related to the front-end stack

[nickromano]

It is mostly a web view around the front-end stack.

[wilg]

No, it wraps the website.

[tusharsoni]

The apps are native but still seem to be using HTML views [1]

[1]: https://twitter.com/dhh/status/1275906524569731072?s=20

[ch4s3]

> the UX is fairly laggy

I don't really find that to be the case. All of the actions seem to be done for me in under 400ms which is to say under the Doherty Threshold. That mean's that they are largely imperceptible. Sure it doesn't have fancy animations, but there isn't really any time for them.

Can you cite an example of a popular React SPA that is less "laggy" in your opinion? I'm curious to compare the UX.

[JamesSwift]

Ive never heard of the Doherty Threshold, but looking it up, it seems that its actually saying > 400 ms "is painful", not that its "imperceptible". And that aligns with previous rules of thumb I've used for mobile UX -- you generally want things to be < 100ms, and ideally < 50ms. If something results from user interaction the bar is much closer to the 50ms side of the range.

[piazz]

Sure, a fairly best in class example would probably be Notion. Switch between pages, move some elements around, etc. There's a level of interactivity and responsiveness that I just don't see with Hey.

[thirdsun]

While I haven't used Hey yet, I find Notion on iOS to feel very sluggish and out of place compared to native apps. That's not a benchmark at all in my opinion.

[alecbenzer]

Switching between pages is pretty hit or miss for me in Notion. If it's a page I've been to recently it's very fast, but it's noticeably slow on some page loads. hey seems consistently pretty-fast.

Moving around elements doesn't seem like a fair thing to compare to navigating around the app... that's more like looking at how smooth text editing feels in Hey.

[ksec]

Which is also running on Rails if I remember correctly.

But Notion seems to be those extremely extremely rare examples.

[alecbenzer]

Yeah, maybe it's different the further you are from the US or something, but from my use of hey, I have no idea what these people are talking about. It feels about as snappy as most other apps I use. If anything it feels snappier than my average app (though I think that has more to do with backend/network than the UI).

[paxys]

More server side rendering means that a lot of the experience depends on the internet connection. Even minor lag or jitter can drastically affect responsiveness.

[jakelazaroff]

Discord and Figma are two standout examples.

[sitzkrieg]

if i maximize discord on a 4k display its unusable, but i guess i should blame something in electron for that

[alecbenzer]

Not measuring but just going off of my memory, hey feels subtly but distinctly snappier than discord.

[whoisjuan]

They are using Turbolinks. They generate everything server-side and then Turbolinks calculates the delta between the existing loaded template in the client and the incoming template generated in the server and injects only the changes.

This has a lot of advantages, mainly that you don't need to care about state on the client side and you're always synced with the real estate on the backend. It has one major drawback though. If you want to create snappy interfaces, you still have to create some client visual state and modify the visual state before you receive the response from the server. Otherwise it becomes laggy because it's waiting for the response to re-render. If you don't do it this way it's going to feel slow for sure.

But again, the main advantage of this is that there's no complex state logic in the client. The server-rendering is the source of truth for your state.

It's definitely a different mindset because now you have to write JS to create UI states as they are expected to come fro the server (if you're looking for that quick SPA snappiness).

I think it's an interesting approach, but I'm not sure if I like it, though. I have build apps this way and always get the sense that I'm not creating something that feels fast.

[karmakaze]

Where is the "existing loaded template" kept server-side, sticky session cache? Seems maybe better for scale to send the whole small html and let client diff-apply.

[whoisjuan]

In theory the server doesn’t care about this because the idea is that you’re requesting something that is generating a complete new template. What turbolinks does is looking at the difference between whatever you have loaded in the browser and whatever was sent by the server.

So if you have 10 images loaded and one changed, turbolinks it’s only going to swap the one that changed.

Have in mind that we are talking about plain HTML likely gzipped blobs. So although this is not efficient it’s still fast enough for simple app layouts.

[karmakaze]

> plain HTML likely gzipped blobs

Got ya. This is what I'd expect.

[hfourm]

Also even modern turbolinks suffers from a lot of headaches interacting with third party libraries. It isn't as bad as it was but it isn't great.

[burlesona]

Uh... did we use the same app? I signed up this week and found the whole thing very clean and zippy. Nothing in the animations / interactions felt off to me.

[mpartel]

The experience might vary a lot depending on ping times to their servers, if most interactions require a server round-trip (and if they don't have nice animations to hide the lag).

[deltron3030]

But the reception of Hey also proofs that most people don't care about flawless animations and visual design with webapps. I don't like their visual brand either, but I still might get the app when I have to deal with more email stuff.

[mdoms]

I wouldn't read too much into the reception of Hey at this stage. It has only been opened up to people who pre registered, which is to say followers of dhh/Basecamp, who are predisposed to like it.

[deltron3030]

There are tech sites and productivity channels who got their hands on it, so far I didn't notice any complaints about Heys UI. I think the bar is quite low because many other apps people use perform much worse.

Btw, I'm a follower of Basecamp and their designers, and I don't like their visual design choices :p

[bdcravens]

I'm sure they've allowed in all pre-registrants at this point. I registered sometime in the last week and was allowed in yesterday. I'm pretty sure DHH said the other day they'd open it up to the public this week sometime.

[ksec]

It is open to all now.

[fomine3]

Even though allowed in all pre-registrants, I suspect that people who registering email service that costs $90/m(even trial exists) are tend to DHH follower or similar people.

[frandroid]

What I find amusing is that all of today's SPA frameworks/views are kind of descended from Angular, which Google built internally after learning the lessons of how to build such a thing while putting the Gmail front-end together. We 15 years of SPA usage in email applications demonstrating their superiority. We have things like Facebook, the one true SPA which rules them all. And yet. Turbolinks.

(And I say that as a big RoR fan!)

[elsurudo]

Facebook has a terrible and slow UI, so IMO not the best counterexample.

[p_l]

A lot of Google stuff, to this day, uses GWT apparently

[frandroid]

Internal tools are always what takes the longest to get the greenlight to rewrite... Don't take shortcuts you don't want to live with forever :)

[mfer]

So, I'm not having issues with lag. It seems to work as I expect. I wonder what situations would cause people to have lag.

[rsanheim]

The UI performance feels snappy to me, and opening up threads or going to commonly used pages feels about as fast as Gmail. From watching the performance w/ network tab open things happen in around 300 - 500 ms, which is inline w/ Gmail as well.

_Opening_ app.hey.com is a different story, and is far faster than opening a tab to gmail. I often wait for Gmail while staring at a blank tab as it loads, even one a fast broadband connection. Using Gmail over spotty broadbad, say while traveling, often leads to dropping down into "simple HTML mode".

Hey loads up very, very quickly, which isn't surprising given how small the bundle of html/js/css you are pulling down is.

[latortuga]

Interesting note, on Twitter DHH mentioned that they have some additional "magic" that they're using to do frontend work. It sounds like HTML over websockets, not unlike Phoenix LiveView or (tooting my own horn here) our recently released Motion library (https://github.com/unabridged/motion) which both allow you to use the server as your single source of truth while providing reactive UI components on the frontend. He indicated they'll be releasing more later this year.

[ksec]

>Motion library

Nice, this is much closer to LiveView than Stimulus Reflex. Will check it out when I have time.

Slightly off topic:

>Github's ViewComponent is currently the de-facto standard for component/presenter-style libraries for use with Rails and likely will make it into Rails eventually.

I thought DHH rejected the idea?

https://github.com/rails/rails/pull/36388

[alecdotninja]

> I thought DHH rejected the idea?

I can't speak for DHH, and I don't see anywhere that he commented in the PR. My read of the thread is that there are open questions about the best way to structure this abstraction, so the minimal interface to allow for clean community experimentation has been stabilized in the meantime.

[omnimus]

It is probably like LiveView but i think its over http. Like Laravel Livewire https://laravel-livewire.com/ I am not sure websockets and ruby are best of friends.

[latortuga]

ActionCable doesn't really scale that well, but can work for small loads. In addition, there's AnyCable to bring high scalability using the ActionCable protocol for easy Rails interop. With Motion, we are planning support for AnyCable.

[rhizome]

The Rails version of that is called ActionCable.

[latortuga]

Kind of, yeah. ActionCable is just the plumbing though. The functionality of Motion, this forthcoming magic, LiveView, etc is all a step higher up. Motion uses ActionCable as the implementation mechanism, the "pipe" that data transfers over. But ActionCable itself is basically just "you can use websockets with Rails!" and not much else.

[rhizome]

Well sure, and inevitably there are going to be gem(s) or framework additions that make it easier to send HTML down the pipe, which is how I read your comment. We don't disagree!

[tonyedgecombe]

I’m just happy when it works which seems far less common with SPA’s.

[ForrestN]

Odd, I haven’t experienced any of this. Smooth all around for me so far, no refreshing at all.

[rosywoozlechan]

I believe they don't have much of a frontend stack at all, it's just a little bit of JavaScript, so I don't understand how the UX would be laggy if it doesn't actually do much.

[akiselev]

Poor understanding of DOM updates, requestAnimationFrame, and async programming in single threaded JS GUIs is my guess.

[coldtea]

We have been understanding all these for 20 years at the level Hey uses them, so if there's indeed a problem, it can hardly be that...

[madeofpalk]

You can still write bad code without React.

[JamesSwift]

Because its hard to have seamless / performant UX when requests necessarily dont share DOM state. You run into the same issues on native mobile applications.

[maps7]

I've been using it for the last few days and I don't have this experience. It's better than Outlook (web or desktop), hotmail, yahoo, gmail and other email services I have tried.

[oh_sigh]

On signup, it also tries to autofill my credit card number when asking me what my full name is. Maybe it is just a chrome UI issue and it will only give the form my full name and not my CC#, but it is a little bit concerning.

[mseidl]

of course it's DHHHAMP

[yagodragon]

If they spent all this time and energy into building a high performant and minimal react/vue app instead of using their over-engineered in-house front end frameworks the result would be even better. Maybe they should just embrace Vue.js which, like rails, is also an indie open source project ,not backed by big co. Vue 3.0, while still in beta, brings lots of improvements on the table and the new custom renderer api would make it easier for their team to also target native mobile apps.

[stepbeek]

What over-engineered front-end framework? Stimulus?