Hacker News Reader

Comment by aliqot | Hacker News Reader

Maybe I'm just getting old, but Javascript jumped the shark at some point. Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful.

im sure someone with shinier boots than mine will pop in and tell me how im wrong, and perhaps youre right, but the web was a much better place without all the toolchain and shenanigans. We must return to fundamentals.

View on HN

I agree with you from a technical standpoint — something created for displaying and navigating between documents is being misused for distributing apps.

At the same time though none other model affords the same distribution, write once run everywhere. No other distribution platform can compete. And users have become accustomed to the web being apps as well as documents. In fact, many have become accustomed to more or less treating their web browser as an OS (or more realistically, not giving the distinction any thought).

Maybe an interesting way forward could be a web model specifically for apps, which of course many would say would be WebAssembly. The HTML/CSS/JS combo has been remarkably successful and resilient though, so I'm not convinced it will be dethroned easily.

It existed in the platform. But Mozilla has lost the first _and_ the second Browser War and has been sentenced to shepherd some "web developer" Wiki and tell everyone how fun that all is.

Yes it can make your day sad, but I'm sure, out there is a crowd that is just amazed by all of it. And its told that the payment was not that bad as well, so we truly only have winners.

My boots are pretty dusty too, and a web browser isn’t usually how I usually want to engage with a tool or toy.

But the systems architecture model of infinitely beefy backends with simply-adequate thin clients predates both of us. Browsers, the cloud, and all this obnoxious javascript tooling are the contemporary implementation of that and not without reason. They do it pretty well!

Like with any new tool, people get carried away and start using it for things that really don’t need it. I’m with you that most websites don’t need all this stuff and get caught up in it anyway.

But that’ll burn off, and in the meantime, we’ll end up with a rich, mature thin client system for the solutions that need it and that system will be around for decades. No sharks jumped.

Browsers of today are begging so much for new clothes, they ain't browsers anymore. Gib dem Affen Zucker.

I remember when HTML5 and CSS3 were just in the RFC phase and many web developers thought they would make their jobs simpler. Because the things they were being asked to do, for which they were currently creating tortured workarounds, could be done directly with the new standards.

But of course the job did not become simpler. The fixed value turned out not to be what clients would demand, but the quantity of tortured workarounds devs could be enticed to endure.

I'll be an anecdote: I literally only came back because of CSS3 and jQuery. Managing layout with tables and all hover effects with javascript did not sound like a fun career choice when I first started. And now I've fully embraced flexbox and grid and styled components - I rarely have to think about classes anymore. New tools have been making my job a lot more fun over the years.

Almost got back into webdev but the technical interview was 100% JavaScript.

"Am I out of touch? No, it is the children who are wrong."

This is an old, tired take that boils down to "we should be ashamed for wanting nice things." If only everyone would just accept simple websites like HackerNews! This is backwards, it is user-blaming. It turns out that the web is an incredible platform that has revolutionized the world, and thousands of people have worked hard to build tools that make it easier to develop on. "Web fundamentals" can't give you Google Docs.

> "Web fundamentals" can't give you Google Docs.

There's real irony in this statement, since you can't get much more fundamental than that. WorldWideWeb.app (Nexus) was created as a read-write client for both navigating and authoring content. Not only are modern Web apps not a necessary precondition for that, but neither JS nor any form of mobile code are necessary, either.

(The thing that Docs does wrong where "fundamentals" are concerned is its de-emphasis on the importance/role of the URL and making every Docs doc a sort of second-class publication that exists in this "other" kind of space—i.e., Google Drive and the Docs editor, which you always get a sense of being "inside", instead of the content just being out there on the Web.)

People want to be able to author and share docs, directly in the browser and share with no effort. You cannot do this without JS, and the level of complexity is sufficient that you need robust tooling in order to manage it.

You can do this directly in the browser* without JS—in exactly the way shown by the example I just gave: by using a browser that is capable of editing and sharing docs (directly).

* If someone really wanted to be a stickler, they could point out that that you've set up Google Docs to fail your own rubric, since it involves indirect editing. The browser itself has no direct role in the editing process. It only manages to do so by fetching and executing the minified bundle on the Docs site.

So your solution is to write a browser so you don't have to write JS?

