[zaro]

But what should we do when things are actually complex?

There is a lot of negativity here on HN on the same things you mentioned, but I fail to see any viable alternatives.

Like what? Replace the MB of JS with plain Html and forms? It's not going to be simpler to code, and it's definitely not going to be simpler for the users. Or maybe use a native desktop app? Then it's even more complicated for the users, and coding it leads you in world of cross platform pain. And the closest thing there was to not using MB of Javascript and have decent UX was Java and applets/jlnp, but it somehow didn't manage to be widely adopted.

[blackflame7000]

Shot in the dark here, but perhaps you could try leaving the functionality the same and just try taking out all that code that tracks every pixel the user looks at, for how long, and how they can better market porn to that user...seems like that stuff could be taken out...

[larzang]

What programmer wants to add those things? Ads have been the bane of the internet for 20 years, how many times has a developer excitedly clamored to ruin their performance metrics, layout, security, etc with more ads? How often are programmers arguing for incredibly complex UI elements over the native (and trivial to implement) alternatives?

Programmers don't choose these things, because programmers aren't the real decision makers, it's management and business that makes the web awful.

[manicdee]

> What programmer wants to add those things?

The one that wants to keep their job.

> How often are programmers arguing for incredibly complex UI elements over the native (and trivial to implement) alternatives?

The existence of Bootstrap and Semantic UI suggest that programmers are in fact often arguing for incredibly complex UI elements over the native alternatives.

[reportgunner]

Are you saying that the executioner is not a murderer because he doesn't make decisions about who to execute and who to leave alive ?

[blackflame7000]

"how many times has a developer excitedly clamored to ruin their performance metrics, layout, security, etc with more ads?"

Depends how much traffic they have I suppose. I'd be pretty excited if ads bought me a Lamborghini for every color of the week because Tuesdays right now are pretty boring.

[zaro]

Of course, I tottally agree. I am not talkng at all about tracking, and 3rd party services at all.

I was talking mostly about the actual application logic and presentation.

BTW tracking is hapening even w/o javascript.

[C1sc0cat]

Its not adds its shovelling massive amounts of bloated JavaScript frame works in and hoping for the best and in a lot of cases just not understanding how to structure a website.

[TheSpiceIsLife]

I wonder what the economic impact of doing that would be.

[TeMPOraL]

If everyone did that? Probably very positive in terms of energy and resource use, positive in terms of less things to worry about for the businesses - and very negative for all the bullshit adtech jobs that wouldn't be needed anymore.

So strongly positive, in other words.

One has to remember that marketing and advertising have a big negative-sum-game component going on, where most or all of your marginal effort to promote your product serves only to cancel out the marginal effort of your competitors to promote their products.

[nobody9999]

>If everyone did that? Probably very positive in terms of energy and resource use, positive in terms of less things to worry about for the businesses - and very negative for all the bullshit adtech jobs that wouldn't be needed anymore.

It's not just the annoyance factor, it's the bloat from ads. In fact, something like 48% of retrieved data[0], on average is ad related.

Getting rid of those ads could cut client (and server and network) energy draws significantly. And we could further reduce energy usage by not needing add-ons like ad/tracking blockers and stuff like NoScript[1].

I browse with js disabled and, unless I need to visit a particular site, I'll just close the tab if js is required -- as the bloat, the security risks and the hubris of js overuse is just too much.

[0] https://www.nextpit.com/ads-consume-half-of-your-mobile-data

[1] https://noscript.net/

Edit: fixed spacing of referenced links.

[krageon]

