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).<p>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!<p>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.<p>There are of course many advantages to using SPA, but for me I don't think it will ever give me the same <i>calmness</i> as with server-side rendering where I can see all requests in the last 24 hour being successfully responded in <X ms.
This likely doesn't mean what you think.<p>His full thread contradicts the headline[1]. They heavily use several JS libraries, including Turbolinks.<p>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).<p>1. <a href="https://mobile.twitter.com/sstephenson/status/1272608117604397063" rel="nofollow">https://mobile.twitter.com/sstephenson/status/12726081176043...</a>
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.
Since I've never heard of HEY, here's the site: <a href="https://hey.com/" rel="nofollow">https://hey.com/</a><p>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...
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.<p>I saw a cookie-wall built with React recently. That's just wrong in my opinion.
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.<p>Is it feasible to work as - let's say - solo developer in the startup?
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").<p>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.<p><a href="https://roca-style.org/" rel="nofollow">https://roca-style.org/</a>
I'm looking for a <i>easy</i> 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.<p>Nowadays??<p>- Java swing: Java is pretty straightforward but I could never get the layouting engine to do what I wanted.<p>- .NET windows forms. Same as above except using c/c++/c#<p>- 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.<p>- 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.