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

The unreasonable effectiveness of simple HTML

shkspr.mobi

Post reply on HN
Print view View original

191–200 of 387 posts

Re: The unreasonable effectiveness of simple HTML

#191

Post by SulfurHexaFluri »

ratww wrote: post #68
apabepa wrote: post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates…

>The issue is that a lot of developers will want to use React for everything else on the page, because they think it's "icky" to use other kinds of tech in other parts of the website.

It is though. I work on an app thats 80% react and 20% rails SSR and when working on anything, seeing that an area that needs change is written with SSR makes the job 10x harder as you have to come up with alternative methods to get it working or just rewrite it in react. When everything is react everything is quite easy and you can pass around data and update things without a refresh easily.

Re: The unreasonable effectiveness of simple HTML

#192

Post by SulfurHexaFluri »

michaelpb wrote: post #174
ratww wrote: post #68

Earlier quoted context omitted.

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates…

A few years ago when teaching at a previous coding bootcamp that started with FE JavaScript, I remember my surprise when well-performing students got through 3 months or so of it and were confused and very impressed when I showed them how an tag worked, since they had only been aware of (jQuery) JavaScript powered pages. When you are stuck just doing JS powered SPAs, an tag seems like advanced technology! I ended up…

Almost every JS app I have seen uses a tags though. Even if they are just links to # pages. With most router libraries you can even use real paths and it works all on the front end. Sounds like you found one anecdotal case that didn't know this.

Re: The unreasonable effectiveness of simple HTML

#193

Post by SulfurHexaFluri »

ratww wrote: post #134
ziftface wrote: post #117

Earlier quoted context omitted.

The fact is, the Javascript ecosystem is unmatched when it comes to very quickly creating frontend applications. Maybe another set of tools would have been better, but that doesn't really matter. This set of tools is what everyone uses, and a lot of effort and creativity goes into making js frontend development as smooth and fast as possible. I often need to very quickly make internal services at my job and while I l…

I disagree. Rails was already faster for CRUD apps back in the mid-2000s. Batteries included, maybe a gem or two for an admin panel or for auth. Not that it matters, but rails new is probably faster than 60 seconds too. Django is pretty good too. ASP.NET Webforms was made for CRUD, and it even provided a WYSIWG designer back in the early 2000s. And it was just a matter of launching Visual Studio and creating a new pr…

Rails is an excellent choice for the backend but on the frontend its much less productive than react. Most rails apps these days would use rails as an api backend and react on the frontend.

Re: The unreasonable effectiveness of simple HTML

#194

Post by labawi »

pvorb wrote: post #181
acdha wrote: post #141

Earlier quoted context omitted.

> One of the great things about accessibility is that it often doesn't just benefit people with disabilities. I really love how Microsoft's design team has pushed this with their “Inclusive Design” concept[1] and highlighting how any sort of disability can be situational (holding a baby), temporary (broken arm), or permanent (missing arm) but we often only think of those in the last context despite there being orders…

I fully agree with all of your points. I just wanted to point out the irony that the manual and other documentation for this "inclusive design" toolkit come as PDFs – the worst choice you can make if you strive for accessibility.

I may be missing something obvious, but why is pdf such a bad choice?

As long as it has actual text and is reasonably typeset (selecting text in this pdf seems to work properly), I don't see what's wrong. I'd take it any day over webpages with random floating content that you have to click through and use a modern browser with javascript without blockers/filters for the content to even render, in small text on 20% of the page, with low contrast and somehow broken zoom.

Re: The unreasonable effectiveness of simple HTML

#195

Post by SulfurHexaFluri »

spideymans wrote: post #125
MaxBarraclough wrote: post #51

Earlier quoted context omitted.