For almost every "web professional", the things they do are not complex. It follows then that the likelihood of this question (to a reader that doesn't know you) being asked by someone who simply doesn't understand what it means to be simple. The casual observer is further lured down this path of reasoning because of your implications that a plain form is somehow worse than something mediated by megabytes of javascript. In almost every case you'll find online, this isn't true.

[fetbaffe]

Why wouldn’t it be simpler to code? When you do server side rendering with HTML forms you reduce complexity by having more pages.

It is somewhat more complex to handle more pages in your code base, but each page is short and simple.

[mattlondon]

State management is harder to do when running an app with a 50/50 split across browser and server.

You end up with a lot of complexity around cookies/local storage (and trying to persuade users that cookies are not bad and that their virus checker should not delete the cookies please ...) or encoding the session ID in the URL and hoping that users do not share links or bookmark pages, and then of course you end up with the "please only click once" links around buttons etc.

You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language (although could be nodejs of course). It is an extra interface that needs to be designed and maintained with all the opportunities for screwups that come with it.

[swiley]

I've written apps like this and have to wonder what on earth you're doing because this is very straight forward.

Put a session id in a cookie and use a relation table to point at the tables owned by the user. This takes very little code. The alternative is managing a distributed database, half of which has to run in the browser. That actually sounds much harder (although not surprising for a startup.)

If users are deleting first party cookies than it's their own fault. Tracking state on the website you've visited is the entire point of cookies. If the user throws their phone on the ground really hard your website also won't run on it.

[fetbaffe]

Yes, lots off apps today have the entire schema replicated in the browser, which means that every schema change you do in the backend must be replicated in the frontend. Madness.

If your UI is a copy of the database why not just give the user a phpmyadmin login instead?

[reportgunner]

> why not just give the user a phpmyadmin login instead?

The guy at the previous company said we can't do that.

[pitay]

You can use one of the many servers that manage the users session for you and only override it if needed. Is there any real problem with a server that uses a cookie to only store the users session ID, storing the other data related to the session ID on the server? For most sites I wouldn't think there would be any issues with it.

[fetbaffe]

Why would you need all that state management in the frontend if most of the rendering is on the backend?

We already have two teams today, one for the overly complex frontend and one for the backend. Solution to that is server side rendering and full stack developers.

[quanticle]

>You also now need two teams to code the front end - one that knows HTML etc, and one that knows the backend-frontend language

Or, you could hire some full-stack developers and let them split the work more efficiently.

[acdha]

You don’t avoid using JS at all but only use it where it benefits the user. For example, the users benefit from having those forms having nice validation, dynamic lookups, etc. but they don’t benefit from using a vDOM on top of the far more efficient browser DOM or loading an entire general purpose templating framework instead of just using the DOM to update an existing form.

Those are things which developers do because they think it’s easier than learning the web standards or looks better on their résumé and as long as you avoid measuring actual performance you can sustain these beliefs for a long time even while your users are seeing performance below the level of a 2000s Rails app with worse error handling.

[zaro]

> You don’t avoid using JS at all but only use it where it benefits the user. For example, the users benefit from having those forms having nice validation, dynamic lookups, etc. but they don’t benefit from using a vDOM on top of the far more efficient browser DOM or loading an entire general purpose templating framework instead of just using the DOM to update an existing form.

I am sorry, are you talking about example todo app ? because for most apps with complex navigation, data entry, and validation this is absolutely not true. Just use the DOM , might be somehow feasible with webcomponents, but they are years late to the game.

[acdha]

> most apps with complex navigation, data entry, and validation this is absolutely not true.

You mean we just imagined all of that existing? You could make an argument saying you personally haven’t learned how to do it but that’s a far cry from “absolutely not true”.

[franzwong]

Developer can stop using webpack to bundle 3rd party libraries. Let browser cache it.

[fgkramer]

Cross origin browser cache is a no-go for Safari (and hopefully other browsers will follow suit), 3rd party scripts from a CDN are not cached across different domains. The only way to properly cache things longterm is with webpack records, but not many people can bear with the added complexity of maintaining them in their pipelines.

[ratww]

+1. If you're only targeting evergreen browsers you can already use syntax like `import Library from './library.js'`, plus lots of modern ES6 features.

For IE11 just load polyfills and let the 2-10% of IE11 users pay the tax, instead of making all your users in modern browsers download giant bundles.