6 ms·

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 fa

• tonyedgecombe 6y ago
  I’m just happy when it works which seems far less common with SPA’s.
• ch4s3 6y ago
  > 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.
  • piazz 6y ago
    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.
    • ksec 6y ago
      Which is also running on Rails if I remember correctly. But Notion seems to be those extremely extremely rare examples.
    • alecbenzer 6y ago
      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.
    • thirdsun 6y ago
      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.
  • paxys 6y ago
    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 6y ago
    Discord and Figma are two standout examples.
    • sitzkrieg 6y ago
      if i maximize discord on a 4k display its unusable, but i guess i should blame something in electron for that
    • alecbenzer 6y ago
      Not measuring but just going off of my memory, hey feels subtly but distinctly snappier than discord.
  • JamesSwift 6y ago
    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.
  • alecbenzer 6y ago
    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).
• rosywoozlechan 6y ago
  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 6y ago
    Poor understanding of DOM updates, requestAnimationFrame, and async programming in single threaded JS GUIs is my guess.
    • coldtea 6y ago
      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 6y ago
    You can still write bad code without React.
  • JamesSwift 6y ago
    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.
• burlesona 6y ago
  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 6y ago
    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 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
      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 6y ago
        It is open to all now.
      • fomine3 6y ago
        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.
• latortuga 6y ago
  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 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.
  • rhizome 6y ago
    The Rails version of that is called ActionCable.
    • latortuga 6y ago
      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 6y ago
        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!
  • omnimus 6y ago
    It is probably like LiveView but i think its over http. Like Laravel Livewire https://laravel-livewire.com/ https://laravel-livewire.com/ I am not sure websockets and ruby are best of friends.
    • latortuga 6y ago
      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.
• rand0mstring 6y ago
  DOWN WITH JAVASCRIPT
• mfer 6y ago
  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.
• mseidl 6y ago
  of course it's DHHHAMP
• whoisjuan 6y ago
  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 6y ago
    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 6y ago
      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 6y ago
        > plain HTML likely gzipped blobs Got ya. This is what I'd expect.
• chapati2301 6y ago
  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.
  • Axsuul 6y ago
    The iOS app is native and not related to the front-end stack
    • tusharsoni 6y ago
      The apps are native but still seem to be using HTML views [1] [1]: https://twitter.com/dhh/status/1275906524569731072?s=20 https://twitter.com/dhh/status/1275906524569731072?s=20
    • nickromano 6y ago
      It is mostly a web view around the front-end stack.
    • wilg 6y ago
      No, it wraps the website.
  • chvid 6y ago
    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.
• ForrestN 6y ago
  Odd, I haven’t experienced any of this. Smooth all around for me so far, no refreshing at all.
• oh_sigh 6y ago
  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.
• yagodragon 6y ago
  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 6y ago
    What over-engineered front-end framework? Stimulus?
• frandroid 6y ago
  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 6y ago
    Facebook has a terrible and slow UI, so IMO not the best counterexample.
  • p_l 6y ago
    A lot of Google stuff, to this day, uses GWT apparently
    • frandroid 6y ago
      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 :)
• maps7 6y ago
  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.
• rsanheim 6y ago
  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.