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

271–280 of 467 posts

Re: Second-Guessing the Modern Web

#271

Post by 29athrowaway »

The modern web should be rebooted:

- Browsers are a privacy mess. Users are left exposed to blatant fingerprinting, tracking across websites, etc.

- Instead of JavaScript as first class language, use WebAssembly or a similar language as a first class language. Developers may continue to use JavaScript if they prefer, but the code they deploy should be WebAssembly.

- Instead of HTML and CSS, browsers should use a binary representation of a document. Developers may continue to use HTML and CSS, but what they deploy is this new binary format, not HTML and CSS. That would make documents more compact and render faster. And, this makes it possible to replace HTML and CSS with something else.

Re: Second-Guessing the Modern Web

#272

Post by searchableguy »

worble wrote: post #253
unclebucknasty wrote: post #231

Earlier quoted context omitted.

I'll take it a step further and say we shouldn't be using the Web paradigm at all. We've tried a million different ways now to essentially generate HTML. So many frameworks. So many libraries. Front end. Back end. Etc. But, we're still working within the paradigm of the stateless Web, designed to display documents and images. Trying to hammer an application in there (especially a SPA) really doesn't make sense. So, w…

I'm personally curious how far we could go with using just canvas and wasm. If we focused on making a browser that was just incredibly efficient and focused at using wasm and webgl, and had no other concerns, a lot of the cruft could be cut. Then any given "page" would essentially just expose the canvas for wasm to draw to, and GUI frameworks like Qt (which already can compile to wasm I believe) could just target thi…

We should embrace flash again - https://github.com/ruffle-rs/ruffle

Re: Second-Guessing the Modern Web

#273

Post by dgellow »

acemarke wrote: post #13

Dan Abramov put up a tweet thread agreeing with this piece, and talking about how the React team is now looking at trying to come up with some server integration capabilities to enable a hybrid model for the rest of the community: https://twitter.com/dan_abramov/status/1259614150386425858

Server side rendering is a thing since React has been announced.

https://reactjs.org/docs/react-dom-server.html

Re: Second-Guessing the Modern Web

#274

Post by arvinsim »

burlesona wrote: post #72
luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…

> Also the fact that the solutions don’t work very well means they’re constantly being reinvented, which means if you do the work to keep up with it all you’re rewarded by being regarded as an expert, which is nice.

This is a huge assumption. For example, I don't think any web dev enjoys wrangling with CSS positioning or workarounds because they want to be "rewarded by keeping up".

> Last year I assigned a feature to a junior dev which was quite simple. He spent two days hunting for and testing React libraries to try and build it. When he told me this I said, “Holy crap, that is overkill.” I tried to explain how easy this would be with just plain HTML and JavaScript and he didn’t understand, so we paired for about 90 minutes and the work was done.

I don't know what your feature is. But any decent web dev today has to think of multiple angles that are not present in non-frontend development

- Responsiveness

- Browser support

- Accessibility

- Internationalization

That is in addition to testing, error logging, analytics, etc. We haven't even gone to the business logic yet.

Many people underestimate how much work a good web app entails

Re: Second-Guessing the Modern Web

#275

Post by rjknight »

commandlinefan wrote: post #118
luxphl wrote: post #47

I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…

I’ve never used React, but I spent years fighting with Angular, and it seemed like all downside with no upside - I kept expecting the upside to become apparent eventually, but it never materialized... it just made site development take longer, crash more mysteriously, and run slower. Is React really “better” than Angular? That is, does it actually do anything?

In my opinion, yes.

Angular's model is based on "two-way data binding", which was also the paradigm used by Backbone and other popular JS frameworks of a ~decade ago. This means that any user interaction with your app directly causes some JavaScript value to change, potentially triggering side-effects. But you can also cause the same value to change in your business logic code, in response to some other event or change. Components maintain a lot of data internally, so your job as a developer is largely about making sure that these components stay in sync with each other, and with whatever non-component-oriented data you have.

This gets messy very quickly. Where is your data? What things can cause your data to change? What happens if you want to change a data schema, or introduce new fields, new components? Angular tries to solve this problem with a fairly complex architecture[1] which promises that all of this can be OK if you follow the rules.

The problem is that this architecture is so complex that most people can't follow it well: there are modules, components, views, directives, services, dependency injection containers, service metadata, bindings, a router, and events. That's ten concepts, and you can't build very much in Angular without knowing what those concepts are and how they relate to each other (and if you can build it without knowing these things, then you didn't need Angular).

React is much simpler: there is state, and there are views. State can be global or component-local, and I would suggest ignoring component-local state unless you can't avoid it. Views render whatever state is passed to them. State can be updated by events. This is the same basic loop that is recognisable in desktop apps, games, in fact most interactive software. There's no "two-way binding" because views render based on state, but can't modify it directly. This is a lot easier to understand and to debug.

React might be less "batteries included" than Angular, but Angular requires such an enormous battery pack because it is trying to solve problems in an insanely complicated way.

[1] https://angular.io/guide/architecture

Re: Second-Guessing the Modern Web

#276

Post by arvinsim »

theonething wrote: post #137
mgummelt wrote: post #130

Earlier quoted context omitted.

React still requires you to write HTML and forms.

And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.

> And it makes it harder to do so. I hate doing forms in React. You basically have to reinvent the plumbing that's already standard with the HTML spec. Very tedious.

Show me the HTML standard that supports SPA submissions that don't reload the page.

It seems that your problem is about SPAs, not React.

Re: Second-Guessing the Modern Web

#278

Post by onion2k »

TeMPOraL wrote: post #249
onion2k wrote: post #238

Earlier quoted context omitted.

and don't even need to think about "browser support" because it'll be usable with anything from the past two decades Not including a patchy or high latency internet connection though, right?

I'd say especially including these; plain, old, JS-independent, server-rendered sites handle these conditions much better than modern SPAs.

I don't agree. A classic PHP-as-it-was-used-15-years-ago site either loads or fails for every user request. That isn't good enough any more. An SPA either loads or fails for the first request, but then they do a lot of things that can mitigate a patchy internet connection - prefetching content, offline mode, bundling things to reduce the number requests, etc. A server-side rendered app doesn't take advantage of those optimisations, although things like rel="prefetch" are starting to get used more which helps a lot.

Like the article suggests, there's definitely some middle ground where enough of the site is loaded on the first request for it to work, and then more things can happen in the background to make subsequent interactions faster and more reliable. That isn't a pure SPA and it isn't a pure SSR site either.

Re: Second-Guessing the Modern Web

#280

Post by arvinsim »

chipotle_coyote wrote: post #183
luxphl wrote: post #115

Earlier quoted context omitted.

I truly do not think it's a lie. Not sure why you think it's a thrill. It's saved me hundreds of hours, if not more. It's certainly faster to use jQuery to change a CSS attribute than it is to setup a React project but what's not considered in that calculation is maintaining the state of that attribute or making changes to the logic in the future. Especially on code you didn't write originally. If all you have to do…

I think the problem/frustration is simply this: there are a lot of web sites out there that are, well, web sites, not web applications. Looking back at the linked article, it goes out of its way to talk about many ways that React is "pretty great" and "for a particular scope of use cases it's the best tool you can find," but then goes on: > There are a lot of problems for which I can't see any concrete benefit to usi…

Serious question:

Is this really a problem with web developers? Or is it with product managers who demand SPA like behavior?

Post reply on HN