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

Second-guessing the modern web (2020)

macwright.com

Post reply on HN
Print view View original

191–200 of 309 posts

Re: Second-guessing the modern web (2020)

#191

Post by gspr »

tshaddox wrote: post #102
young_unixer wrote: post #20

I have a very good idea of how the web used to work 10 years ago. But when I try to learn Modern Javascript frameworks, the tutorials rarely do a good job of explaining that they won't teach me how to create a normal, traditional website, or if it's even possible to create a normal website with the framework. They simply assume that the modern way is the standard way. I want a modern alternative to PHP, but the JS co…

Server-side Node.js still exists and, if you like, can be quite similar to good old PHP. A "Hello World" app in Express.js is pretty barebones and easy to get started with, and there are probably lots of comparable alternatives. I've always found Express.js to have a big community with lots of guides and info, although I admittedly haven't had the experience of coming to it as a newcomer to programming or the web.

This is something I'll never understand: Isn't the only selling point of JS that it runs on every web browser? Why would anyone want to use it (or, in 2021, PHP) on the server side, where you can use any language you want?

Re: Second-guessing the modern web (2020)

#192

Post by adwn »

arsome wrote: post #50
nemothekid wrote: post #24

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

Yep. We recently did an assessment of available UI libraries and pretty much concluded the best maintained libraries with a modern look and feel are all web-focused and we're likely to have to settle for building an electron app if we want to be able to take advantage of the best selection of 3rd party libraries without building as much ourselves. As much as I don't like the ecosystem or Javascript as a language, the…

> Seriously, what is there?

Take a look at Sciter [1]. You build your UI using HTML/CSS/JavaScript, and your application logic in any language with a C FFI [2], and it supports Windows, Linux, Mac OS, and Android. The distribution size is tiny: only a single dynamic library of around 10 MiB. It's not open source, though.

[1] https://sciter.com/

[2] Available bindings, apart from C and C++: https://sciter.com/developers/sciter-sdk-bindings/

Re: Second-guessing the modern web (2020)

#193

Post by pengwing »

blakewatson wrote: post #145