Supposing I just want to create an internal tool that allows me to collaborate in realtime with my colleagues on a document (multiple cursors, everyone editing at once) and I have to do it in an existing browser because I don't write C++ and only have a few weeks to deliver - how would I do this without JS? Also, it needs to work on Android, iOS, Windows, and macOS in FF, Chrome, and Safari.

> So your solution is to write a browser

First, you're moving the goal posts...

> so you don't have to write JS

... and attacking a strawman. (No, I'm not worried that I might "have" to write JS. I've written a lot of JS. And I put a lot of effort making sure there was high quality documentation about the language in the early days of developer.mozilla.org—so that other people could have a nice time when they write JS.)

Secondly, you are aware—I'm certain of it—that the company behind Google Docs actually does have a browser.

> You can do this directly in the browser without JS—in exactly the way shown by the example I just gave: by using a browser that is capable of editing and sharing docs (directly).

So your users will need a specific browser to use your Web app?

This goes against a primary advantage of Web apps... They work on many different browsers/devices*

> So your users will need a specific browser to use your Web app?

No. For the use case mentioned (editing and sharing docs in Google Docs), no one would be using a Web app, because there isn't one anymore. With the browser itself able to do directly what Google Docs is being used for, there's nothing left.

<contenteditable

Sure. And now you need thousands of lines of JS to make it cooperative in real time.

That's not a requirement for most people, versions and locking is fine.

There are certainly refinements that can be added with JS, but JS is not a requirement, and certainly is not for rendering an editable page.

We're talking about programming apps such as Google docs. It is a hard requirement. Your reply is completely useless from technical perspective. Sorry-not-sorry to be so blunt but I have no sympathy for "yeah you can do it without any JS if you remove all features". Let's just go a little further and throw away our computers - we can send carrier pigeons to each other, right? And what's this paper stuff? Useless! Stone tablets 4ever!

And as a user, it is a hard requirement for me too. I never want to go back to locking and versions, that's absolutely terrible and completely kills the workflow I have with my colleagues. Collaborative docs editing is single most awesome development of the modern web and users are choosing the otherwise not-so-good Google Docs solely based on this feature. Perhaps not every user needs it - but there are countless users that do. If I wanted to edit without collaboration I'd use Word - much better UX and document editing capabilities... Sadly no truly working collaboration - it's too much like locking/versions, so it's not an option. I'd rather use collaborative raw text editor than the best of the best locking/versioned WYSIWYGs.

I presume it didn't have realtime collaborative editing or comments?

You can have simple websites without them being ugly

Users don't want this shit, startups do.

This is an incredibly broad statement based on practically nothing. You don't think it's weird that most of the largest, most successful websites have mountains of tooling and frameworks to help them remain performant and reliable? All these tools either help the user directly, or solve real problems for companies to help them build more quickly.

I also think you grossly overestimate the average user's abilities. They literally cannot tell what is possible and what is not. They don't want simple, they want something to solve everything, as easily as possible.

You don't think that it's weird that most of the largest, most successfull companies have mountains of office politics?

Clearly this means that office politics is good for your company

Largest economies in Europe have the oldest and most drafty, poorly insulated housing stock. Therefore shitty housing stock must be good for the economy.

Largest economies in the world have the most pollution. Therefore pollution must be good for the economy.

Backwards reasoning.

You're arguing that correlation does not imply causation. Fair. So tell me: how would you manage to build a website like Facebook without robust JS tooling?

The answer tends to be "wellll I hate most of these features anyways, let's get rid of them and then it can be as simple as HackerNews!" But obviously, millions of people use those features every day and like them. The tooling solves a real problem.

There are industries that use real robust tooling to run banks, build databases, control surgical robots. They don't choose Javascript, it has all the robustness of a wet noodle.

Desktop and Mobile application are reasonably robust, have very complex software and could do everything Facebook does trivially. All this 'robust tooling' has evolved because we are trying to shove an application into a browser, and despite decades of effort. it still kinda sucks.

If Apple, Microsoft and various distributions of Linux pulled the finger out of their collective asses and agreed on a half-decent, cross-platform GUI software package in 2005, none of this JS madness would exist.

> cross-platform GUI software package

And cross-platform APIs, cross-platform libc, cross-platform networking... and then the same shuffle on mobile, making sure everything is compatible? Supporting x86 and ARM?

