Live data from Hacker News

Ask HN: Why is everything in JavaScript changing so fast?

news.ycombinator.com

291–300 of 303 posts

Re: Ask HN: Why is everything in JavaScript changing so fast?

#291
post #87

Earlier quoted context omitted.

What's wrong with native apps? They use less memory, battery, and processor than an interpreted stack. They can be more responsive than the hardwired 16ms latency built into the browser. If you need network it's not hard to open a socket. The browser itself is a native app opening sockets. In pretty much every respect, native apps are better for the user than web apps. The person that benefits the most from web apps…

I'm not taking a side here, but I would like to advocate for a fair comparison, since you have skipped all of the trade-offs in the other direction. For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, bu…

> easier to discover,

How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.

> easier to update,

because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?

> easier to manage (since you only have one version in the wild you have to handle), Except when there are cache issues. Or when you have multiple servers and need to upgrade them without downtime. Not to mention all the stuff required to host your app needs to handle enough scale to load not just any potential server side data but also the entire ui, possibly every time someone loads it (opposite of the cache problem above). Must be easier though, I've never heard of any web apps being unavailable because the servers were overloaded.

> easier to launch (especially for first-time users), How is typing a or clicking a link easier than tapping/clicking an icon?

> easier to use from different platforms,

If your browser on your platform is supported. And you have the right version.

> more secure (debatable, but since the browser has huge companies working to keep it secure, and your native app that's just opening sockets doesn't, it probably is true)

This is a joke, right? Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps? Pretty much no web apps use local storage exclusively. So your attack surface is not "the browser", it's the browser, the network stack, the network itself (see: ddos on Dyn, Comodo/WoSign bullshittery to name a couple from the last month alone), your server host(s), your server os/stack, your server side app logic, your server side db/storage stack.. Do I need to go on?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#292
post #119

Earlier quoted context omitted.

Explain what the coincidence was ? There are alternatives everywhere (ActiveX, flash, java, visual basic IIRC). And yet here we are, with JS. I believe JS came here because it actually is the best language we have had in the web. It's so easy to throw shit arround, but let's be honest with ourselves, this isn't purely out of luck.

JS is the only language integrated into the browser and the DOM. Netscape rejected other languages (Python, Perl, TCL) because of syntax, so Brendan Eich disguised Scheme into Java syntax and hacked up a prototype in 10 days. Today, Javascript is sooo interwoven with the DOM in browsers that it is near impossible to separate them. Google planned to do this for Dart, but gave up. If they had done this and other browse…

1. WebKit rejected adding barriers to support multiple garbage collectors and a super-GC to collect cycles, required by Dart or any 2nd VM. See https://lists.webkit.org/pipermail/webkit-dev/2011-December/... where Fil Pizlo of Apple cites 5% throughput regression.

Dart was never going to make it, and adding 3 or 4 VMs with their own GCs is even less plausible.

2. See https://github.com/WebAssembly for progress on what asm.js showed was possible: a 2nd, initially co-expressive with asm.js, eventually more expressive, binary syntax for the Web. It's happening now, this year and probably shipping experimentally in 1Q2017.

Writing "easily take a decade" out of ignorance just says to me you didn't even bother to use google!

Re: Ask HN: Why is everything in JavaScript changing so fast?

#293
post #265

Earlier quoted context omitted.

On the other hand, Go's type system is so bad that it nullifies all the benefits it brings to the table. I'd rather have no type system than Go's type system, but why even ponder that if I can have everything? With JS I can start out with dynamic types, then switch to static types if the need arises (typescript, flow), fully or partially. Oh, and both of those have really good generics btw. And we have async/await to…

Ive never put the words together, but you've basically highlighted what I want: Python (and its type system) + Go routines Where can I find that!?

TypeScript?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#294
post #284
post #256

Earlier quoted context omitted.

There are a few condescending attitudes at play in your comment. Consider this: just because a language is easy to pick up doesn't mean it attracts "poorly trained devs". It just means it attracts more devs, because it is easier to get into it. Putting aside any value judgement of mass appeal, my experience suggests that the most important differences between a poorly-/un- trained dev and any other kind are time and…

> So, being easy to use is a much more powerful feature for a language / framework / platform than most. I never said that JS was easy to use. I said it was easy to access. With JS, you don't really need an IDE, compiler, runtime etc. You need a browser, and a text editor and you can get started. It's unlike a lot of other languages in that way. In some ways, I'd argue that languages like JavaScript are harder to use…

> think people need to have more respect for the software engineering field, follow best practices, and not throw out everything we've learned as each new Next Big Thing (TM) comes out.

I agree with this sentiment, with a few (rather large) caveats:

∙ Best practices yesterday may be legacy practices tomorrow.

∙ The Next Big Thing™ is usually hidden lower in the stack (in the above example it was cheaper commodity hardware and free-as-in-beer operating systems), and while it may not force throwing away everything, it can still prompt throwing away a heck of a lot.

So, yeah, there is a lot of churn in the JS ecosystem right now. It's inevitable that there will be some sort of shakeout and some projects will emerge as de-facto standards around things like declaring dependencies, build tools, etc. The same thing happens in every successful software ecosystem exploiting a new niche.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#295

Earlier quoted context omitted.

We have to rewrite everything in JS because JS is the language that runs on browsers. :) If you were asking a higher-level why (why do we have to use the browser), look rer's sibling comment. I wrote the phrase "wise old timers" with respect-- y'all truly have things to teach us. But it often feels that y'all just want to complain about how we're doing things wrong, rather than actually helping. I suspect that "old t…

> We have to rewrite everything in JS because JS is the language that runs on browsers. Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway. Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal? If the problem is discoverability/installation/security etc we could focus on ap…

