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

241–250 of 467 posts

Re: Second-Guessing the Modern Web

#241

Post by okareaman »

ng12 wrote: post #224
okareaman wrote: post #50

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…

That's not why hooks were invented. Hooks are by definition component local.

I'm not a React expert, but I wonder how do you interpret this by Dan Abramov? This is where I got my information about hooks before trying them out:

React doesn’t offer a way to “attach” reusable behavior to a component (for example, connecting it to a store). If you’ve worked with React for a while, you may be familiar with patterns like render props and higher-order components that try to solve this. But these patterns require you to restructure your components when you use them, which can be cumbersome and make code harder to follow. If you look at a typical React application in React DevTools, you will likely find a “wrapper hell” of components surrounded by layers of providers, consumers, higher-order components, render props, and other abstractions. While we could filter them out in DevTools, this points to a deeper underlying problem: React needs a better primitive for sharing stateful logic.

https://reactjs.org/docs/hooks-intro.html

Re: Second-Guessing the Modern Web

#242

Post by Nextgrid »

ako wrote: post #211
Polylactic_acid wrote: post #168

Earlier quoted context omitted.

The alternative is just having premade components lazily glued together. It seems that the markets have decided that highly polished custom tools are worth the cost.

Low code and no-code markets are growing rapidly, so don't be sure the markets have decided.

"Growth" != profit. I can sell $10 bills for $1 and grow rapidly too, doesn't mean I will ever become profitable.

Are these low/no-code providers actually making profits, or is it a temporary fad and eventually 1) the market will re-adjust and these no-code tools will become more expensive to sustain themselves, bringing up the cost of a no-code app and/or 2) users of these tools will realise their limitations and eventually word will get out that you end up spending twice as much with no-code than doing "code" to begin with?

Re: Second-Guessing the Modern Web

#243

Post by int_19h »

dbmikus wrote: post #190
MattyRad wrote: post #176

Earlier quoted context omitted.

I think you're bordering on a contentious idea that I will take a step further. I would argue that frontend, nearly in its entirety , is effectively one giant bike-shed operation. And like you're alluding to, it's an operation that exists mostly because there is money to burn. At best , frontend exists to save backend engineers the trouble of dealing with the tedium of HTML/CSS. As an example, the article brought up…

I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * sear…

It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD.

Every attempt so far produced many technologies that died very fast, and a few (e.g. SQL) that survived long enough to become a natural and useful part of the landscape - but even that part still requires programmers to tend to it. When non-programmers try to use that tooling, the result rarely works well; and in those few cases when it does, it's rarely maintainable anyway.

Re: Second-Guessing the Modern Web

#244

Post by goatinaboat »

MattGaiser wrote: post #156
userbinator wrote: post #113

Earlier quoted context omitted.

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a user and developer myself, that's the sort of selfish attitude that really really angers your users. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answ…

> As a user and developer myself, that's the sort of selfish attitude that really really angers your users. A user is only unhappy if they withhold some money over it.

A user is only unhappy if they withhold some money over it.

Yes and no. If you are selling to the CFO on the golf course, then you get paid and all the actual users are unhappy. This is the entire ERP industry.

Re: Second-Guessing the Modern Web

#245

Post by compressedgas »

wrnr wrote: post #3

> If Wikipedia were started today, it’d be React. Maybe? No, I'm building a hard fork of wikipedia and I'm using Go to render the pages on the server side and a vanilla JS for a user friendly the rich text editor. I don't know why not more people use WebComponents as a light weight alternative to React/Vue/Angular. It was natural choice in my case because it grew out of the desire to keep the tech stack small. For no…

Is that a replacement for mediawiki or an actual a fork of wikipedia?

Re: Second-Guessing the Modern Web

#246

Post by int_19h »

pjmlp wrote: post #213
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 have been developing all sorts of native and Web applications for a couple of decades now, and SPAs is something I avoid as much as possible. And yes, I also implemented interactive desktop like applications as Web applications. Server side rendering frameworks, with support for components and just enough JavaScript go a very long way, and best of all, they are faster than SPAs in every kind of device that customer…

Speaking as a user, I generally prefer non-SPA web apps as well. They're much more predictable.

Re: Second-Guessing the Modern Web

#247

Post by jimbob45 »

int_19h wrote: post #243
dbmikus wrote: post #190

Earlier quoted context omitted.

I'm actually more of the opinion that a lot of backend is bikeshedding! Branding and UI/UX design are very important for emotionally influencing a customer's opinion or improving their user experience with your product. On the backend, how often are the any different than some cross set of options from: * synchronous CRUD * async data flow * bidirectional realtime messaging (message in the "data packet" sense) * sear…

It seems that each generation of programmers at some point comes to this epiphany that a lot of things that they're doing are repetitive enough that they ought to be doable by non-programmers, if you just come up with a way to glue those common things together easily. That was the story behind "4th generation" programming languages, for example; and to some extent, behind RAD. Every attempt so far produced many techn…

RAD died because it could only cover 98% of business needs and idiot managers thought they needed a language to deal with 100% and so threw away really great tools.

I could fully foresee VB making a comeback in the future.

Re: Second-Guessing the Modern Web

#248

Post by TeMPOraL »

pvg wrote: post #174
userbinator wrote: post #113

Earlier quoted context omitted.

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a user and developer myself, that's the sort of selfish attitude that really really angers your users. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answ…

zero need of JS XHR was invented because without it, Microsoft couldn't make a web-based email client that behaved the way users expected an email client to behave. 20 years ago. I'm not sure you can reasonably claim this stuff is not also strongly driven by the expectations of users and and the desire to meet those expectations.

I'd like to know which users desired a web-based e-mail client 20 years ago. It is my impression that this kind of software is very much push, not pull - i.e. the idea comes from the vendor, not from customers expressing a demand. Which is not a bad thing in itself (a big part of progress is speculative creation); I just don't like the unspoken assumption that companies do things because customers want them to, it's not always true (almost never in B2C).

Re: Second-Guessing the Modern Web

#249

Post by TeMPOraL »

onion2k wrote: post #238
userbinator wrote: post #113

Earlier quoted context omitted.

It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a user and developer myself, that's the sort of selfish attitude that really really angers your users. I sometimes wonder if the people claiming to hate client-side technologies or disable JS in their browsers have actually ever had to build a complex website to put food on their table. My bet is the answ…

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.

Re: Second-Guessing the Modern Web

#250

Post by int_19h »

noahtallen wrote: post #220
systemvoltage wrote: post #54

Earlier quoted context omitted.

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? It is REST-ful and static. To be completely honest, this is one of my least favorite things about HN. As I write this comment and click reply, if I wish to navigate “back” after I post this comment, the first back button click with take me to this still-filled comment form. (Will I…

> Will I fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into

Have you tried clicking "Reply" once more after going back? If not, do try.

Post reply on HN