Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

141–150 of 467 posts

Re: Second-Guessing the Modern Web

#141
post #104

Earlier quoted context omitted.

This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is. But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package. Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to s…

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.

Doing things with react is mutually exclusive with SPAs. You could even do a purely server-rendered website using react on the server if you wanted to, and all the benefits of functional component design can still be utilized.

Re: Second-Guessing the Modern Web

#142

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…

100% agree.

KISS - Keep It Simple, Stupid - Never let me down.

Re: Second-Guessing the Modern Web

#143
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.…

You suggest React is at once both "easier to work with"; and "largely more complex" and "gatekeeping" (harder to learn?). Aren't those opposites?

Re: Second-Guessing the Modern Web

#144
post #91

Earlier quoted context omitted.

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 app…

>it's simply not possible to avoid re-rendering the entire page without using XHR Wrong on two separate levels. First up, technologies like iframes , frames , and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever. Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+…

> First up, technologies like iframes, frames, and objects/embeds allow that just fine; you can use at least some of them without any JS whatsoever.

Thats complete BS, Iframes are just loading other HTML pages so you still need another tech to allow for static HTML to re-render itself. If your just talking about some kind iframe jacking then I don't see how thats remotely relevant.

Objects/Embeds? Sure you don't need javascript to make a page interactive if you have things like Flash/Silverlight/UnityWeb where your just executing through a completely foreign API usually via a plugin.

> Secondly, with avoiding re-rendering you end up avoiding a 200ms ... 500ms load+render of simple full page, at the cost of doing 2...5 seconds of gradual load+render of various bits and pieces. Bits and pieces that often are so unwieldy they cause widgets & content to load gradually, jump around, and sometimes even get hidden behind a loader. While the CPU fan keeps whining at full revs.

Maybe if your using something older than sandy bridge trying to use facebook I guess but outside of these kind of silly edge cases, ive rarely seen an iphone/macbook/desktop from the last 5 years spend more than half a second on any kind of heavy redrawing logic ever.

> The solution became worse than the problem it purported to solve, and your users pay the price in wasted time + RAM + electricity.

Then they can use another app website without JS that does all these features they want but with Iframes and flash.

Re: Second-Guessing the Modern Web

#145
post #115

Earlier quoted context omitted.

> they're easier to work with and they save us time. I have never seen evidence of this. Its a lie developers frequently mention because it sounds so thrilling to say. Approximately how much time does it save you in estimated hours? Its like asking for a helicopter to take me to work, because supposedly its faster. I'm simply assuming its faster without looking at any numbers or finances.

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…

> It's saved me hundreds of hours, if not more.

How did you come up with that? You tracked the time it took to complete the project with and without React and diffed it?

Re: Second-Guessing the Modern Web

#146
post #65

Earlier quoted context omitted.

You are contradicting yourself by opening with a claim of time savings and ease of use followed by admitting that the solution is largely more complex. More complex work does not save time in aggregate and is not easier to use.

The solution is not more complex to the developer or user, it's more complex to the browser , which hardly ever complains when you make it work harder :-)

Users could complain when someone makes their browsers work harder. Looking around the net, they mostly don't. I don't know. The only time I developed a serious full SPA, I intended to use it myself on a $50 phone, so I actually kept complaining to myself until it started loading in reasonable time and working instantly after that.

Re: Second-Guessing the Modern Web

#147
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…

A lot things can be easier if you do things the "wrong way". App development can be faster if you don't use Typescript, liberally use the "any" type, or just avoid. Most of recent javascript tech like React, Redux, Typescript, et all, came to reign in the multi-paradigm language that is Javascript so that larger organizations can actually make maintainable error free code from a language and ecosystem that is very easy to shoot yourself in the foot in from junior developers.

Sure, you just do some javascript and HTML to get your thing working quickly, but that hasn't even been recommended since the days of Jquery (where it was recommended over just doing vanilla JS in order to maintain cross-browser compatibility).

It depends on your setup and use cases whether or not something is overkill, but for any reasonably large app just doing some HTML and javascript is not going to be enough to keep things maintainable, and that's before even considering things like browser compatibility, accessibility concerns, localization/internationalization, etc. A simple app or product does not mean the internals are necessarily simple.

Re: Second-Guessing the Modern Web

#148

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.

As someone who uses React/Mithril and has just been hired to work mostly on jQuery, you obviously haven't had to build something more complicated than a wordpress blog.

Re: Second-Guessing the Modern Web

#149

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…

And yet, unlike newspapers with an in house advertising staff. All web adverts are 3rd party. That are easily blocked. Google laughs to the bank everyday it killed old advertising.

Re: Second-Guessing the Modern Web

#150
post #104

Earlier quoted context omitted.

This is what I meant by gatekeeping; there is common misconception that you have to go looking for a library to solve a problem. And it makes it seem like there's a higher barrier to entry than there is. But the reality is that React is plain HTML and Javascript, in a less error-prone and maintainable package. Everything you can do with vanilla JS you can do in React, but with React you benefit from being forced to s…

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 and it's why I'm skeptical of saying SPA's are bad. To me they make my life easier and are very flexible.
Post reply on HN