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

Second-Guessing the Modern Web

macwright.org

Post reply on HN
Print view View original

51–60 of 467 posts

Re: Second-Guessing the Modern Web

#51

Post by seangrogg »

austincheney wrote: post #33
tiborsaas wrote: post #29

Earlier quoted context omitted.

> instead of settling down and focusing on getting the most out of a platform How do you know when to settle? Should we have stopped at jQuery? We are doing exactly what you are asking for, but not in the way you like. Web developers are getting the most of the web platform. The result is that new frameworks and libraries are keep popping up. Most will sink, a few will float and it's okay, this is how evolution shoul…

> Web developers are getting the most of the web platform. I disagree, as so many (perhaps most) web developers have no idea what to do with web technologies aside from building SPAs in their pet framework.

And most backend engineers don't go architecture astronaut Kafka, Cassandra, Kubernetes, et al into seemingly straightforward concepts?

The number of times I've seen Kubernetes as part of an on-prem install of enterprise software when there will only be one node was hilarious. That front-end devs get flak seems to largely be because their choices are visible, not because they are any different from the weird heaps people throw together behind them.

Re: Second-Guessing the Modern Web

#52

Post by amw-zero »

caribousoup wrote: post #34
userbinator wrote: post #8

Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, a…

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

I agree with the sentiment of what you're saying, but I don't agree with the premise that there are no use cases for single page apps. You can achieve a decent UX for some applications by using small amounts of vanilla JS, but it's simply not possible to avoid re-rendering the entire page without using XHR requests at some point. That is how the browser is designed, fundamentally. Because it wasn't designed as an application platform, it was designed as a document platform.

But some products are actually better as applications, not interconnected documents. For those applications, the browser fights you every step of the way, because that's not what it's designed for. You simply can't compare the UX of document-based web applications to native clients.

An SPA is just the web approximation of a native client. Your application truly runs in the client process continuously, so rendering transitions happen smoothly instead of blank pages and jumping transitions. Everyone would benefit from understanding more and using that to simplify all areas of the tech stack, but the experience that an SPA offers is simply not possible otherwise.

Re: Second-Guessing the Modern Web

#53

Post by seangrogg »

coffeefirst wrote: post #37
MattGaiser wrote: post #23

The problem with not using a JS framework is that eventually, the investors/business person/design team/frontend enjoying devs wants this highly animated site with all sorts of little toggles, confirmation boxes, popup models, toasts, etc. It is far nicer doing that in React where you can just casually npm in some online component that does that rather than in vanilla JS or jQuery. React is basically a compromise bet…

Except for the user, who never asked for vanity animations and hate the popups.

Well, when I am considered a developer AND a stakeholder I may be able to address that AND not be told that I'm going to implement the carousel because "market research" anyways.

Re: Second-Guessing the Modern Web

#54

Post by systemvoltage »

caribousoup wrote: post #34
userbinator wrote: post #8

Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, a…

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

Please write more about this because I feel the exact same.

Use built in HTML forms. Let the page refresh, what's wrong with going to `/orders/{order_id}` page to get information about the order? It is REST-ful and static. Why do you want things moving around and reacting? People of the internet - imagine if the internet protocols were given to us, but no browser existed. Would we develop this non-sense we have today?

What should have happened is the following:

- Develop web-to-native-UI mapper, call that thing a browser.

- Don't let developers style native elements. A drop down should not be designed by people except for the owners of the OS. Yes, it looks different on different OS but your application should be more than putting lipstick on a pig.

- Accept the fact that your application looks different on different OS'es but embrace the fact that your application works intuitively to the users, you have much less to maintain and focus on the logic of your app.

The web went downhill the day `` tag was allowed to be styled by CSS. We had a web-to-native-UI mapper!

I am forever a believer that democratically designed things generally suck unless there is a BDFL who can make shots. Dictatorship is a necessity of great products and services - Steve Jobs to Guido, democracy is good in politics, not in software development. Feature creep from the public will ruin whatever youre buidling. Designers will ravage through what worked well and replace it with "taste".

/Rant, I am getting old. Humans tried to make the web "pop", but instead it exploded with chaos.

Re: Second-Guessing the Modern Web

#55

Post by torben-friis »

daguar wrote: post #40

> But there are also a lot of problems for which I can’t see any concrete benefit to using React. Those are things like blogs, shopping-cart-websites, mostly-CRUD-and-forms-websites. For these things, all of the fancy optimizations are optimizations to get you closer to the performance you would’ve gotten if you just hadn’t used so much technology. I think this is at the root of it — most web devs today don't see tha…

Speaking as a young(ish) dev, I think the issue with SPAs is that it's that its use has been conflated with separation of concerns and agnostic backend dev.

