Hacker News Reader

Comment by Permit | Hacker News Reader

> I personally think we should abolish JavaScript and not allow arbitrary remotely loaded code to execute on our computers.

> "I want web sites to do everything a native app can do" is a suicidal mistake.

If you think you're ceding a lot of power to Google and Apple when it comes to browsers, I fail to see how "That webapp you're building can't use Javascript so build it in Objective-C/Swift for iOS instead" would cede less power to Apple.

At least I don't need Apple's approval to build my website...

View on HN

> I personally think we should abolish JavaScript and not allow arbitrary remotely loaded code to execute on our computers.

Yeah this is honestly where I stopped reading. The ship has long-since sailed on this one - on-demand software clearly wins on utility over local software in most cases, a fact which is proven by how dominant web is over native software despite it's many shortcomings.

I actually think what we need to advance software is a better stack/tooling for web to bring it closer to the native experience. I.e. I can imagine a world where my laptop is mostly a platform for running WASM/WebGPU code downloaded from network on demand - and it would be nice if that type of software was not so reliant on the browser as a middle-man.

Yes, that would be great! Except Apple deliberately hobbles their browser to prevent competitiveness with native apps.

But I guess that's the whole point of the discussion :)

> Apple deliberately hobbles their browser to prevent competitiveness with native apps.

It might be true that it’s not competitive but no evidence that it’s deliberate.

If it wasn't deliberate they would let you install Chrome instead of forcing you to use Safari with a chrome skin. And why do they have Safari with a chrome skin? Because then most gullible users thinks they can actually use chrome and that chrome and safari are mostly the same, when they are actually really different and they therefore don't understand what they are missing. Even here on HN where people should know better you sometimes see users say "if you don't like safari you can just install chrome!".

> If it wasn't deliberate they would let you install Chrome instead of forcing you to use Safari with a chrome skin.

Because browsers allow remote code execution and Apple wants to limit the attack surface.

This is about gullible users being protected from attackers by Apple.

I think we need BOTH a platform for on-demand apps AND a platform for documents with some dynamic content. That we've tried to put both together into one platform is, I think, part of the problem. I would like to be able to read the news on my phone without the cpu going to 100% and draining my battery. I would also like to be able to do collaborative document editing and video calls without having to install an app that takes up space even even I'm not using it. Today I feel both use cases suffer from running on a platform that tries to handle both.

Exactly. And I don't even think the separation would be hard on a technical level.

I spend a lot of time on websites where I rely on JavaScript (Google Maps, navigating GitHub etc.), but it's always the same handful of sites. Having a "Trust this Website" button to whitelist these places would totally work. Everyone else can serve me static HTML or lose me as a visitor. (I realize that's kind of what NoScript extensions achieve, but they're not a standard with enough momentum.)

In some sense I agree, but I think it's really difficult to understand where you would draw the line.

For instance, the modern web is a UX nightmare - every time you go to a site, you get bombarded with popups, requests to send notifications etc.

But how can you define which level of interactivity is allowed on a document without limiting creativity and the potential of the platform to grow?

For an extension like noscript or ublock, yes, it's hard to draw a line. One site uses one feature set, another site uses a different feature set, and if you draw the line around the union of those feature sets then it's too broad. Ads complicate things even more, because a simpler technology makes it easy to filter them.

I don't think the solution is in trying to draw such a line. I think the solution is to build something that covers 80% of the use cases, AND makes it sublimely easier than the technology we use today, AND is backed by someone with the power to deliver it to users.

There are examples in our history where we rejected a complex technology in favor of a simpler one, so there is some precedence. Remember HTML 3.0?

> a fact which is proven by how dominant web is over native software despite it's many shortcomings.

I wish it was, perhaps may be by numbers i.e. websites vs native software but if we take mobile ecosystem, native applications rule and many of the web pages are just landing pages for those mobile apps.

Smartphones are the first computers for majority of the world and significant population among them would have never opened a browser to enter an URL but perhaps would have used WhatsApp to click a link and opened it in built-in browser.

Even in web, mobile visitors has long overtaken desktop but again how much of it is organic i.e. direct or search when compared to those from social media, chat apps which again are likely to be native apps(and opened in built-in browser).

After a decade of developing mobile(native) apps for all major platforms I've quit native mobile app development and have started to focus my efforts back on web; My audience are intentionally those who wouldn't mind using a web application but I still occasionally receive questions from a new user like 'Is there an app for this'.

I strongly believe that until the duopoly in mobile ecosystem is fixed, Web is under serious threat.

> I wish it was, perhaps may be by numbers i.e. websites vs native software but if we take mobile ecosystem, native applications rule and many of the web pages are just landing pages for those mobile apps.

Largely because iphone doesn't let you install a proper browser that doesn't lack most features from the past decade, and iphone users is where the money is at so that is what companies targets.

Although iOS browser locking is troublesome and dangerous for free and open web it's not the reason for why native apps are preferred on smartphones; It's because mobile apps are easy to access, faster to use and Big Tech invest humongous amount of money in promoting those apps as it can siphon more data.

> mobile apps are easy to access

