Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

201–210 of 467 posts

Re: Second-Guessing the Modern Web

#201

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…

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…

> 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

Designer hate it

Re: Second-Guessing the Modern Web

#202

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…

> loads 50x-100x faster And takes less time to develop in the first place! These frameworks just seem like pure overhead to me.

You end up dupe your layout page everywhere and have a hard time update all of them if designer changed their mind.

Or you could use some template system to do that… but if you need to use template, why not use react(or something like that) anyway?

Re: Second-Guessing the Modern Web

#203

I’m tempted to step back and evaluate this on another level. Our industry is very big, and any industry that gets that big will be able to house a lot of people just for the sake of it. If you think we have a large amount of fresh frontend people, understand they are hired almost with a one to one correspondence with fresh product/business people. Modern product development is essentially a polishing job on every com…

Since 2013 my work has generally consisted of applications that run in the browser, right now I'm working on the first normal website I've worked on in 7 years. And I agree this is a bunch of little polishing jobs.

I do say to myself what's the right solution here, but I know for business reasons I am not allowed to do the right solution.

Re: Second-Guessing the Modern Web

#204
Just one thing. How do you reuse components on client and server side and at the same time keep the component encapsulated. For example I don't want my component to have a bit of php, a bit of JavaScript and then couple my JavaScript to the class that php gives me. This is a huge hack. If you have 2 states, they have to be both on JavaScript and php land... Not a waste?

React solves this huge problem.

Re: Second-Guessing the Modern Web

#205
A lot of the comments here are missing two key points:

1. Google and Facebook have created really high-standards for what's considered a usable web application 2. HTML is still a language highly optimized for creating static documents, not building the reactive applications most devs want to build

I think experienced developers might even deliberately ignore how much of a moat these two facts create for big companies (because it serves their interest as well).

Think about it: if styling/designing/building a web app like Google Docs was easy, do you really think Google would be able to maintain its lead in every vertical in that market for so long? Sure, maybe for some use cases it's the best solution — but what about lawyers or doctors: they could certainly use a custom version of a real-time document-editing app.

But, by keeping web development hard (i.e. split into a million different technologies that have trouble connecting with each other), Google and Facebook have enough breathing room to be able to create THE real-time work platform and THE social network, without worrying too much about competition sneaking up behind them.

And, if some small startup does manage to get off the ground despite the incredible engineering effort required, Google can just copy or acquire them with some of the billions they've made from their technology moat — and voila, as an extra bonus — all the devs who work at that acquired startup are already trained in the specific framework that Google and Facebook uses (oh yeah... that's why they open sourced it in the first place...).

By creating this huge moat between what's a "good enough" real-time web application in the eyes of most users (who expect instant updates, smooth transitions, collaborative features, and interoperability by default) and what most developers can pull off in a few months, these big companies can ensure they stay on top and not too many competitors arise.

And why don't developers fight back against this? Because this moat benefits us as well. It artificially inflates our salaries by making web development a super complex field. Not only do you have to know a lot of technologies and all of their secrets settings, you also need to know how everything fits together behind the scenes.

Can you imagine if web development was as simple as learning a single language? We'd all be making far less money by tomorrow.

All these moving pieces and arcane knowledge gives us pride in knowing something other people done, while making it extra hard to be a new developer. It also protects our employers from being disrupted every 2 weeks, giving some economic stability to the tech market at large.

Another benefit it provides to those already in power is an easy way to control who the next breakthrough success: if you're running a startup that's competing (even tangentially) with Google or Facebook or the thousands of other entrenched players, you'll need a million dollars just to catch up to them in terms of creating a usable product. People aren't going to be impressed with your photo sharing app if its interface isn't as sleek as Facebook's or Instagram's.

What's the solution to all this? The no-code movement? Perhaps low code?

Nah — those are patches in a sinking ship. The fundamental fact is: the web wasn't made for building dynamic web applications (and web components aren't actually simplifying the process).

