Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A JavaScript-Free Front End

dev.to

Post reply on HN
Print view View original

181–190 of 215 posts

Re: A JavaScript-Free Front End

#181

Post by cfv »

duchenne wrote: post #179

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my…

Just a stupid question. Why would you need a bundler for plain HTML?

I agree on everything else, but I kinda tripped on that and I'm not sure what you're actually looking for.

Re: A JavaScript-Free Front End

#182

Post by wwweston »

onion2k wrote: post #14

Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd wri…

> If only you'd written an offline-first PWA and used background-loading and prefetching with some intelligence to retry failed requests in order to deliver content before I actually need it this would have worked so much better.

This is a unicorn. If it's the real world we're talking about, as far as I can tell client-heavy webapps that are actually engineered this well -- and don't frequently end up in a more inscrutable state than a pageload failure when network issues rear up -- are rare enough in practice that it feels weird to hold that up as the yardstick for criticism.

And if the point is that more applications should get there, well, that's more or less orthogonal to the point of the article, which (in spite of the headline) isn't so much that no one should use JS for anything ever (since the author details the JS he made a thoughtful choice to include), but that a notable range of UI behaviors that are frequently implemented using JS without a second thought don't necessarily have to be, and there are plausible benefits to the alternative. So this isn't exclusive with background loading / prefetching.

Re: A JavaScript-Free Front End

#183

Post by cfv »

gambler wrote: post #141
roebk wrote: post #115

Earlier quoted context omitted.

This is not simply about modals. Using VoiceOver and Chrome I cannot access the pop up menu to navigate the site. These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing. More specifically, no you cannot add keyboard shortcuts "with 0 rework". How are you returning the users focus to the active element before they opened the modal? The key is not to use an "arb…

>These CSS tricks are cool but they shouldn't be used in a production environment without basic usability testing. The same can be said about any JS library that interacts with page controls. The wast majority of modal dialog implementations on the web do no follow the standards you're referencing. Do you routinely criticize websites on this basis, or is this criticism only reserved for ones that use vanilla HTML+CSS…

> The same can be said about any JS library that interacts with page controls.

Difference being JS, if written by an averagely competent individual, can be changed once and this change will apply to any instances where it's called, and this cute pattern will need to be manually updated in any number of places where it's applied, one by one.

> Yes, you can. 0 rework != 0 work.

Rework meaning you have to go back over the "done" thing and then do more to cover the technical debt. On each and every instance of the thing.

> if something in your JS gets broken

As opposed to replacing the cute styling trickery for browsers that don't really support it, which is somehow better?

Re: A JavaScript-Free Front End

#184

Post by duchenne »

cfv wrote: post #181
duchenne wrote: post #179

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my…

Just a stupid question. Why would you need a bundler for plain HTML? I agree on everything else, but I kinda tripped on that and I'm not sure what you're actually looking for.

If you have a solution to avoid using a bundler altogether, that would be great. Personally, I would use it for:

- compression of html/css/images.

- css compatibility with old browsers.

- source map / auto-refresh during development.

- For any even slightly complicated app, you still need at least a bit of javascript. So, you need babel, minification, source maps, and so on...

Re: A JavaScript-Free Front End

#185

Post by combatentropy »

hliyan wrote: post #8

This is totally true. We've recently started to discover this paradox ourselves: when styling and layout is all done via CSS, and JS + other assets are cached, HTML is just as light weight as JSON over the wire. As ashamed as I am to admit it, our newest innovation appears to be "multi-page apps"!

Yes, the keys in JSON take up about as many bytes as the tags in HTML.

Re: A JavaScript-Free Front End

#186

Post by pdimitar »

duchenne wrote: post #179

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my…

Err, isn't everything you are worried about also served quite well by all server-side rendering frameworks since forever?

I legitimately cannot understand your issue.

Re: A JavaScript-Free Front End

#187

Post by duchenne »

pdimitar wrote: post #186
duchenne wrote: post #179

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my…