Easier than typing a web page once and then maybe clicking "add to my home screen"? Which is how PWAs work. They are great on Android, but iphone has deliberately not supported the standard.

> faster to use

Citation needed.

> Big Tech invest humongous amount of money in promoting those apps

Again, apple doesn't support the web, so companies that want to leverage web capabilities are forced to develop native apple apps.

No need to even go this far. Just have Javascript as an option, not a default. People seem to have lost sight of the fact that the web was and still is functional without all the added browser features. By all means, have the features, but making them defaults is something very different. It is denying the more basic functionality of the web. In some (read: many) cases, using the web in a more basic way without certain features reduces the amount of risk a user undertakes. Sometimes it is just plain faster and more reliable, too.

This developer-dictated "defaults" strategy is developer-friendly but user-hostile; it's why we end up with power users commenting on HN along the lines of "I can't turn off X, because then all sites will break." Most users (non-power users) cannot even turn off X because they do not even know they can. They haven't got a clue. Developers like it this way. This is some highly manipulative maneuvering; this is unethical IMO, but I think like a user not a developer.

Defaults are definitive. Perhaps that's why the current CEO of Google, before he became CEO, worked so intently to get vendors to make Google the "default search engine". Users do not change these defaults.

> Just have Javascript as an option, not a default.

This is already the case, isn't it? You can easily disable js for good, and then enable it as needed on a per-site basis.

It hasn't been the case for some time now. JS started as something to spice up the html content, to add extra niceties. But The rise of virtual Dom JS rendering Frameworks brought upon pages that don't have any html content, that don't display anything without JS, Just a Blanc page. For some time adopters of such Frameworks would keep a limited functionality noscript page, but it didn't take long for them to drop the extra work. The highest profile website following this theme is Twitter, the dropped noscript a year ago. So JS is not optional anymore, to browse the full web you need JS, without it you get a subset that doesn't include some major social networks or some major news sites.

In what other way could JS be an option than it is now?

Ever since JS was added to Netscape Navigator, it's been the case that you need it to experience the full web. The difference is that now you need JS to experience more than a small fraction of the web.

It is an option, the web has just evolved past no-javascript sites.

Or in other words, it's actually not an option.

You disable JS, you make most websites unusable out of the box. You don't even need to go that far; disable web fonts and half the websites' buttons become undecipherable.

Technically those might be options, but in reality you have no other choice if you want to use the web.

I would like to see something in the middle. Instead of defaulting to no javascript, default to "javascript lite". But make "javascript lite" full-featured enough that it makes building websites _easier_. I know a lot of people have tried this already, so clearly it's a hard problem, but I think there's a market for it. There's a reason why wordpress, geocities, myspace, medium, and even AMP all exist. Limiting a content creator's options can make things simpler, and people want simple.

Imagine a technology where I can test my page on one browser and be confident it looks right everywhere, not because the browser has market dominance, but because all the hard work of targeting the lowest common denominator has already been done for me. When was the last time you thought "hmm I better check and make sure this markdown document renders correctly in safari"? I think this is where the world is heading, and it's why so many sites are supporting markdown syntax. But there are so many markdown flavors and engines that we've just pushed the problem to a different level of the tech stack. But I think the concept is sound, even if the technology is still evolving toward that ideal.

What you’re describing is/was jQuery. Then we learned how to transpile things back to earlier versions of JS and all bets were off.

If you use today’s jQuery to build out some functionality today, it will likely work exactly the same for every browser since IE10.

> It is an option, the web has just evolved past no-javascript sites.

For many sites it is not an option. If you disable JavaScript then it does not render at all. I've also run across web sites that do not work at all if cookies are blocked.

IMHO this kind of design is just retarded. If you want certain functionality dependent on those features being active, I can understand that. But them being disabled should not prevent the web server from sending me HTML and CSS so something renders on my screen.

It is an option, it's just not convenient to you.

> retarded

I know this is HN, and there are a lot of people here who are resistant to social change, but please don't use this word

I think more effort should be put into cross browser support, but that said.

> "I want web sites to do everything a native app can do" is a suicidal mistake.

Most Mac users are just using MacOS as a windowing system to run Chromes browser engines multiple times across the bunch of Electron apps they use to do their work.

The age where Mac users were mostly working all day in native Cocoa apps is long dead, I think I might be the only person in my office that uses a text editor running on Cocoa not Chrome.

We didn't get here by accident, end of the day Figma is better than Sketch, Google Docs is better than passing Pages files around, Google Maps in a browser window where your actual research is happening is better than opening the Apple Maps app and Slack is better for work than Messages.

The world moved forward, Jeff might not like which tech stack it chose but no one is making anything written "natively" on Macs that can compete, and it's silly to say that it shouldn't exist while that fact is true.

We ended here for pure business reasons, and not as a convenience for end users. JavaScript programmers are dime a dozen comparing to Cocoa programmers. What we ended up with is suite of software almost no one uses on their free choice.

The business decision Apple made to largely ignore Cocoa, especially any semblance of documentation, and then confuse “native developers” by giving them conflicting half-baked solutions like Catalyst and SwiftUI? I guess given the option between a closed-source half-assed framework like Catalyst that even Apple themselves can’t make reasonable apps with (see Apple News), and an open source half-assed framework like Electron where you can at least contribute a fix instead of having to wait a full year for the surprise of whether your reported issue got fixed or not, most people just preferred the latter.

