[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.

[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.

[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.

[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.

[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.