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

51–60 of 215 posts

Re: A JavaScript-Free Front End

#51

Post by eeeeeeeeeeeee »

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

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.

Re: A JavaScript-Free Front End

#52

Post by superkuh »

pault wrote: post #45
superkuh wrote: post #39

This write-up mostly highlights the loading speed and bandwidth benefits but not requiring javascript is far better than just that. In the age of spectre and with browsers exposing more and more bare metal functionality the idea of running arbitrary code on every random site I go to is absurd. There's dozens of us that simply don't run JS. Sites like these (and, say, the way chicago public media does fallback for no…

> There's dozens of us that simply don't run JS Was this intentional? It gave me a bit of a chuckle.

It was an acknowledgement that there aren't enough people like myself for web devs at for profit businesses or institutions to care about.

Re: A JavaScript-Free Front End

#53

Post by tracker1 »

sixstringtheory wrote: post #22
tracker1 wrote: post #15

Earlier quoted context omitted.

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

I get the snark, but Java, Rust, Erlang are all better options than an interpreted language for backends IMO

Define better... Scripted languages can be run without the need for a compilation step, if you're scaling horizontally anyway, you can do nearly as well with node, and node can handle 100k+ connections per core with minimalish memory overhead. Functions are first class, functional approaches are easy and flexible, and when you're just passing bytes to another system or database, JS/Node works well.

As to interpreted languages, JS/V8 has probably seen more optimization than any other interpreted language. As to Java, you don't need a 400-500mb base image either. Rust takes much longer to develop against, as does erlang even if you're familiar with it. If you're parsing JSON into concrete objects, the overhead is often larger with compiled languages than interpreted, where JS just works. I can generally get stuff working in around 1/8 the time it takes for peers to use a compiled language to do the same.

Go is probably a better option than the three you suggested, even then more often than not, I would choose node, just because of the flexibility I get with npm and the larger community. If I, in turn need to eek more performance, or have a process that requires more compute per request, then I'll often reach for another language and/or even choose a Function as a Service wrapper.

Re: A JavaScript-Free Front End

#54

Post by tracker1 »

2038AD wrote: post #27
tracker1 wrote: post #15

Earlier quoted context omitted.

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

It's doable https://learnbchs.org/

I know... used to do CGI with C++ apps and Perl in the nid 90's. I was being snarky, but there are a lot of tools to do web requests in lower languages, and classic CGI did work well enough in a lot of ways, though the security concerns now are huge.

Re: A JavaScript-Free Front End

#55

Post by btbuildem »

zachguo wrote: post #44

What JS does can be reduced to several things: - storing states, and conditionally passing states around - toggling things on or off - element reuse - dealing with events - ajax Unfortunately it's unlikely HTML & CSS would support all these.

Interactivity is a huge part -- moving things, adjusting parameters, live rendering, etc. Think D3, Crossfilter and such.

Re: A JavaScript-Free Front End

#57

Post by lhorie »

zachguo wrote: post #44

What JS does can be reduced to several things: - storing states, and conditionally passing states around - toggling things on or off - element reuse - dealing with events - ajax Unfortunately it's unlikely HTML & CSS would support all these.

The paradigm shift here is that most of these things would be done in the server using traditional techniques: ajax, events, state are all handled via form submissions. The only things in this list that are really "frontend-ish" are element reuse (which, for styling purposes, is accomplished via CSS methodologies) and toggling things on/off, which in the CSS-only corners of the web is accomplished using a radio box CSS trick.

Behavioral augmentation that these days is encapsulated via componentization (e.g. tabs, carousels) is also something that has been explored to death in traditional paradigms, e.g. unobtrusive js

Re: A JavaScript-Free Front End

#58

Post by jonstaab »

timw4mail wrote: post #36
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…

I keep hearing offline-first trumpeted, but I have seen no examples of what that means. Terrible connections exist. But I fail to see how adding more scripting will always help with that. Service workers are definitely promising, but documentation for common use cases is still lacking. Even with a terrible connection, I would still trust a server-side app to load correctly on a refresh more than a SPA. If anything, t…

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 consideration). And they have the potential to save developers work, since you can get away with a PWA instead of native apps on 2+ platforms.

Re: A JavaScript-Free Front End

#59

Post by e12e »

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.

You have to load the whole page again. It may be slower.

Re: A JavaScript-Free Front End

#60

Post by snazz »

tedunangst wrote: post #40
timw4mail wrote: post #36

Earlier quoted context omitted.

I keep hearing offline-first trumpeted, but I have seen no examples of what that means. Terrible connections exist. But I fail to see how adding more scripting will always help with that. Service workers are definitely promising, but documentation for common use cases is still lacking. Even with a terrible connection, I would still trust a server-side app to load correctly on a refresh more than a SPA. If anything, t…

I think they're talking about mobile twitter, where every time I visit I see the message "something went wrong". Then I tap retry and get the same message. It's very offline first. Then I reload the whole page and get the online version.

It seems to have to do with blocking their trackers: https://news.ycombinator.com/item?id=19130667
Post reply on HN