Think about this: your browser doesn't even know what a "user" is or how to connect to a database or what a SPA is. And how long have we been building these things over and over again? It's absurd there aren't standard APIs for all of it...

But that would destroy the moat.

I think the true solution is a next gen version of HTML that abstracts away and standardizes everything difficult about building a web app.

Devs need to be able to focus on just building awesome products that serve a need — not configuring Webpack and getting a 5 year degree in CSS before even getting started.

It's too bad Google owns the most popular web browser (that could actually make a difference in this fight) and Facebook has convinced every developer I know that they've solved web development. It'll be their self-created competitive advantage until all developers simultaneously go crazy from having to re-implement the same damn architecture again for the thousandth time.

Re: Second-Guessing the Modern Web

#206

We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application. Some applications r…

Eventually a document web might become interactive. For example you start with something basic, now you want to show some animations. For example in geometry visualization.

Sometimes you just need something dynamic. I need it in 99pc of my websites. Why would I start with plain js, and then move to react. Plus I already have a base in react that can be shared with all websites. Much easier to maintain all in react than a mix

Re: Second-Guessing the Modern Web

#207

We should create a better division in web standards between the "document web" and the "application web." I think there are valid use cases to both, and we shouldn't rule out either. Wikipedia has to be the greatest realization of the initial spirit of the web: an endless interconnected network of articles of varying topics. That's a real use case, but it's not the use case of _every_ application. Some applications r…

> We should create a better division in web standards between the "document web" and the "application web." Why are those the only two options? By those terms do mean "document web" as HTML without any JavaScript and "application web" as HTML with any JavaScript, or something else?

"Why stop at two" is an excellent question, but the first cleave is the heaviest lift.

I think the first seam should be network requests. Unwind AJAX: produce the "content web" and the "interactive web." The content web should be HTML with JavaScript that can respond to events, but cannot fetch new code. This sterilizes the malware aspect of the web: JS can no longer track you (it can in crafty ways but ad blockers are a match for these).

The second seam should be aimed at the other direction: empowering the web. Factor out the "app web." This provides a native-level API which can dispense with the anti-fingerprinting, second-guessing nonsense. But the app web has higher barriers: revocable certs, user reviews, potentially frictive installs.

Re: Second-Guessing the Modern Web

#208

React is a great example of YAGNI and premature optimization. I'm sure Facebook benefits from it, but most websites don't need it. JSX is an abstraction encouraging deeply nested components, which makes state handling hard, necessitating the invention of React Hooks. "Controlling complexity is the essence of computer programming" -- Brian Kernighan. I see a celebration of complexity in modern website development and…

[deleted]

Re: Second-Guessing the Modern Web

#209
React, Redux, Webpack, 90% line coverage testing requirements...

I understand intellectually, sort of, kind of, often not really..., why those things came to be... but for fuck's sake, they have really sucked the joy out of my web development.

It feels so much more free and fun to just sit down and hack some vanilla HTML/CSS/JS.

The modern web development stack has attained "bondage and discipline" levels rivaling those old Java enterprise edition stereotypes.

Re: Second-Guessing the Modern Web

#210
post #150

Earlier quoted context omitted.

As a sibling comment notes, and as I noted in a reply to the OP, I agree with you that working with components is a nice approach and very useful. Using React as you describe is perfectly fine. The SPA craze where everything has to be done via React components is where we've jumped the shark IMO.

That's fair. I have an app that is rendered server side (Node.js/Express) and the frontend is built with jQuery. Made sense at the time. But I ended up adding two very interactive modules and decided React was best for them and added it in piecemeal, and I was right. But now trying to integrate the new features with the older ones, I wish I started with React for everything. This happens more frequently than I'd like…

Currently the site I'm building is a pretty static site of about 30-50 pages that is just brochureware for a non-profit scientific organization, on one hand I feel sort of embarrassed because it feels like I'm back in 2004 and I have a hard time justifying my salary for something like this, on the other hand I'm really super embarrassed at making the wrong solution because a React SPA with a service worker has been ordained as the way to make this thing.
Post reply on HN