The web does suck, there's no getting around that. HTML and the DOM are garbage even at their original purpose, let alone at writing applications, and everything on top of that is a kludge on a kludge on a kludge.

But let's not pretend dealing with OS APIs from the 90s is much better. We've been trying to get away from that as early as we could with e.g. Java.

Lots of "robust" industries choose the JS ecosystem.

I work in Fintech. There's a lot of tooling to make JS-as-a-language more robust, including TypeScript and some of the best linters, debuggers and introspective libraries available in the entire tech industry.

The only reason JS isn't used more than it is, is because its robustness is young, not non-existent.

Ah can’t wait to finally build a cross platform app without complex JS tooling once I take my time machine back to 2005 and change the course of cross platform GUI development forever.

> If Apple, Microsoft and various distributions of Linux pulled the finger out of their collective asses and agreed on a half-decent, cross-platform GUI software package in 2005, none of this JS madness would exist.

This is what browsers are. You are describing browsers. They run on any device, on any architecture, and nowadays even on the edge. This isn't just about GUIs. I can't stand this lazy mentality of "pfft, I know better than these billion dollar companies, have they tried just making it good???"

Strawman

He argues tooling is a necessary but not sufficient* condition to performant web apps that solve meaningful user-facing problems

You argue he claimed correlation is causation

*Edit: had necessary and sufficient backwards

> You don't think it's weird that most of the largest, most successful websites have mountains of tooling and frameworks to help them remain performant and reliable?

I don't fully agree with the person you're responding too, but it feels like you're making their point for them with this. Users are engaging with a tool or some content for themselves and today. Startups are the ones dreaming of standing among the "largest, most successful websites" someday.

Users don't care how efficient or inefficient your development process is, or how much technical debt you carry, or how many concurrent users or requests you can run, or how scalable you are if things go well. If your service stands up and works for them today, none of those things are relevant to them at all.

That's not to say that the startups concerns aren't critical to making sure that the service is still capable tomorrow and the day after, and that the company doesn't collapse under bad process and inefficiencies, and that the service maintains utility rather than becoming data and stale. They're valid concerns.

But the users are so far removed from those concerns that it can be legitimately frustrating when pursuit of those long-term concerns degrades their immediate experience.

> long-term concerns

And that's it. If you want to ever reach those long-term goals, you need robust tooling.

Free money solutionism's finally dying, dude. Better learn to solve actual problems instead of problematizing what you can barely do.

Do you have any proposed solutions for the problems that exist? Going back to fundamentals doesn't eradicate the problems, it will only recreate them in a slightly altered state.

One of the most commonly proposed solutions is we keep the web to only static content. Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser, shifting all the same exact problems onto a new platform instead.

> Well now we've just shifted all the media-heavy interactive content onto a dedicated app instead of the browser

And then they complain because "This could have just been a PWA, why do I have to install an app for every website I use!?"

You're not wrong, the websites I enjoy the most are basically all static.

I think the problem is that the "web fundamentals" aren't that good to begin with. A web application is very often the least bad solution, but you're not going to have "rich" web applications without tons of JS. Show the average user HN and they won't like the interface.

> Hydration, lazy loading, managing flashes of unstyled content, a lot of this is built to address things that wouldn't be problems if we treated the browser as the dojo that it is and not be so dang wasteful.

What's your point here, exactly? That if random wordpress blogs and recipe websites were less wasteful, the problems these solutions are addressing would not exist?

I can make you an extremely non-wasteful webapp which still needs to display a hundred images on a page (because reasons), so lazy-loading the images is still important.

I can find you a very well-optimized website that is only a few kilobytes, but still loads slow as shit because their network is bad and I'm on a terrible 3G link. FOUC would still be an issue.

I think the point is people should use the correct tool for the job. Instead, sites that should (or can) be static sites are unnecessarily using some JS framework.

Newer JS frameworks like Svelte and SolidJS can be almost transparent to the user, though - with no need for bootstrapping a complex codebase in the client before they can interact with the site. I'm guessing that OP describes a further development along these lines.

i think you're conflating static sites with sites that lean heavily into JS frameworks. plenty of sites are not static, cause they need that whole session thing, and don't use JS frameworks

