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

91–100 of 215 posts

Re: A JavaScript-Free Front End

#91

Post by smokeyj »

ddoolin wrote: post #12

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style,…

The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day.

If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line.

In the time the author re-wrote his app, I could have gotten the same benefits with SSR and ported it to react native. But yeah, javascript bad REEEE

Re: A JavaScript-Free Front End

#92

Post by theandrewbailey »

winduptoy wrote: post #68
shove wrote: post #33

This is really great but I was really surprised by that 230k number. Expected ~150k

Hey, author here. Just for reference, 180k of that is fonts. The rest is super tiny. Of course, once you've loaded it the first time, it's cached.

Have you tried minimizing that? Are you using WOFF2? Have you eliminated extra character sets/ranges? I know of a tool that can help:

https://www.fontsquirrel.com/tools/webfont-generator

Re: A JavaScript-Free Front End

#93

Post by robocat »

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 drops every 10th request

Who has good heuristics for retry (or other techniques) to achieve reliable communications for a PWA?

We do retries, with a few different strategies, but we have a poor idea of exactly how effective (or not) our retries are. Also my code for this is ugly and it's a nasty area to test properly...

Re: A JavaScript-Free Front End

#94

Post by [deleted] »

roebk wrote: post #87

It's perfectly possible to do some nifty tricks with CSS alone. The one thing this author has omitted is the impact this has on accessibility. Sure, I can open a modal without the need of JavaScript, but my focus isn't trapped within the modal and with no standard keyboard shortcut (ESC) to dismiss the modal, it provides a sub-standard experience for all users. Be sensible and use JavaScript when it's appropriate. Pl…

[deleted]

Re: A JavaScript-Free Front End

#95

Post by lhorie »

smokeyj wrote: post #91
ddoolin wrote: post #12

These are handy tricks, even in JS at scale, and I'd recommend their usage if you can (big if, business requirements come first for most of us). That said, I don't really buy into the no JS/purism movement for load/execution speed. For bite-sized apps or simple pages, sure. However, it's completely possible and not that hard to develop full-blown web application suites using full JS for everything (structure, style,…

The whole thing is a solved problem. You can easily render React apps on the server and send HTML down the wire, then lazy load the rest of the JS. Author could have installed next.js and called it a day. If you put your app logic in something like Redux it'll work on server-side rendering, client-side rendering, and can be included in react-native down the line. In the time the author re-wrote his app, I could have…

> I could have gotten the same benefits with SSR and ported it to react native

Are you saying that rhetorically? In my experience, React is no silver bullet (e.g. different router and styling mechanisms for RN), trickiness dealing w/ timezones in SSR, etc.

And besides, the point here was largely about bundle size and fast time-to-interactive. Next.js optimizes a lot for developer experience, but you're definitely still going to be shipping a pretty sizeable JS bundle with slower characteristics than a hand-coded "closer-to-the-metal" thing.

Re: A JavaScript-Free Front End

#96

Post by ddoolin »

mrec wrote: post #84
eeeeeeeeeeeee wrote: post #51

Earlier quoted context omitted.

Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.

"people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is . There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance,…

It wasn't posited as advice to a specific question, but rather a guiding principle, which is still valid and bears repeating given the frequency of the mistake.

Re: A JavaScript-Free Front End

#97

Post by incadenza »

mrec wrote: post #84
eeeeeeeeeeeee wrote: post #51

Earlier quoted context omitted.

Seems like once again people just need to pick the right tool for the job. The problem is that people get stuck into one framework and it’s familiar to them so it gets forced into a project it doesn’t make sense for down the road.

"people just need to pick the right tool for the job" is utterly useless advice, just as "you should do the right thing" is an utterly useless answer to an ethics question, because it doesn't help you decide what the "right" tool/thing is . There are lots of considerations in answering that usefully. Fit for the particular problem domain is one of them, yes. But so is familiarity. And ease of hiring. And performance,…

It’s a quip used to remind people to work backwards from the problem they’re trying to solve, not the other way around.

I think it’s an appropriate response to blanket advice on choice of tech stacks.

Re: A JavaScript-Free Front End

#98

Post by jonstaab »

mercer wrote: post #90
jonstaab wrote: post #58

Earlier quoted context omitted.

Henrik Joreteg ( https://twitter.com/HenrikJoreteg ) makes some pretty good arguments for PWAs. I've not had the chance to work on one, but when you start looking at mobile devices in particular, they do seem to be a good middle ground between the slimness of a document (web page) and the capability of a native mobile app. They're also not mutually exclusive with "no javascript" (if you do it right, which is a consid…

I'm very much on board with the promise of PWAs, but so far I've never found an approach that didn't feel too complicated/tedious. That said, I've not made serious attempts in at least a few months, maybe a year. Would you say the situation has solidified/standardized in the interim, and if so, could you point me to some resources?

Unfortunately, I'm in the same boat, having only fiddled briefly with some of the newer web APIs, rather than architecting an app around service workers. My impression comes from folks like Joreteg who do the work, and from the increasing frequency with which new native-like APIs are released into browsers (though almost invariably implemented badly).

That said, even though the way service workers are registered is sort of odd, they're pretty trivial to work with once you're there. As far as resources go, MDN is always pretty solid, and this post (https://developers.google.com/web/fundamentals/primers/servi...) on Google's web dev guides is what I used to familiarize myself with them.

Re: A JavaScript-Free Front End

#99

Post by gambler »

Geee wrote: post #43
gambler wrote: post #21

Earlier quoted context omitted.

I remember there was some ridiculous article here where the author claimed to build world's fastest web app with PReact. It was a hierarchical list of HTML5 features with some tick-boxes. Out of curiosity I converted the giant JSON blob to list. HTML was about 15% smaller than JSON. You could also do most of the "logic" of the app via styling and normal HTML controls.

The benefit of JS comes in incremental updates. When you update that list with a new item, you can use optimistic update and small payloads in JS, while in HTML you have to load the whole page again, which is slower.

Firstly, the application I was talking about[1] didn't have real updates.

Secondly, no one stops you from doing incremental updates with HTML except they way you design your data structures and UI.

In fact, HTML has something that JSON doesn't. Semantics. This means you can create a generic setup for incremental updates based, say, on element IDS.

---

[1] https://hackernoon.com/10-things-i-learned-making-the-fastes...

Post reply on HN