Hacker News Reader

Comment by leerob | Hacker News Reader

As someone who worked extensively with Dart in a previous role, I'm not sold on Flutter.

For the vast majority of use cases, JavaScript (or TypeScript) is going to be a better solution than Dart.

Like it or not, JavaScript is the #1 player on the web and if you're trying to scale and share resources or code at all, you want your engineers to be proficient in JS. Yes, Dart is similar, but it's not JS. And it's not _just_ the language: it's the ecosystem. Linting, formatting, package managers, debugging issues, Googling problems, Stack Overflow answers, etc.

Also - Guess how much of that Dart specific knowledge was useful in my current role? None. It's gonna be hard to hire devs who want to work on Dart IMO.

My opinion: You can have Android, iOS, Web & Desktop with 95%+ code sharing between them using React Native + React Native Web -> https://github.com/devhubapp/devhub

View on HN

Like it or not, JavaScript is the #1 player on the web

In a decade, Apple has had little trouble convincing developers to take up not one but two weird languages statistically nobody was using before. I don't think the languages themselves (and even their ecosystems) are what drives or fails to drive adoption.

I thought it was a truism in tech that monocultures are a bad thing?

JS might be the #1 player, but there's no reason to be against attempts to challenge the status quo.

IMO the problem is that Dart is pretty much JS and really not challenging the status quo - My light experience with Dart is JS < Dart < TS. So if there's an opportunity to simply use TS, I don't see the benefits of Dart.

AOT and JIT compilation and the fast hot reload and performance in general of dart/flutter seem to absolutely trump JS/react native.

> there's no reason to be against attempts to challenge the status quo.

Now try justifying that ideology to upper-management :)

> I thought it was a truism in tech that monocultures are a bad thing?

There were so many benefits to the PC compatible/DOS monoculture in computing. Competition drove down prices, the need to be compatible meant that many new advancements were done in a standardized way, and everybody got a flourishing software ecosystem to use. Monocultures come with _tradeoffs_, but you could argue that without a few of them coming along at the right time, computers would be way behind where they are now.

>Like it or not, JavaScript is the #1 player on the web

Are we talking frontend or backend here? Historically JS has ended up 'king' solely because it's the only language browsers support - but do you not think WebAssembly has the power to change things here?

And on the backend... I'd dispute that it's used for a majority of backend applications. Perhaps a majority of new applications?

JS is a much better compile target than webassembly for managed / GCd languages for the foreseeable future.

Google seems to be commited to Dart, since they already developed linting, formatting, package manager, support for multiple IDEs... As a native iOS developer, I can say that I'm very impressed because Apple did none of that for iOS.

Dart is meh, but because Google owns it, they can change it to Flutter needs (and they are already doing that). I can see it becoming very nice language in few years, but right now it's good enough.

GHCJS is mature enough to write production frontend apps in Haskell. JavaScript is not required.

Try: https://github.com/obsidiansystems/obelisk

Example app: https://github.com/srid/Taut

NPM is enough reason to not use javascript but I haven't touched javascript since introduction of typescript.

Why? NPM is a fantastic package manager.

But a disastrous registry

NPM introduced a new type of code injection.

Could you explain the code injection vulnerabilities present in NPM that other package managers don't have?

Not the OP, but my understanding is that the problem is a matter of practice: there are so many tiny packages with such complicated dependency graphs that the exposed surface for attacks is two steps past gigantic.

As someone who doesn’t use much JS/npm, but who did work with dependency graphs in software systems in a former life, my (largely academic) study suggests that this is an intractable problem in npm — that is, a solution is such a big change from npm foundational usage that it’s far more likely to be solved with an npm replacement than an npm change. I would welcome sources that either refute or confirm this.

The performance was poor enough for long enough (and continues to be, probably?) that more than one third party implementation came along to replace it. There's no real reason that NPM can't be as fast as Yarn, except that it isn't (or wasn't? I haven't used it for enough full-size projects lately that I would know whether or not it's gotten better).

What are you using instead of JS for web development?

If you really dislike NPM that much, GitHub might be here to save the day.

https://github.com/features/package-registry

Like I said, I'm using typed javascript (typescript) with some webassembly where it make sense, I am not trusting my own code without typings.

I have absolute no idea how to fix package management for javascript, NPM has its own problems that long fixed by other package mangers for other languages, it been years NPM still broken.

Reply on news.ycombinator.com