I always have cognitive dissonance about this kind of stuff. I read this article and “In defense of the modern web” and I feel like I agree with both of them. I think new things don’t necessarily make older things obsolete. We have printers, for example, but it’s not like pens, pencils, and even chalk aren’t useful. Whenever I start a new project (admittedly, these are personal projects so not the same kind of scale—…

>new things don’t necessarily make older things obsolete. We have printers, for example, but it’s not like pens, pencils, and even chalk aren’t useful.

When first reading your example, I expected the printer to be the old technology. I think printers and pens have very different use cases. Using a pen establishes a creative loop with direct feedback, while printing is about making a copy of something that already exists. I think its fairer to compare a printer to digital storage/digital display of a document. The former exists due to ancient legal requirements when signing contracts.

Similarly delivering a cached SSR HTML document fast and hydrating it with JS afterwards is the way to go. TTI is only a problem if you don't use regular links as fallbacks to make requests before hydration replaces them with JS-based event Handlers.

Implement the modern web by using the established web as a fallback.

Re: Second-guessing the modern web (2020)

#194

Post by onion2k »

kristopolous wrote: post #147
jkaplan wrote: post #64

I agree with a lot of these points, but differ slightly in two regards: 1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns. 2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product land…

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…

I find it slightly incredible that someone can describe React as "the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years", have a whole bunch of complaints about how bad it is, and how it makes no sense, and how it reduces their productivity by a factor of 100 ... and then also use it for 5 years.

Re: Second-guessing the modern web (2020)

#195

Post by tempodox »

I've got one nitpick:

> ... frontends [...] have been loyal to one programming language for decades.

I wouldn't call using the _only_ thing available “loyalty”, its just do-or-die.

Other than that, the article rings true for me.

Re: Second-guessing the modern web (2020)

#196

Post by onion2k »

adreamingsoul wrote: post #183

I have to admit, I’ve been avoiding TypeScript and React for any professional projects. TypeScript due to lack of experience, but I understand the benefits. React due to many reasons, but most of which is that I don’t agree with the “benefits”. I have been working with the Frontend for over a decade and have been on the forefront of its progression. KnockoutJS was a pivotal moment and cemented what followed with Back…

There's no reasonable argument that you can make in favor of Knockout, Backbone (I hope you mean Marionette though... no one used Backbone on its own), Angular, or Vue that doesn't also apply to React.

Re: Second-guessing the modern web (2020)

#197

Post by wonnage »

kristopolous wrote: post #147
jkaplan wrote: post #64

I agree with a lot of these points, but differ slightly in two regards: 1. In my experience React DOES lure people into the "pit of success" in at least one important aspect -- modular and re-usable front-end code. React is certainly not the only way to get this, but it does help force you into some good patterns. 2. The "sweet spot" for React is pretty large. If your site is truly static (e.g. a blog, a product land…

How? It's the most painful, difficult, slow, frustrating, confusing programming experience I've ever had in my 25 years. It's made me want to leave the industry completely and I honestly think I will after this project. It has single handedly slaughtered and destroyed my quarter century love affair with programming. It's a wildly inflexible architecture that aggressively forces their users to conform to an orthodoxy…

I'm sorry you have this experience. I think the most confusing part of React for me was that even though JSX looks like HTML, you're actually not interacting with HTML at all. At its most basic you're just giving React a `[{ type: 'div' }]` and it will create and manage an actual for you.

Re: Second-guessing the modern web (2020)

#198

Post by BiteCode_dev »

nemothekid wrote: post #24

One thing I've seen happen again and again in a lot of technologies is a "framework gravity". A lot of people see this as engineers just wanting to work on "hype" technology but I think what is actually happening is a reflection of global engineering time. React is great for SPAs. Most large companies are working on honest-to-god SPAs. By extension most engineers are working on SPAs. So most tooling is created for SP…

> Most large companies are working on honest-to-god SPAs.

Most devs don't work at large companies, at least not tech oriented large companies. I'm almost certain most projects don't come out from such companies either, statistically.

In fact, most projects are not SPA, nor using any kind of AI, Big Data, or another buzzword.

So I don't think that's it.

I think that large companies are just the loudest, also creating/promoting popular FOSS projects, and they have great engineers that are on many social networkd, including HN, or write famous blogs.

And so people have the impression that you need an SPA into a docker mix among other microservices each horizontally scaled in the cloud, monitored using an observability framework, using a big data pipeline for processing things they will store in their NoSQL sharded DB accessible through a GraphQL Api.

Because Jack working at GAFAM for $500k has the time, env and will to sing about it, but Juan working in a Madrid bank is just spending his company time fixing the Tomcat server quietly.

Re: Second-guessing the modern web (2020)

#199

Post by onion2k »

bmeski wrote: post #151

I've seen the issue of new hires, time after time, getting a small ui ticket and immediately asking, "where is the client store?" or "Why aren't we using Redux, it'll clean up our code a bunch." Of 20+ applicants I've interviewed this year, only 2 knew about element.dataset and how to create a basic state scoped to that vanilla JS "component". The issue is groupthink and using the hammer on everything.

The point of Redux (or any state library) is to share state between components. Unless you're doing something like putting the state for a child in the data- attributes of a parent somewhere further up the tree I don't think element.dataset does the same job at all. element.dataset is much closer to something like using useState.

Re: Second-guessing the modern web (2020)

#200

Post by wonnage »

bmeski wrote: post #151

I've seen the issue of new hires, time after time, getting a small ui ticket and immediately asking, "where is the client store?" or "Why aren't we using Redux, it'll clean up our code a bunch." Of 20+ applicants I've interviewed this year, only 2 knew about element.dataset and how to create a basic state scoped to that vanilla JS "component". The issue is groupthink and using the hammer on everything.

It's probably because invoking DOM APIs is terribly slow and if you're accessing those fields with any frequency you're better off using a JS object.
Post reply on HN