Err, isn't everything you are worried about also served quite well by all server-side rendering frameworks since forever? I legitimately cannot understand your issue.

You just probably know things that I don't know. That's why I am asking.

Which SSR framework do you prefer?

Re: A JavaScript-Free Front End

#188

Post by Azrathud »

duchenne wrote: post #179

How do you guys achieve this in practice? I made my home page without javascript, and it is blazing fast. But as soon as I try to make something more complicated I bumped into practical problems. - Components. I want to have the same navbar on all my pages, but I don't want an un-maintainable copy-pasted code on all my pages. - Data. I need to display some data that is different for each user. How do I embed it in my…

I try to go minimal javascript. There are two main ways you can limit javascript: static site generation or a rendering via a backend language.

Solutions

Use a templating engine with a backend language. My goto is jinja. For example you create a nav template and then include that template in your larger templates. You can then render different templates depending on the given route or file.

Alternatively use a static site generator. I use pelican. The static files are generated upon deployment from markdown for content, scss for css, templates for html, etc. There are plugins for using minifiers.

For user specific data, You can give the user a randomly generated session id cookie generated via a backend language. The backend language generates further pages based on information retrieved from the session id cookie. The session id would correspond to state in some database. Async data loading cannot happen without client side javascript.

- Dev tools: Write tests. the backend language would have developer tools such as a debugger. Generally you can run a dev server which allows to to drop a breakpoint upon failure. (backend frameworks can support this) Alternatively, you can change the rendered HTML via a debug flag (for local testing).

For PHP, The HTTP server serves the rendered files from the backend language's application server / module therefore you normally wouldn't be able to directly edit the backend code via a web browser.

Re: A JavaScript-Free Front End

#189

Post by onion2k »

billyhoffman wrote: post #174
onion2k wrote: post #14

Since I'm caching and gzipping everything, each subsequent pageview is around 6 KB; far smaller than the SPAs I've seen with equivalent functionality. That's ace. But my internet connection has a 2 second latency so I still have to wait an annoyingly long time every time I interact with your app. My connection is terrible too, so it drops every 10th request, and now I'm seeing a lot of broken pages. If only you'd wri…

It’s great that you have an opinion about the benefits of a SPA for slow connections and other people (lower comments on this thread) have opinions about how “easy” it is to implement request retries and caching/service workers. I have an opinion too. But my opinion and your opinion really are moot. Because do you know whose opinion is probably backed by the most data and the most expertise? Google’s Gmail team. And…

Gmail's slow connection message is great, but it's there because Gmail is a multi-megabyte app that will take a long time to download if you're on dial up or something. That's a bandwidth issue rather than latency or line quality problem. None of the points I made say anything about bandwidth.

I completely agree with the point you're making though; if a user is on a low bandwidth connection then sending as little data as possible is best, and that's likely to be plain HTML with very little rich content like images.

That said, Gmail's slow connection UI is horrible to actually use. Very few people choose it over normal Gmail. Most people want the big fancy app, so we as developers should work out the best way to deliver that.

Re: A JavaScript-Free Front End

#190

Post by ritty »

I admit it, I hate single page apps. I see very few that actually work well. I don't hate JavaScript, it has its place, but you don't need to make an entire website an SPA. Stuff like the main Spotify, Slack, or Discord pages, and even things like Google Docs, and email front ends are fine for SPA. But you don't need to also embed all the FAQs and other crap into the SPA. You know what isn't an SPA? Hacker News. You know what else isn't? Google, GitHub, Amazon, and Stack Overflow. I've disabled the SPA version of Reddit. I've built SPAs and they are so much harder and take so much longer to develop and maintain than traditional web sites. I wish they'd just die. Sadly, everyone else at my work orgasms about SPAs, pushing every damn thing into it. We have stuff that works perfectly well and no one has ever complained about it? Screw it, let's spend $50k turning that feature into an SPA. I know many of you disagree with me and I'll get off my soap box now.
Post reply on HN