“Business reasons” and “convenience for end users” are not entirely decoupled because developer time is not infinite or free. As an end user, the app that exists on my platform (Figma on windows) is better than the app that never got ported because it’s codebase is tied into a bunch of OS native stuff (Sketch). If an app costs half as much because it’s easier to hire developers who know JS compared to native devs, I’ll also be happy. If an app gets features added faster, or is less buggy, or has a better plugin interface, hey, I won’t complain.

There’s nothing that says “as an end user I’ll always prefer electron” - I don’t care what it’s written in. But from my perspective there seems to be a lot of high quality electron software that may not have existed otherwise.

>We ended here for pure business reasons, and not as a convenience for end users.

But it's users who are creating these business reasons. Many people, myself included, simply don't experience native software as universally superior as platform purists would have it. So we're not paying for it.

And no you can't simply blame employers either. They may not care much about what their employees find more convenient or more beautiful, but they sure care about productivity and TCO.

Resource constraints are not a capitalist conspiracy. Free software suffers from the same issues and trade-offs between implementing actual features and re-writing software for six different platforms and UI technologies.

A choice free of any and all resource constraints cannot exist.

Also we have to consider that porting software or trying to make it work with the same characteristics and UI is pretty difficult and expensive (in time and money) compared with a web app or an Electron application.

You forgot the elephant - vscode - built on chrome (electron) and now used by majority of devs.

Also folks who want js go away web sites dont realize how massive the ecosystem is. How many unicorns are SaaS vs Native? You are asking them to go out of business?

I also fail to understand how "lets install native code to run on our OS" results in more security and privacy.

The browser is inherently more locked down than native apps. A Facebook app on your computer can read anything on it without any pesky browser security and privacy features getting in the way.

The Twitter thread isn’t discussing security or privacy. It’s discussing who (effectively) controls web standards right now, and who should do so in the future.

> A Facebook app on your computer can read anything on it without any pesky browser security and privacy features getting in the way

This is not true, at least on OSX.

It will ask the user to confirm whether the app is allowed to read/write to key locations e.g. Documents, Photos as well as access key sources of data e.g. Contacts.

That just leads to decision exhausted users saying yes by accident. Traditional browser policy errs more on the side of not making things that are too often dangerous especially if they are rarely beneficial over safer flows. Trying to make progressive web apps do whatever an app can do is basically being bug for bug compatible with bad ideas that sound "convenient".

>decision exhausted users saying yes by accident

true this. day before yesterday, i had a webapp ask camera and mic permission and after giving yes to both got a third dialog immediately - i read it but gave yes accidentally before realizing it was permission for push notification -

such a dark patterns can be used for exploiting users.

Unlike on iOS, we are unable to determine access per app at a file level on MacOS (OSX). The permissions are at a folder level. Thus, if we give access to the Documents folder today and then pick a single file, the app is actually free to scour the Documents folder and act on its own (scan the meta data of all the files, upload all the files somewhere, for e.g.)

"Apple has too much control over the web, so let's build native apps in Apple's walled garden" is not exactly the most persuasive argument.

Don't forget to pay your apple tax (TM) on the hardware to actually build said native apps. And your yearly tribute to the apple app store so they flip a coin as to whether your app is listed or removed.

Agree. I can see why a Mac/iOS developer might feel that way though.

The author never says that - you are misrepresenting them. They are against the walled garden.

But removing javascript from browsers will just make more walled gardens. Browsers are not walled gardens, unless your OS prevents you from installing other browsers (see iphones...).

It doesn't matter what you say you support if the consequences of what you do hurts that goal.

> But removing javascript from browsers will just make more walled gardens

What new walled gardens do you think would be created if JavaScript was removed from browsers?

A walled garden for every OS.

MacOS and iOS apps will need to be written in Swift, so you better hope all devs know Swift and have Macs to write code in.

Windows Apps will need to be written in... uh, C#? Good like finding as many devs for that as there are currently for JS.

I think that goes back even further: The industry has invested a lot to push the concept of arbitrary automatic updates. Today it's not just normal that the code and functionality of your installed apps is constantly changing, it's almost expected. An app that doesn't get updates is considered dead.

Nevermind that this results in a system that is completely impossible to reason about, that this allows companies and corporations to play out business politics right on your hardware and that now suddenly apps can be taken over by malicious parties.

Suddenly, we need a privileged "app store" 3rd party that can constantly monitor apps and ban them, should they suddenly turn into malware.

That is suicidal.

>At least I don't need Apple's approval to build my website...

Yes. But some day you may need Apple's approval for Apple's user to visit your website due to security / privacy / or other ideology them deem unfit for their user's consumption.

Seems like the original tweet is now gone? But I do want to say, full fledged webapps have been an absolute game changer for internal tools at large companies. I can't even imagine maintaining internal tools any other way now.

The author also is critical of Apple’s control of the App Store. There is no contradiction.

Reply on news.ycombinator.com