[1] http://blog.vizuri.com/creating-your-own-angular-material-na... [2] http://stackoverflow.com/questions/28389671/create-a-menu-li...
Let's talk about Material Design Lite. Go check that website, especially the components page (https://getmdl.io/components/index.html). It's really nice and responsive, try changing the size of your browser window and see how the navigation bar collapses to the top. Damn this looks like a great framework, I'd like to do the same thing in my app. Imaging the surprise when you can't actually do that using the framework out-of-the-box. Oh by the way, forget about MDL, all the developers have moved on to Material Components for the Web (https://github.com/material-components/material-components-w...). So much for the guys who just want to hang a door, there's a new brand of screwdrivers on the block.
It would be great if the so-called "engineers" could spend some more time creating a complete toolbox instead of reinventing new screwdrivers every month.
- You don't have to learn every new framework. Google has 10k+ Angular 1 projects, this stuff doesn't go away after hitting critical mass.
- This constant iteration has lead to multiple production-ready UI paradigms that were just relegated to FP research. Try using Angular 1 or vanilla React, and then do something with vanilla Android. Or GTK+. Do we want GTK to be our baseline for UI work? Qt is nicer, but it's definitely playing catch-up.
You can poke fun, but there's a reason everyone opts for things like Electron. It's the most satisfying way to build frontends for a lot of people.
And the only satisfying thing about Electron, is hitting package and getting three platform-specific binaries. Otherwise, it is still web frontend development. In contrast, I have had the pleasure of doing desktop development in Qt and WPF, which was quite enjoyable (and the ecosystem has not changed a lot since I left it years ago).
Also, MVC and MVVM were UI paradigms before web frontend development. And I am quite sure I heard about ReactiveExtensions before Facebook React.
Yes, vanilla Android is terrible.
And I’m just sitting here, using https://github.com/ReactiveX/RxJavaFX
And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
https://docs.oracle.com/javase/8/javafx/api/javafx/scene/con...
> UI bindings require a lot of manual converters instead of doing conversions that p.e. WPF does out-of-the-box (like double to string when using a text box; principle of least surprise).
You can use String.valueOf, but usually don’t want to do that. And how do you want to represent the float? With Scientific notation, Engineering notation, or purely decimal? This is not simple.
> And (the worst) it's not conceptually compatible to the model classes (abstract tree model) that almost every UI framework (including Swing) provides. Instead, tree nodes have to be manually instantiated).
Or you use the FXML bindings for creating them from XML?
I'm not convinced it's particularly good reasons. I think ignorance of native GUI coding and the old, "When all you have is a hammer, every problem looks like a nail" mentality has a whole lot to do with it.
> Guess what? Angular Material is dead. All the developers decided to start over with Angular Material 2 because there's a new screwdriver brand in town: Angular 2.
I think an important lesson from this is to be careful about the tools you use. If a particular company puts out great tools but changes them in incompatible ways, you might end up having to go back and rehang a lot of doors.
Yes, Google could have handled those projects better, they could have put up big warning signs that they are "deprecated".
I think it was a good move to recognize how unmaintainable things (can quickly and usually) become with angular1 (or with anything that is a mess of a hundred semi-external JS libraries), hence TypeScript.
Virtually any mainstream language is capable of building performant, maintainable, reliable code. Virtually no developers are capable of creating performant, maintainable, reliable code. After decades in the industry and generations of new whizbang tools, libraries, and languages I've come to terms with the fact that the problem is "us." I've seen exactly one significant sized application keep those 3 qualifications for more than a couple of years. Once all the original core developers on the project moved on, it was less than a year before the code base was a total mess.
I think what you're really asking for is a tool that forces you to build performant, maintainable, reliable code. I'm not sure that's entirely possible until we get AI writing and maintaining its own code. Humans suck.
Do u care about what language Amazon uses to write S3? Do u believe it is the language that make S3 succeed, or fail?
Even as a programmer, as to the other services I am calling, things I do care about involving their stability and correctness that affecting my work. I care shit about what how they write their service underneath, may it be cool or dumb.
If I'm running a business that lets say develops an ecommerce platform I won't be too impressed if my developers are using assembler. Java good, but if Scala gives them an edge and cuts my costs so much the better!
It's enlightening to me because a lot of what we consider "hard" or "too academic" is actually our own prejudices speaking. Of course it looks like that to us, coming from Java, but try talking to someone who learned Scala first :)
I also find it encouraging. Maybe some day we will be able to finally take advantage of the JVM without the weight of Java-the-language.
I think we're starting to see a new phenomenon: people who don't start on the JVM with Java. It's interesting because it shows (in my opinion) that the whole "Scala is too difficult" thing was mostly a misconception. What it was truly all about was: it's hard to give up old ways of thinking :)
That said, I love Haskell and would definitely enjoy using it at work, but it's a no go for "political" reasons, which is sort of reasonable even if disappointing. Scala scares management way less than Haskell!
That's true, but we've been in the region of diminishing returns for programming languages (I'm not talking about runtimes) for a long, long time now. To go back to the (bad?) tools metaphor, it's like saying that unless you're using nothing but your fingers, you DO care about tools. Well, yeah, but once you have a decent screwdriver, innovation in screwdriver technology -- short of a revolution -- is likely to yield diminishing returns on investment, especially as the cost of adoption remains high. Switching from, say, Java to Scala is not much cheaper (if at all) than switching from, say, assmebly language to FORTRAN or C. This does mean that the effort spent on switching languages (or screwdrivers) should decline.
And just to be pedantic: When I bought my first SwissTools Insider[1], I realized that it's actually still possible to innovate in screwdriver design. That doesn't make them better for every task, but hey, that's the way it is.
[1]: http://www.pbswisstools.com/de/werkzeuge/quality-hand-tools/...
Architecture will generally not be. Scala and Java encourage building applications in different ways. That doesn't mean one is better than the other (though I'd argue you could make that claim), but some problem domains are better modeled with Scala, and likely some with Java. And some programmers work better tending toward a pure, immutable, functional style, while others work better with OO, side effects, and mutable data.
While choice of language/framework may not be as important as many other choices you need to make when building an application, but it's not something that should be dismissed as irrelevant, either.
That's something that holds across all fields of engineering and art.
The screwdriver analogy is right on a lot of levels. Is it so hard to accept that software developers is not some unique snowflake position that cannot be compared to any other job?
Besides, if all you do is to fix a door than you may be right. But we build entire tower blocks, with doors, windows, elevators, ventilation systems, structures able to hold up tons of material, and all the rest. Your screwdriver metaphor may be good go way to score a cheap point with strangers on an internet forum, but not much besides.