From what I can tell the short answer is that you're right, there's really no good technical reason for all that weight. Which is to say, it's just bloat. Much has been written on this. Here's an article from 2018. (I realise the irony in that it's hosted on Medium.) https://medium.com/@addyosmani/the-cost-of-javascript-in-201...

The JS performance difference between high and low-end devices is stunning (9s vs 32s load times, based on the Medium article). Web devs, who are often used to using the latest and greatest devices, will have no idea how terrible their code performs on slower devices. And I fear that modern CPUs with excellent JS performance will only exacerbate this issue

I had always been using 2-3 year old android phones for the last 7 years and I was unable to comprehend how anyone uses the web on mobile because everything was so incredibly slow in the browser while native apps were fine. Then I got the latest iphone and my mind was blown at how I could scroll a website at 60fps. I guess if you have the fastest phone on the market, everything seems fine.

Re: The unreasonable effectiveness of simple HTML

#196

Post by godshatter »

mattl wrote: post #55
tshaddox wrote: post #17

Earlier quoted context omitted.

What if a device doesn't have a web browser? Or a display? Or a network connection? At some point you have to make some basic assumptions about the platform you're targeting.

There are many web browsers that don't support JavaScript, and JavaScript is something that can be quite easily turned off in many browsers that support it. Harder than it used to be, if anything.

Then there are those like myself that run NoScript or something similar where the author of the website has to entice me into allowing them to run javascript code on my computer. If I can find the correct one to enable out of the dozen or so that most websites seem to use.

Re: The unreasonable effectiveness of simple HTML

#197

Post by antonhag »

ratww wrote: post #68
apabepa wrote: post #19

I am not a front-end developer but looking at it from a distance I really don't get modern web design. Sure some sites might need fancy javascript single page features, like if your webpage is an interactive map or realtime game, but most sites are just text and some pictures. Whats with all the javascript? Your site looks just like the next one anyway! It feels like an "Emperor's New Clothes" situation or maybe more…

As someone involved in hiring, this is what Bootcamps and Universities are teaching, and what companies are looking for: backend spits JSON, frontend consumes it using React. Rendering HTML on the server is not really "the default" anymore as it was 10 year ago: it's more of an optimization for when your React site is slow, and it's a black box to most people. Even static websites are "strange tech" to new graduates…

One thing I love about Svelte/Sapper is that it can be used for both the server-side rendering and the interactive map. And it doesn't feel like an afterthought - idiomatic usage leads to server-side rendered html with progressive enhancement of JS.

Re: The unreasonable effectiveness of simple HTML

#198

Post by Aeolun »

reificator wrote: post #182
madeofpalk wrote: post #148

Earlier quoted context omitted.

FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-jsx-a11y

> FWIW, using React or whatever makes it more obvious that you're making these mistakes because your event handlers are attached right on the "HTML" element. It makes it easy to spot because you see > > and it immedaitely sticks out as a mistake. Because its easier to statically understand these mistakes, theres even tooling to automate detecting some of them as you type https://www.npmjs.com/package/eslint-plugin-js…

Depends on how far you are linting it? If you lint your node_packages folder you may still catch these.

Re: The unreasonable effectiveness of simple HTML

#199

Post by SulfurHexaFluri »

superkuh wrote: post #166
chrismorgan wrote: post #95

Earlier quoted context omitted.

The trouble is that you can’t support HTTP without completely undermining HTTPS. If you support HTTP at all , you’re damaging the experience for the almost everyone that could have used HTTPS: almost no one will get the HTTPS version unless you deliberately push them over to it, which you will only be able to do after page load by some JavaScript-based user-agent or feature-based sniffing, so now the page loads and t…

The implicit premise here is that your website requires HTTPS only and that a theoretical downgrade attack is enough to justify not having http at all. Most websites don't even need HTTPS and the complications and sacrifice of autonomy required isn't worth it. Remember, there are no cert authorities that are human people. They are all corporations or institutions. Having to get an incorporated entity's permission to…

I'd flip that and say you should only support http if your website absolutely requires it. Unless you absolutely can not avoid supporting old devices you should just redirect http to https.

The privacy of all users is more important than supporting the outdated browser on an ereader.

Re: The unreasonable effectiveness of simple HTML

#200

Post by SulfurHexaFluri »

kstrauser wrote: post #87
salutonmundo wrote: post #63

The worst web browser I have access to is the "experimental" one on a Kindle 4. Most web pages that one might want to visit will not load in this web browser—because it does not support modern versions of TLS. For the reasons mentioned in this article—it's probably a good idea to keep plain HTTP access available on your websites.

Eh, 98.24% of all users worldwide can use TLS 1.2: https://caniuse.com/?search=tls%201.2 I'm not willing to make security exceptions to support devices from 2011. "HTTPS by default" lifts all boats: people who would MITM your users can't tell if they're reading your nice blog or a critique of their local government, and that's a good thing.

With DNS over HTTPS and encrypted SNI, soon the only information you will get is "They accessed a website on amazon/cloudflair"
Post reply on HN