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

231–240 of 467 posts

Re: Second-Guessing the Modern Web

#231

Post by unclebucknasty »

_630w wrote: post #216
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"

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, why do we just keep forcing it? If leveraging the ubiquity of the Web is the objective, then there's nothing to say we couldn't have a VM running in a browser that itself uses web protocols/languages, but abstracts them away. That would leave us writing code a la Swing, an event-driven, component-based model that makes so much more sense for a GUI style application. No CSS, HTML, fighting back-buttons, state management, routing, etc. That's all handled in the VM.

Re: Second-Guessing the Modern Web

#232

Post by TeMPOraL »

groestl wrote: post #228
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 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.

> the process has a tendency to self correct over time - creative destruction and all that

I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.

Re: Second-Guessing the Modern Web

#233

Post by ssijak »

babaganoosh89 wrote: post #39
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

I think a lot of the problem is React's syntax and ecosystem is too complicated for the majority of sites out there. IMO using React to make static sites and regular CMS / document type sites is way overkill no matter how performance optimized it is. I've been experimenting with Vue and I'm liking it more and more just for the simplicity.

Ract syntax is functions + jsx. Jsx has just a smal set of additional rules compared to ordinary html, so I would not call it complex. In Vue 2 you have directives and wierd object model where you store data, getteres, watchers, etc. Each library has its own set of things which needs to be learned, and for me both basic vue and react are easy.

Re: Second-Guessing the Modern Web

#234

Post by tiborsaas »

MattyRad wrote: post #176
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…

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…

Don't be shy, go that last extra mile and just say that frontend engineers are fraud.

Re: Second-Guessing the Modern Web

#235

Post by searchableguy »

TeMPOraL wrote: post #232
groestl wrote: post #228

Earlier quoted context omitted.

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.

> the process has a tendency to self correct over time - creative destruction and all that I wonder how long it takes for the correction to kick in, because for the last decade+, software seems to be getting worse and worse - slower, bloatier, less functional, and with more user-hostile business models.

Just look around your government systems. They have had decades to fix themselves but are they fixed yet? Are they faster, less bloatier, less user hostile and privacy invasive?

Re: Second-Guessing the Modern Web

#236

Post by compressedgas »

echelon wrote: post #6

HTML should never have grown into the mutated application runtime it is today. The presentational concerns for documents are different from application rendering. The javascript stack should have been something entirely separate. I strongly feel we should create a lightweight HTML fork that is again document-centric and doesn't allow for all of this javascript nonsense. Something that doesn't allow for stupid custom…

What you want is for web authors to follow progressive enhancement. No JS should be required to load the contents of the page. If JS is included it should be to replace what would otherwise require a full page reload.

Re: Second-Guessing the Modern Web

#237

Post by grey-area »

amw-zero wrote: post #52
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…

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…

You don't need an SPA to use XHR, and your description of the SPA experience for the end user is a fantasy - there's a reason pretty progress bars are popular in SPAs, and it's not because of fast state changes, quite the reverse.

Re: Second-Guessing the Modern Web

#238

Post by onion2k »

userbinator wrote: post #113
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.…

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?

Re: Second-Guessing the Modern Web

#239

Post by withinboredom »

Polylactic_acid wrote: post #170
theonething wrote: post #137

Earlier quoted context omitted.

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.

It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.

It literally does, unless you have the form POST or GET to an API directly + a redirect from the API.

You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because they validate on the client.

Re: Second-Guessing the Modern Web

#240

Post by grey-area »

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?

That problem was solved approx 20 years ago.

The alternatives are not react and templates vs writing html by hand.

Post reply on HN