HTML has native support for lazy-loading images these days. No need for added JS.

You can lazy-load a lot more than images. In my example, yes I wouldn't use js for it, but it's irrelevant to the point I was making. My read of GGP is that "lazy loading is useless because you shouldn't have so much content that it's needed, ever", which is a bad take.

it does, but when design and top brass say it needs to fade in - back to some JS you go

> FOUC would still be an issue.

hell, just using webfonts can cause FOUC - no JS needed.

> if we treated the browser as the dojo that it is

I have no idea what this means. Isn't a dojo a place for learning or meditation? I don't understand how that fits the browser, the internet, or web development.

My take was something along the lines of 'the browser is a place to strive for simplicity and mastery' instead of 'move fast and break things'.

I thoroughly agree, society was much better before computers came along.

Whoa whoa whoa, let's not get carried away. The peak of technology obviously occurred in $YEAR_AUTHOR_GRADUATED_UNIVERSITY and it's all been downhill from there.

I would add a -50 to that.

We want to live in golden age

Can't tell if this is is a joke or not lol

There is some bias in this comment, perhaps Ordnung is what compels it, but simpler was better, and though collectively we were less informed, we were also less burdened.

There is value in a plain lifestyle and community. We've lost a sense of community because of this pervasive false-familiarity that the internet and phones have created. You no longer need to see your relatives and community members because you can 'see' them on a website or app or call them.

Whether it gets acknowledged or not, for all of the positives this connectivity brought, there were an equal amount of problems. Our advances in telecommunications led to an uncomfortable truth that not everyone's innermost feelings should be foisted upon the greater community. Everyone knows someone who's consumed with worry/negative-excitement over the struggles currently taking place.

We will never again have another private thought, another uninterrupted conversation, eye contact, feeling someones hands as you tell them how much their being means to you. All of that are the incontrovertible consequences of the Internet, our prodigal problem child.

This sort of generalization really doesn't help any discourse.

While it's indeed easy to lose the things you mentioned we're still not forced to do so. Many are already stepping back and reconsidering their choices, and rediscovering various real-life elements. I'm seeing it around me.

And this:

> We've lost a sense of community

...is extremely one-sided. I started my life in a small town where if a bunch of prejudiced people didn't like you then God help you because they could even make sure grocery stores will not be selling you food. I wish you luck even existing on a basic level there.

For people who don't have the approval of their small communities, internet (or physically moving) has been a blessing.

So while your point is valid, you went way too far without regard for nuance. The fact that a lot of people waste their precious time on bullshit on the net does not in any shape or form mean internet hasn't been extremely helpful and enabling for many people.

> We will never again have another private thought, another uninterrupted conversation, eye contact, feeling someones hands as you tell them how much their being means to you.

I disagree. It is just that these now need a conscious decision from us. My thoughts are still private until I choose to publish them. My conversations are only interrupted if I allow them to be. We make eye contact when we decide to. The intimate moments with my partner are there when we create them.

True, it’s easy to loose that and growing up today, you need someone to show you that it can be done. Which is why I agree that we stand to loose that, but we are not there yet.

poe's law strikes again

(it is)

agreed, wouldn't be able to read this comment

We must return to fundamentals.

These are not fundamentals. Overtone window has shifted out of its initial position completely, but browsers ignored it for two decades and offloaded that to webapp developers. Web 2.0 is not a browser, it is what became possible with everything people have built outside of it, on top of “take it or leave it” attitude. Web 1 is an archaic network of winword-level documents that is a huge step backwards in ui, ux, common sense.

We must not return to anything, browsers must get their ass up and running towards what other people achieved through hard work despite all the obstacles.

The core issue is that browsers were not made to provide the sophisticated features we require these days. Because of this fundamental problem, you can't build something like Gmail or Spotify without increasing the complexity of development exponentially.

The "SSR + sprinkled JS" paradigm is still totally valid though for many use cases.

Developers, just coding their websites, not a toolchain in sight.

> but Javascript jumped the shark at some point

Contemporary frontend, in-browser app development, you mean. JS is a programming language. By conflating a language with a particular culture of software development, you implicitly transfer more power to that culture, the people in it, and their practices, even though your message expresses a clear desire for the opposite.

Reply on news.ycombinator.com