Live data from Hacker News

Second-Guessing the Modern Web

macwright.org

221–230 of 467 posts

Re: Second-Guessing the Modern Web

#221

Earlier quoted context omitted.

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.

I'd say you have to group business-facing front ends with consumer-facing front ends, as well as big chunk of mobile development, because all of these are done by the same people from the same programming culture, with the same technologies, patterns and ways of thinking.

And with that, I'd argue this is majority of software.

Re: Second-Guessing the Modern Web

#222

Earlier quoted context omitted.

Except for the user, who never asked for vanity animations and hate the popups.

Wrong. I ask for it as a consumer. I expect it, and I demand it. We're in 2020, I don't want to click around on hyperlinks - I'm sorry. I grew up in a world of interactivity and the iPhone. My bar is very high for consumer services. Animations and smooth transitions are table-stakes.

Surely you also grew up in a world of web browsers and hyperlinks. They haven't gone anywhere. There's just more applications on the web now in addition to traditional websites and hybrids. When I use the browser on my phone, I'm usually touching hyperlinks to go to different sites and pages, and often those hyperlinks are shared on different apps.

Re: Second-Guessing the Modern Web

#223
post #94

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've often said that web development has a big culture problem. In any other field, 'modern' is the opposite of a selling point. People want tools that work, that are proven and have years of stability and momentum. But in web development, there is an obsession with the new and shiny. It's 100% about the developer's own experience in creating a program and 0% about the user's experience actually using the half baked…

Is that really true?

On the backend, shiny technologies like Go have been exploding — Go modules only stabilized this year! Since React was released, we’ve gone through through at least two new ways of deploying a server — containers and serverless, replete with their own huge abstraction layers like Kubernetes — and we’ve moved from monoliths to microservices and back again. And in native land, the “Rewrite It in Rust” crew is doing their best to bring the new and shiny to systems programming.

I agree that frontend web developers are maybe a bit too enamored with new tools. But I don’t think that mindset is unique to them, at all; they just happen to be the most numerous and visible examples.

Re: Second-Guessing the Modern Web

#224

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.

Re: Second-Guessing the Modern Web

#225
post #186

Earlier quoted context omitted.

Maybe we are? Suggesting the whole world stop doing this is silly bud

> Maybe we are https://adhdawarenessmonth.org/everyone-has-little-adhd/ An ADHD diagnosis is not purely based off of exhibiting behaviors typically associated with it. While everyone is forgetful/distracted sometimes, ADHDers have a physical/chemical difference in their brain which make such behaviors impossible to avoid. > Suggesting the whole world stop doing this is silly One person at a time

Just wanted to say that I don't think this is a silly pursuit, and I'm sure plenty of other people reading feel the same way. I think this is a serious issue because the language we use is related to how we act and treat each other, and talking about the issue has a real effect.

Reminds me of the quote attributed to Margaret Mead, whom I actually don't know anything about besides the quote: "Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it's the only thing that ever has." Too corny? Idk. I like it

Re: Second-Guessing the Modern Web

#226

Earlier quoted context omitted.

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.

I think there's a strong overtone of that in many places, including in business and popular culture. Most peoples' interactions with software are phone apps and web fluff.

Re: Second-Guessing the Modern Web

#227

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…

>Over the next 10 years I think we're going to see more and more codeless SaaS services

Maybe it will finally happen, but some variation of this has been the holy grail for a lot of years now.

I read an article a while back that talked about how many times developers have implemented the same thing in different ways at different companies; for instance payment processing. And it's true. But, you have companies like Stripe and Braintree. Now, there's even a SaaS subscription management SaaS businesses that sit above these (I don't recall any names).

But these just become other things to which we have to integrate. Now the task has moved, but we still have to build the connections and implement all of the business rules that go around that. I guess my point is that with every business having different logic, processes, models, etc it becomes very difficult to have some generic tool that allows a codeless solution to all of these problems. It's not the individual components like those you listed that cause the complexity. It's the way they are wired together and the underlying rules. So, while it seems inefficient to keep building these things, I think it is reductionist to say "well, it's only another CRUD app" or whatever.

Sure, tools can make things easier, but they make things easier for everyone. So now the bar is raised in terms of what you must do over and above that baseline in order to win.

Maybe a good analogy is that back in the day everything was written in assembly. High level languages came along and made it easier to do more faster. But then the complexity of software and the demands on it also increased, so in a similar fashion it just moved the problem.

Re: Second-Guessing the Modern Web

#228

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 might be possible that product development itself is the actual bike shedding, and all the frontend, backend and product devs help the product owner realize that ;) However, you can't know in advance, yet the process has a tendency to self correct over time - creative destruction and all that.

Re: Second-Guessing the Modern Web

#229

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. My experience is quite the opposite. I still use Gmail's "Basic HTML" UI, and it takes less time for me to click a link and load a new page on that UI than any interaction on the default UI.

I use a regular mail client on my computers and phone, and don't touch webmail with a ten foot pole. Google did it best, but it's still junk.

Re: Second-Guessing the Modern Web

#230

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.

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.

You probably meant "orthogonal" (a smarter-sounding way of saying "perpendicular", in the sense of "linearly independent"). A framework made and used primarily for doing SPAs can't be "mutually exclusive" with doing SPAs.
Post reply on HN