Hacker News Reader

Comment by aaronmu | Hacker News Reader

I'm amazed at how many people use a client side framework, am I the only one who prefers good old server side rendered static html with maybe a little bit of javascript on top?

When I need a more dynamic page, I create a react app specifically for this one page.

Whenever I need to write JS these days, I go for either TypeScript or F# using Fable (an F# to javascript compiler).

View on HN

For a long time I was in the server-side html + js for ajax/validation/effects camp, but I'm starting to gravitate to the SPA side of the fence.

Why? While server-side based web sites can load quickly, there's something dissatisfying (to me) about clicking around a site, waiting for server responses, when nothing has changed.

Sure, js, css, img, etc. assets are likely cached in the browser, and you're just downloading a blob of gzip'd html, but wouldn't it be better to flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?

A SPA combined with websocket connections allows you to implement the, "don't call us, we'll call you pattern". Granted, for mostly static sites this isn't particularly useful, but still, in principle, only consuming server-side resources when state has changed is a "natural" goal I'd argue.

There are tradeoffs with both approaches, but I'm leaning toward SPAs more and more.

I urgently encourage you and anyone else reading this to check out Turbolinks 5, ideally in tandem with Stimulus.

https://www.youtube.com/watch?v=SWEts0rlezA&t=3m22s

https://github.com/turbolinks/turbolinks

https://stimulusjs.org/

You can get all of the benefits of server-generated pages with the speed of an SPA. 90%+ of the sites built using SPAs would be better served by Turbolinks and Stimulus.

Just looked at stimulus. Really cool framework. circa 2008 or so there was this concept of non-intrusive javascript where you bind js to elements. So you could wysiwyg html and then inject js where you need it. Thought that was a neat idea and like what stimulus does it. Any real life experience from anyone ?

Yes, I'm using it in the budgeting webapp that I develop and here's one little component that I shared, a calculator for input boxes https://tomk32.de/2018/08/04/stimulus-component-calculator.h...

Really should add a gif or something.

pretty cool.. thanks for sharing... I could not work on the app itself, but that is ok.

Just for context, Stimulus is written by the same people who make Rails, Turbolinks etc - Basecamp. In fact, primary author Sam Stephenson was the author of Prototype, which was the library that inspired the creation of jQuery.

Stimulus and Turbolinks 5 don't have to be used together, but when they are it's a beautiful thing. That's because Stimulus uses the MutationObserver API to observe for DOM changes (eg. loading a new view in response to a click). It is the nicest event handling concept I've ever worked with.

I’ve never used Stimulus, but I can concur that Turbolinks is magic, at least for the simpler Rails app I made. It took load times from over one second to feeling like a native app, didn’t require any changes on the backend (it’s enabled by default in Rails), and the site works just fine without it, for those of us who like blocking third-party JavaScript.

I've never heard of either before, and they've really caught my attention. Thanks for bringing this up.

Let me know if you need any help getting up and running. I'm not involved but I'm a big fan.

For what it's worth, if you are impressed by the reasoning and design-thinking that created these libraries, I encourage you to try Rails sometime as well. I still consider it the best way to build a web application for 90% of use cases. I'm happy to answer any questions you might have.

https://www.quora.com/Why-do-so-many-startups-use-Ruby-on-Ra...

This all looks really nice - any idea if there's anything comparable that works with Django?

Turbolinks has out-of-the-box support for Rails, but should theoretically work with any backend without much work. Just install via npm.

Stimulus will work with any (or no) backend.

Turbolinks will work great with Django, but I recommend configuring your stack to automate the inclusion of the Turbolinks-Location header in your responses.

I just did a quick Google and this came up: https://stackoverflow.com/questions/47240766/to-use-turbolin...

Let us know how you make out!

Why not just make the traditional site, and then add what, a dozen or so lines of JavaScript (or some backend frameworks will do it for you) to make form submissions/links into XHR calls dynamically.

Also - using WebSockets for a one-way communication channel is ridiculous. I know it's the cool kid way to do things, but that invariably means it's over hyped and has a more appropriate alternative. In this case, it's EventSource/Server Sent Events.

I have some sympathy for your view here, but there are some other practical concerns as well in this case. For example, EventSource/SSE are not natively supported on IE/Edge but WebSockets are, so how well whatever you need to do works with your chosen polyfill is a factor.

Right, except eventsource is pretty simple to pollyfill because it’s just http.

Websockets requires explicit support on the backend, in every layer of your http stack that it’ll traverse.

If the goal is to simplify your stack, websockets is not the solution.

Oh, I agree, and under normal circumstances EventSource + polyfill is what I'd use too. I'm just pointing out that it's not always as simple as overhyped things being used only because of the hype, because sometimes there are genuine technical differences in areas like compatibility or performance as well.

