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

211–220 of 467 posts

Re: Second-Guessing the Modern Web

#211

Post by ako »

Polylactic_acid wrote: post #168
runawaybottle wrote: post #139

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…

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.

Re: Second-Guessing the Modern Web

#212

Post by flukus »

amw-zero wrote: post #45

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…

> Maybe Gmail is the best example of using the SPA experience to drive a rich UX.

Gmail is is the perfect example of an app that loses more functionality than it gains by being an SPA. Middle click to open an email in a new window doesn't work, if it was a normal web page that would have come for free. This is more important functionality to me than saving a page refresh. Same goes for JIRA, middle click at least works but the the 30+ seconds to reload the SPA in it's own tab makes it unusable.

These are both document driven apps and the document viewer I'm using them in have some great features that they cripple.

Re: Second-Guessing the Modern Web

#213

Post by pjmlp »

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 customers might have.

Re: Second-Guessing the Modern Web

#214

Post by grey-area »

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 people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time

The premise of the article is that they are not easier to work with and do not save time in most situations. I agree.

Most websites are fundamentally documents, even those that think of themselves as apps. You could even build gmail quite easily as a document based app with some limited use of fetch() or WebSockets to get the data you need, though it's one of the few applications where a less document based approach might help.

React and other js frameworks are a huge amount of overhead for very little gain if you see the web this way. Your about page is not improved by using react.

Re: Second-Guessing the Modern Web

#215

Post by aryehof »

PaulDavisThe1st wrote: post #161
runawaybottle wrote: post #139

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…

What do you consider "our industry" to be ? Software development? Web development? What used to be called "Application Development" back in the 1980s and early 1990s? I'm asking because there's a lot of software developers/engineers whose jobs don't feature any of the keywords in your comment ("Frontend", "Backend", "SQL queries", "modal" etc. etc.)

If all one has been exposed is a development world of web-based consumer-facing front-ends (CFUI), it is hard to imagine that the majority of software lies elsewhere. Hard to imagine that anything else is important. It leads to a viewpoint that modern programming is mainly about UI interacting with a database.

Re: Second-Guessing the Modern Web

#216

Post by _630w »

runawaybottle wrote: post #139

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…

At this point, I am convinced the problem is not web frameworks but browsers. Someone needs to take all the legacy bloat away and put it in the side while starting from the scratch. Web doesn't need three different languages. It doesn't need freedom that costs accessibility. It doesn't need to be so primitive.

It smells. Awful defaults.

import "reset.css"

import "reset.js"

Re: Second-Guessing the Modern Web

#217

Post by luckylion »

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.

And they do, even if it's not a conscious decision. Most large scale experiments see bounce rate increase and revenue decrease with page load time. More load time because "it's easier to develop this way and it saves developer time, which is expensive" means more bounces and less sales.

Of course, that only matters at scale. If your site never takes off, optimizing for user experience (instead of developer experience) wouldn't have paid off. On the other hand, maybe putting your users second lowers the chance of it being well received.

Re: Second-Guessing the Modern Web

#218

Post by goatlover »

mmis1000 wrote: post #202
commandlinefan wrote: post #121

Earlier quoted context omitted.

> 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?

Because Rails, Symphony, Django, Phoenix or whatever does the job in the preferred language of the developer/team and often has more batteries or better tooling included.

Re: Second-Guessing the Modern Web

#219

Post by luckylion »

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…

> Developers like simple sites like Hacker News. Nobody else does.

People like Google.

I'm convinced that users don't care for most "design" and "clever layout". Site owners do, but users don't. Which is understandable, you want your site to stand out so you make it special. Users usually don't want special, they don't want to think, they don't want to figure out where they need to hover for functionality to reveal itself etc. I do believe that users would be much happier if layout/design possibilities would be much more restricted, like they are on mobile, because there's no constant re-learning there.

The problem is that designers and developers need to get site owners on board, so they are selling to site owners.

Re: Second-Guessing the Modern Web

#220

Post by noahtallen »

systemvoltage wrote: post #54
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…

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 fuck anything up by clicking “reply” once more? This is an easy trap for a user to fall into.) The second back will take me back to the post comments. Which is weird, because this is where I was taken after posting the comment. The third back will take me back to HN homepage. I expect to go back to the homepage on the first back click.

And this nav stack works as it does because HN uses plain HTML forms without any “overkill” JS. But the reality is that the default back behavior doesn’t really fit most user expectations, because most people don’t understand that clicking each of these buttons added more and more to the stack. Most people don’t know what a stack is! :) I think this is a great example of why the default document behavior of the web doesn’t really match most people’s user expectations, and the normal form behavior on the web makes it way to easy to do the wrong thing, like re-submit information.

Post reply on HN