> we could focus on app stores and sandboxes (which modern OSes also have both), instead of rewriting everything on the web.

Show me another way to write end-user applications that are cross platform, and then (if it existed prior to 1995, or even 2005) explain to me why your particular alternative didn't take over the world.

Heck, even standalone desktop and mobile apps are now being built with web technologies (react-native, Electron, etc.) rather than GUI frameworks like wxWidgets.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#296

Earlier quoted context omitted.

I'm not taking a side here, but I would like to advocate for a fair comparison, since you have skipped all of the trade-offs in the other direction. For example, web apps are often easier to discover, easier to update, easier to manage (since you only have one version in the wild you have to handle), easier to launch (especially for first-time users), easier to use from different platforms, more secure (debatable, bu…

> easier to discover, How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store. > easier to update, because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever? > easier to manage (since you only have one version in the wild you have to handle), Except when there are cache is…

> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store.

Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and installation process, no delay, instant feedback.

> because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever?

Not sure I follow. Are you asserting that native apps are easier to update than web apps?

> If your browser on your platform is supported. And you have the right version.

The combinations are smaller than the combinations of operating systems and phones one would have to worry about.

> This is a joke, right?

Is this a good way to have a productive conversation?

> Did you suddenly forget all the huge leaks of massive amounts of information from hacked web apps?

Do you think only web apps communicate with servers?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#297
post #204

Earlier quoted context omitted.

Some ppl simply are rock stars. They are better than everyone else at the whole open-source lifecycle. They know how to do the marketing, manage scope, ship features, manage issues, etc. To make a successful open-source project is not easy and is about balancing a range of factors, including balancing their work/life. Not everyone can do this, or wants to do this. I think rock stars earn their status.

Yeah, I don't know about that. In my mind, the true rockstars are the people solving hard problems, e.g., kernel contributors, safety critical code, driverless vehicles, etc. I couldn't care less that you can quickly tape together 100 libraries and 7 frameworks to get the latest rendition of pets.com off the ground.

Making people who are incapable of kernel work, drivers work, writing safe critical code, etc. capable of being safe, secure, and highly productive, if only by glueing hip new libraries, is a rockstar task.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#298

Earlier quoted context omitted.

> easier to discover, How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store. > easier to update, because "clear your cache and reload the page" has been said by no frustrated support/technical staff, ever? > easier to manage (since you only have one version in the wild you have to handle), Except when there are cache is…

> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store. Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and i…

> Not sure I follow. Are you asserting that native apps are easier to update than web apps?

I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update.

> The combinations are smaller than the combinations of operating systems and phones one would have to worry about.

That can't possibly be true. Most platforms have more than one browser available, and with the exception of Microsoft, browsers don't have a "use x.y.z version rendering" like platform sdks.

Edit: unless you're taking the approach of: it works with this specific platform device running browser X, so it must work with all others running X. In which case, why not take the same approach to native apps?

> Do you think only web apps communicate with servers?

Where did I say that? Nowhere.

Web apps must contact servers and any remotely useful app will have all its storage server side.

In addition, web apps rely on servers to deliver the very thing the user sees and interacts with. UI spoofing has become such an issue browser vendors are reverting back to make it harder for web pages to present native looking dialogs etc.

Native apps can operate in a client server model, but a great deal of them don't need to because their use case is for local work, and even those that do, are merely transferring data over that channel. They aren't dependent on the same channel for the very interface the user sees.

Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.

Re: Ask HN: Why is everything in JavaScript changing so fast?

#299

Earlier quoted context omitted.

> How can that possibly be true? A web app can appear in a search engine. A native app's website can appear in a search engine and in a platform App Store. Because when I come across a web app in a search engine, I can click it, use it instantly, evaluate it, and decide to stay or leave, all within seconds. No checking if the app I found supports my platform, no click-through to my native app store, no download and i…

> Not sure I follow. Are you asserting that native apps are easier to update than web apps? I'm saying the processes are more robust. You either have the old app or the new one. You're never left with half of each, and you aren't beholden to random caches about whether or not you get the update. > The combinations are smaller than the combinations of operating systems and phones one would have to worry about. That ca…

> I'm saying the processes are more robust.

I disagree. I think updating a web app is vastly more robust. You update the source, and the only possible issue you have is caching and platform compatibility (the former is a real issue, the latter is mostly alleviated by decent testing).

Updating native apps (due to the next point) is much more problematic because the number of platforms is much higher.

> Most platforms have more than one browser available

Yeah but you can't multiply the number of browsers times the number of operating systems, because Firefox on Linux and Firefox on Windows and Firefox on Android and Firefox on MacOS are (for 99% of the apps) the same target.

> Claiming that web apps are more secure is the most ridiculous thing I've read in a long time.

Are you interested in a real discussion? Or just posturing?

Re: Ask HN: Why is everything in JavaScript changing so fast?

#300

Earlier quoted context omitted.

> We have to rewrite everything in JS because JS is the language that runs on browsers. Not much of an argument. We already have 24/7 internet connected laptops, tablets and smartphones, which is were those browsers run in the first place anyway. Perhaps we could, and I'm going on a limp here, just cut the middleman and run on the metal? If the problem is discoverability/installation/security etc we could focus on ap…

If the problem is discoverability/installation/security etc we could focus on app stores and sandboxes To this day, I maintain that if Microsoft hadn't neglected that essential aspect of the Windows ecosystem for decades, they would probably still dominate the personal computing industry.

Uh...

Oh, you mean 'personal computing' in it's original sense, which encompasses mobile platforms as well, not just desktop computers.

Post reply on HN