3 ms·
Go is well past the point of it mattering whether Google continues to use it or not. I don't think Dart or Flutter are. And Dart's more of a barrier to that le
by OJFord 3y ago
Go is well past the point of it mattering whether Google continues to use it or not. I don't think Dart or Flutter are.
And Dart's more of a barrier to that level of adoption than Flutter itself (if it were somehow language-agnostic, or a multi-platform JS framework even). Tauri has mobile support coming, and once it does with some level of polish, it's harder to imagine Flutter ever getting that popular? It would be trying to convince 'this is a great framework, this is the one you should choose [but sorry you need to learn Dart]' versus 'use whatever [JS] framework you want, you probably already have a favourite'.
- jononomo 3y ago> but sorry you need to learn Dart At this point in my career I'm definitely not intimidated by having to pick up some new syntax -- especially if it is straightforward and sensible.
- OJFord 3y agoMe neither (and I only really have 'it's basically the same as [take your pick]' level familiarity with JS/TS anyway) but I bet my manager planning the hypothetical multi-platform project would be. It means it's either greenfield or a re-write. It probably affects hiring even if I think we'd agree it shouldn't. And it's not just 'learning' it, the language itself, it's library availability and the general ecosystem. Which is obviously a bit of a chicken-and-egg problem or tautological even that '~nobody wants to use it because ~nobody uses it'.
- jwells89 3y ago> And it's not just 'learning' it, the language itself, it's library availability and the general ecosystem. Exactly, there’s a whole universe in a bottle that comes with each language, and I think that is what is the largest source of friction these days when developers consider using a language, especially when the language has little to nothing unique to offer in exchange.
- kryptiskt 3y agoAdding a new language to the stack always adds costs, especially if it's a marginal language. In addition, the migration costs increases as you can't bring in old code. And all your effort is wasted the day you want to migrate away. It's just so utterly pointless, Dart doesn't bring anything to the table as a language and isn't used for anything else. I have no idea what internal Google politics made Flutter go with Dart, but it would have been way better if they had used Go. I say that as a certified Go skeptic, at least that is a widely used language.
- jononomo 3y agoThink of it the other way around: Dart was created for the sake of Flutter. You seem to think that the framework designers at Google just decided to pick a niche language called "Dart" to write Flutter in when they could have picked Javascript to write Flutter in. No. They decided to make the design of Flutter as a framework so clean and pure that they would have to work backwards to figure out what language it would need to be written in and then they created Dart. You're not supposed to use Dart for any purpose other than Flutter -- that's not a drawback to learning Dart -- that's the whole point. An entire team at Google literally created a language to make it easier for you as a developer to express yourself in this domain, and you think that's a drawback? That's like thinking being given a ladder is a drawback when you want to get up on the roof. Sure, you could just assemble a big pile of rubble and scramble up it to get on the roof, and it is true that you might be able to later use the rubble for other purposes (whereas a ladder is built for a specific purpose) -- but that does not make the ladder the more limiting tool. If there is one repeated comment I hear about Flutter it is "wow, it seems like such superior technology, I wonder why it isn't more widely used". To which the answer I keep hearing is "it is only superior for doing the thing it is built for -- it isn't superior for other things." Those who would give that answer consider Javascript, on the other hand, an (inferior) tool not only for this problem, but also for other problems, so it is the more generalizable tool and therefore it makes more sense to use Javascript. The argument seems to be that at least if you're using the same crappy tool for everything then you can claim the efficiency of never having to change your tool. "Only a fool would use the best tool for the job", is the implication of those who disparage Dart.
- jononomo 3y ago> use whatever [JS] framework you want I don't want to have an opinion about which JS framework I should use. I want to worry about the client's requirements and build the software. Having 20 frameworks to evaluate and choose between just means that the entire toolset is less well documented and less stable and no one framework has any weight behind it. And after working for years in JavaScript I just don't like it -- I hate the constant brain-breaking workarounds that other languages solve by just not having the problem in the first place. Javascript sucks.
- OJFord 3y agoI'm no JS fan but this argument doesn't make sense to me - just pick from the big ones at random then? Far more weight behind them than Flutter, and I don't know why they get the higher bar of being 'evaluated' between when Flutter doesn't because it's the only option and you're stuck with it. But anyway if you want to use Dart & Flutter fine just use it? My comment wasn't about why someone shouldn't, it's why I think people don't, i.e. why it doesn't have that much adoption.
- afavour 3y ago> I don't want to have an opinion about which JS framework I should use. I want to worry about the client's requirements and build the software. Taking client requirements and selecting appropriate software is part of the job. Choosing Dart for said project is just as much of a choice.
- lolinder 3y ago> Having 20 frameworks to evaluate and choose between just means that the entire toolset is less well documented and less stable and no one framework has any weight behind it. There are hundreds of human languages in the world, but English still manages to have far and away the most weight behind it. JavaScript frameworks are in a similar boat: all the tiny frameworks together make up a tiny fraction of the total usage. React is far and away the largest, followed by Angular and Vue in a distant second and third. Most of the new frameworks you see on HN are actually layered on top of React, which means they're contributing to its weight, not detracting from it. So, if you want to make a decision based solely on weight, straight React is a no-brainer. If other factors matter more, then you've got other choices with different trade-offs.