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).
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.
JS and CSS don't have to be re-parsed and computed, and images don't have to be reloaded into memory.
You also get more control over what the browser looks like while the next page is loading (e.g. loading animation instead of blank white interstitial screen).
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?
I don't think you would need to know ins and outs of Turbolinks to leverage it in your app. It's a simple drop-in library which replaces `body` inner HTML instead of a full refresh in case of page navigation.
Its actual aim is to provide SPA like experience without modern JS complexity which is ideal for solo devs/small teams.
Also, it is worth noting that they are using Stimulusjs framework with Turbolinks.
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.
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.
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.
Is there really an issue about refreshing pages ? If the issue is the time between loading page, well just optimize your base HTML page loading time ¯\_(ツ)_/¯
Without JS forms submission is the maximum you could do. If you want to do something even slightly dynamic, JS is a must. Personally I use JS for apps, but I don't have any intention to use it for documents. But there are many parties that would like the distinction bethese the two obsured.
Given how much HNers circlejerk over it, it would be negligent to not add it to your marketing message if HNers are part of your audience. It also disarms the whole "ugh, a SPA? The internet is supposed to be documents over http >:("
Since I've never heard of HEY, here's the site: 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...
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.
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.
I'm struggling a little to understand what HEY does. They're suggesting that they have "reinvented Email" but is it just client side management that they've changed? It sounds like they've brought spam management to the user, "reply later" which I'm not sure what the difference is between that and moving the email to a folder called "Reply Later". Maybe it's just that most users don't customise a personal workflow and this has interesting/sane ideas as defaults.
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.
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.
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.
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.
40 comments
[ 2.3 ms ] story [ 101 ms ] threadHis 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...
"HEY’s UI is 100% HTML over the wire"
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.
My assumption is that Hey can support offline mode using some clever pre-fetching, but it may not yet in v1.
You also get more control over what the browser looks like while the next page is loading (e.g. loading animation instead of blank white interstitial screen).
Is it feasible to work as - let's say - solo developer in the startup?
I would love for someone with more experience to to answer your question.
Its actual aim is to provide SPA like experience without modern JS complexity which is ideal for solo devs/small teams.
Also, it is worth noting that they are using Stimulusjs framework with Turbolinks.
Every time, I want it to work but you as you mentioned there's a few gotchas here and there that catch me unaware that cause me to shy away.
In the rails JS camp though is StimulusJS. I swear by this for developers that want a bit of JS sugar but don't need the full suite of Vue or React.
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.
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.
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...
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.
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.
I saw a cookie-wall built with React recently. That's just wrong in my opinion.
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.
If you don't need extremely complex UIs everything can be Elixir, HTML, and CSS.
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.
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/