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

101–110 of 215 posts

Re: A JavaScript-Free Front End

#101

Post by smokeyj »

lhorie wrote: post #95
smokeyj wrote: post #91

Earlier quoted context omitted.

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 sti…

> Are you saying that rhetorically?

No.

> And besides, the point here was largely about bundle size and fast time-to-interactive.

As long as the point wasn't to be productive I'll just mind my own business.

Re: A JavaScript-Free Front End

#102

Post by JimDabell »

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…

> 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.

I often work on a train over a 4G connection, so this describes me too. I much prefer traditional style web applications over SPAs specifically because of this.

You know what happens if a request is taking too long or fails with a traditional web app? I hit reload and it retries.

You know what happens if the same thing happens with most SPAs? It throws away my unsaved data and puts me back on the starting screen.

Sometimes there's a JavaScript-powered retry I can use instead. Sometimes it works, usually it is very unreliable (if something has failed to load, often the JavaScript is having problems too).

Sure, I'm willing to accept the possibility that an SPA can be written in such a manner as to compensate for this hostile environment. It's just: I've used a lot of these apps, and I haven't found one that works reliably over a poor connection yet.

Re: A JavaScript-Free Front End

#103

Post by 781 »

tracker1 wrote: post #15
andrewfromx wrote: post #4

100 percent agree. Use as little JS as possible on front end. And then definitely use zero JS on backend.

Definitely...only use C on the backend, any other language is just a hack.

C is too high level and bloated. 20 kb for a hello world executable? That's just shameful.

Assembly language backends on the other hand absolutely scream.

And with a modern IDE they're a joy to develop.

Re: A JavaScript-Free Front End

#104

Post by mercer »

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.

The main issue I have with this idea is that in practice I've almost never found the difference in payload to matter all that much, even on bad connections.

In some cases, even sending the entire HTML document and diffing on that using morphdom (because redrawing does bring noticeable cost rather quickly) was a viable strategy even compared to the most optimal json payload.

I'd very much like to see some examples that prove me wrong though, because while I've done some experiments, I might be underestimating how complex many web apps are. It's mostly that the apps I built in hindsight were often better off with a more old fashioned server-side, morphdom, turbolinks (or maybe intercooler?) type approach.

Re: A JavaScript-Free Front End

#105

Post by winduptoy »

theandrewbailey wrote: post #92
winduptoy wrote: post #68

Earlier quoted context omitted.

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

Yes it's WOFF2, served over gzip. I do not think that I can eliminate extra character ranges because Slimvoice is used all over the world.

Re: A JavaScript-Free Front End

#106

Post by jordache »

well some needs to create a framework around this concept. Have the build process spit out only HTML and CSS that employ these exotic strategies.

It's entirely unsustainable to have a team build an app using these patterns.

Re: A JavaScript-Free Front End

#107

Post by sbr464 »

winduptoy wrote: post #82
sbr464 wrote: post #46

Nice work, I definitely appreciate the focus on simplicity/speed. I just signed up to check it out. I noticed on the invoice page, on mobile, the number inputs (qty, price, etc) showed the full alpha keyboard on input. I think you can add a few attributes to optimize, without using JS also. Great work, thanks for sharing. This link has been helpful for me: https://developers.google.com/web/fundamentals/design-and-ux.…

Thank you! I had no idea that iOS required the pattern="\d " attribute. Those inputs require a decimal, so that pattern won't actually work (something like pattern="\d \.?\d*"). If I can get my hands on an iPhone to test that, I will deploy it shortly!

Awesome!

Definitely a few hacks involved. I’ve seen different combinations of using pattern, type=number, step=“0.01” etc, but you may need support for longer decimals in qty/price.

I’m always on the lookout for form best practices, but it’s definitely hard to stay up with all of the current trends.

There are a few mobile preview tools, not sure which is currently best, for testing on different virtual devices:

Google search: test site with iphone online

Re: A JavaScript-Free Front End

#108

Post by tomca32 »

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…

> Author could have installed next.js and called it a day.

Not a day, but probably a week of debugging. Each and every suggestion you made in your comment makes the deliverable tremendously more complex, is very expensive, will need ongoing maintenance, and is ultimately not needed.

Javascript apps are tremendously complex, why would do this if you don't have to?

Re: A JavaScript-Free Front End

#109

Post by kabes »

> I built the first version of Slimvoice on Angular 1 with a Node.js backend and MongoDB in 2014 (those were all the rage back then). In 2015 I decided to completely revamp the UI and redesigned and rebuilt it in React.

Maybe you should make decisions based on requirements instead of hype. Oh wait:

> Don't follow the hype

But using less javascript is the hype today...

> Plain Old HTML and CSS

This section only shows some very basic UI elements (dropdown, expansion panel, ...). This isn't what libraries like react solve.

> Absolutely nothing is complex about my code

I wouldn't label CSS hacks with invisible checkboxes under "simple and self-explanatory code".

> I found myself wishing for more innovation in the HTML spec

I don't think adding even more bloat to even more web standards than a browser already has to support is the anwser.

Post reply on HN