> clicking around a site, waiting for server responses, when nothing has changed

> flip the script and notify the client, rather than the client clicking around, uselessly consuming resources?

What are they clicking on that is being useless? Are you putting buttons on your page making requests for no reason?

When its server side you send them a mostly-static page with a bunch of links or submits to make more requests with. All those requests are for either sending data back or getting something new off the server. If your use case would involve a lot of user generated input in a streaming fashion then yes, SPA client side programs are th way to go, but if all you are doing is throwing mostly-static CRUD applications you aren't getting an efficiency advantage dumping all the data on the user at first request and then hoping to only get one response of everything they want changed later. You're burning a ton of client memory and CPU cycles to do work you could have done more efficiently with page caching on your end anyway.

You're not alone. Frameworks favour vendor-lockins, better avoid those ones, if they get abandoned or iterate too fast (see React)

In my experience, the problem with a lot of those solutions is that at some point you still need to handle data and some significant dynamic content. Of course, this depends on what you do, but even a simple e-commerce site is fairly dynamic nowadays.

What happens if you go the I'll-do-it-myself is that you still get a significant amount of code, and lots more bugs since you'll have to redevelop significant pieces of what the libraries and frameworks already have done (and tested) - and you'll ever be better than them.

Of course, you don't need to use Javascript to render your whole page. You can still use React or Vue to add these dynamic parts, and render the rest at the backend.

Imo this might be one of the most underrated ways of doing things. I guess human tend to go to the extremes without being rational about it necessarily (or thinking for themselves and just buying into the hype).

I totally agree with you! I've used react and redux in almost every project last year, but that doesn't mean the entire web app was written using react and redux. 50 ~80% was plain old static content rendered on the server.

A dynamic client side UI is more expensive to build compared to static html rendered on the server. Our software usually aims to solve a business problem for as little money as possible so we only build these dynamic ui's when they're absolutely required.

It's funny that some of these client side framework is wrecking the pages as if things are worse than 10 years ago from users' point of view.

I visit a major credit card company's account page and it shows the last time I visited as 'undefined' for a second until it grabs the data to render and it just looks shit.

And I also don't like seeing the page loaded with minimal placeholder, only having have to wait a few seconds for the page to finally render, which is more annoying than even waiting on a blank page because you can't easily tell if things are all loaded or not with placeholders all over.

A pure bad example of over engineering.

You need to make sure things don't look shit using client side framework.

Nope, I would not use SPA unless it's certainly necessary. If client wants the "SPA Effect" you can just slap Turbolinks and be done.

At my work we need APIs for integrations. The easiest path for us is to write the API and write an app to consume it. Although I suppose you could do the extra work to bundle a UI with the API and share the business logic. Also dog fooding helps us get the API right the first time. Im not 100% into the SPA world, in fact one of our clients is an MVC app which uses a mix of HttpClient to call our API and good old fashioned jQuery AJAX calls.

I just wanted to voice this and say if you live in a world where people do not need to integrate with your API then a regular MVC style app and little to no JS is fine. Also, JS helps when you need to do things like CRUD many-to-many relationships on your UI without a bunch of postbacks.

I found the entire premise of the question weird - s/he asks about what people are using, and then states s/he wants to use two specific things.

"Waiter, what can you suggest for me, I want to eat a fillet mignon?".

As for your view - I agree mostly. I'm definitely in favour of making things entirely in the 'classic' web model, adding javascript to enhance things where it makes sense (some of this now is just polyfilling html5 form controls where they're not native).

No. You're not the only one.

Not at all, as I replied on another thread.

Plain old Java and .NET frameworks or CMS, with server side rendering, with dynamic behaviour on as needed basis.

Easy there tiger, React and others are compatible with server side rendering. They’re capable of being the “little bit of JS” on top. Everything will be ok.

I am well aware of server side rendering but you still need to send all that javascript to the client, whether it ran on the server or not. Wouldn't exactly call this a "little bit of js" on top :p

Let's see - one could have both server and client jumping through hoops rendering a client-side framework on the server and then hydrating it again on the client (including having to pull in all the tooling that would require)...or one could just use regular old templates.

There certainly is nothing wrong with going with simplicity over a solution that's overengineered for one's case, tiger.

I was a web dev in a previous lifetime and have gone to the backend for almost a decade now; one of these days I need to climb back up again. Threads like this one are intimidating in a way because there's just been So Much Development and everything I knew was wrong, except... it also still all works just fine! It's just the incorrect way of doing things now.

It's good to hear that maybe when the time comes, I can dip into React by using it as the sprinkle of JS that jQuery / jqxWidgets and such were for me the last time I did any of this.

Reply on news.ycombinator.com