What I mean by that is that the way we learned is that the old/wrong way (php style templates) mix front end and backend development, and data with formatting. It's better to have data available through rest APIs and then consume it from something. Which is mostly true if you plan on being available in a reasonable way from smartphone apps, etc. but of course that means that your website should also be a client capable of working as similarly as possible to a mobile app - there you go, SPAs.

We need to find a way to keep those benefits without the bulk of current SPAs. But SPAs appeared for a reason, and it would be wrong to ignore why it happened. Being able to have front and backend devs working in parallel is a benefit, being able to server your content to several frontends is a benefit, etc.

(And if you're thinking "these people don't need apps anyway", the reality is that clients demand to have them - even if it's only so they can bother users with push notifications or collect data, they do ask for them).

Re: Second-Guessing the Modern Web

#56

Post by cosmojg »

saagarjha wrote: post #27
fenwick67 wrote: post #24

Earlier quoted context omitted.

This is some spin mastery. "yes you're right, React is bad, we're continuing to work on it and make it even better"

I mean, what did you think he was going to say? React is bad, we're dropping it?

That's exactly what we wanted him to say. Use heavy tooling only where necessary and nowhere else. React is rarely necessary.

Re: Second-Guessing the Modern Web

#57

Post by Frost1x »

snazz wrote: post #44
caribousoup wrote: post #34

Earlier quoted context omitted.

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

I'm agreeing with you that the "modern web" is too complex, but the "make a folder and sync it to a Linux box" solution doesn't work very well for real-world use. It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.

>It's easier and a lot faster to sync your static site to something like S3 or Google Cloud Storage and serve it from there. Now you don't need to secure and update your Linux box or be responsible for its uptime.

I was pushing to *nix hosts I didn't have to manage in early 2000. Actually, one of them I recently remembered and had paid a small lifetime membership for limited static hosting (I've done absolutely nothing for 20 years at this specific host and it's working today. Yes, the content is fairly static and very simple (its 20 years old) but it's all there. It's a simple shared system and no it wouldn't scale out to support more than probably 10k simultaneous requests but its served its purpose over the years. No, there's no SLA. I'm not saying services like S3 haven't been able to improve on that older infrastructure but it goes to show what very simple systems are capable of.

I've not spent a second of time in 20 years worrying about security, someone else did for a very nominal fee. This isn't a new concept, now we have better scaling available for sure.

Re: Second-Guessing the Modern Web

#58

Post by Frondo »

caribousoup wrote: post #34
userbinator wrote: post #8

Either you omit some interactive elements on load, or you try really hard to make sure that the JavaScript loads faster than users will click, or you make some elements not require JavaScript to work - like making them normal links or forms. Or some combination of those. I realise I'm in the minority, but I use JS whitelisting, which means that any SPAs I come across in my web searches (a disturbingly large number, a…

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting like an old style website. People are just happy it works. And mobile testing was a breeze.

If I tried to build this on a "modern" stack I cannot imagine any benefit, only drawbacks.

Re: Second-Guessing the Modern Web

#59

Post by cosmojg »

Frondo wrote: post #58
caribousoup wrote: post #34

Earlier quoted context omitted.

I think modern web misery all stems from an industry problem. Everywhere I've worked, I have insisted on building things with basic semantic HTML, hand coded CSS, and vanilla JS where precisely needed. Nobody listens. You can make something that loads 50x-100x faster, works responsively on every device, has energy efficient rendering, and the UI/UX is dead simple to use and familiar to all people. And yet... at least…

Just chiming in to say this is an absolutely viable approach. I just built a project, over about six weeks, using mostly vanilla js and some jquery (the heaviest widget I have is tinymce, which is a necessity unfortunately), and started selling it about two weeks in. I'm up to $650 mrr and the sky's the limit (really, the market is huge and desperately underserved), and not one person has complained about it acting l…

Got a link? I'm curious what your end product looks like.

Re: Second-Guessing the Modern Web

#60

Post by mellow2020 »

saagarjha wrote: post #27
fenwick67 wrote: post #24

Earlier quoted context omitted.

This is some spin mastery. "yes you're right, React is bad, we're continuing to work on it and make it even better"

I mean, what did you think he was going to say? React is bad, we're dropping it?

"React is bad in your case, drop it." I know it's far out idea in tech, to flat out tell someone "you don't need this, you just save time and money and get a better result of you don't use what we made", but it shouldn't be.

React is fine per se, the problem is throwing these "simple, magic" solutions onto everything, without even caring what mountains of code end up running as a result. The minimum for a Discourse installation is 10 GB, for example, but PHP is the weird ecosystem, because reasons. I don't mean to pick on Discourse, but that's still crazy to me.

Post reply on HN