There's a ton of good reasons to replace Android beyond licensing. Security being the largest one. Fuchsia is designed with security in mind from the ground up, Android arguably is not (at least not from the sense of what is considered security today).
Open sourcing the product will help the competition to catch up quickly, all they have to do is take googles product and change its look. The next half is infrastructure, which companies like Microsoft, facebook, amazon, alibaba all have. Plus services like AWS will help future version of dropbox & netflix.
A good example of that is Visual code. I am sure some at github (atom's paprent) is pissed.
The OS Fuchsia, including the kernel Magenta, appears to be open source, mostly under BSD 3-clause, with parts of the kernel under MIT and similar licenses.
Handset vendors and, especially, mobile network providers, would rather ship their handsets with proprietary unmodifiable software that they can cram with antifeatures that will be that much harder to detect or remove.
Having said that, the reports I've seen contain scant actual evidence that Google actually plan for Andromeda to replace Android, or even that Andromeda is at all important to Google. I take these reports with a mountain of salt. I remember that the "Pixel 3" was definitely just about to be announced back in late 2016, and was definitely going to be running Andromeda OS.
GCC is still in the NDK today because some of gnustl's C++11 features were written such that they do not work with Clang (threading and atomics, mostly). Now that libc++ is the best choice of STL, this is no longer blocking, so GCC can be removed.
I believe the article over-sells Fuchsia's use of Rust. Raph Levien wrote some bindings to the OS runtime, and he does work at Google, but his Rust work is not-official.
Which is a shame, they are missing an opportunity to ditch C/C++ in favor of a safer language and set a precedent in OS history.
Imagine how easier contribution would be if you could write the OS parts with less lines, guarantied to no introduce most security and concurrency bugs we know about.
We definitely need a universal OS for all our devices and I really believe Google is in a great position to get us there.
It would really surprise me if Apple got there first. Tim lacks vision and will keep on milking iOS even if the iPad Pro is a failure as a laptop replacement.
Windows is still king in the desktop space, at least as far a user base goes, but it's terrible on tablets and phones. MS has all the tech in place with UWP, but it's still pretty far in the race in terms of simplicity and usability.
Chrome OS ticks all the right boxes, and is experiencing a huge growth, but it's not universal. If Andromeda is real, and it's able to become a universal OS that merges Chrome OS and Android it might be the best thing since sliced bread.
Terrible on tablets and phone? Phones I can agree with but the surface line is getting to be really solid. I've been an iPad guy for years and my next tablet will be a surface.
A surface isn't a tablet, it's a laptop with a touch screen. I've tried them and they are really nice as laptop but they fallback to a finger hostile UI way to often to be called tablets.
I had a Surface Pro 4 for a while and it is really great for the first few weeks but when the honeymoon period is over, the warts start to show. Slowly but surely I gravitated back to my iPad and laptop. The day the SP4 went back to Costco was when I realized it had been collecting dust for over a week.
Yes, we do. I want my phone and my laptop to be in total sync, I want to be able to write code on my mobile which I can just continue on my laptop without any hindrance, currently I have a mac and an android phone, I do have Go and Python installed on my mobile, but it isn't that great to code on my mobile, I have to host the repo on an internal version of gogs to get the code synced up and I still have to manually push the code around.
You could always develop remotely, use your phone to ssh into a more powerful machine. Use tmux or screen and pick up right where you were on a laptop or desktop. This is far more compelling IMHO.
To be usable, SSH to a more powerful machine requires a good and stable connection. That's almost never available, in my experience. If I'm on my phone, I'm likely to be on trains/planes/in tunnels/in the countryside/etc.
I remember the glee of the first time I got an X-Window application to run over the network. I was so confused though because the "x-server" is the software you run on your client machine.
There is a small terminology issue here: a "server" is a program that offers services to remote "client" programs. The clients make requests and the server responds to them. A client program will make a request like "allocate me a chunk of the screen and put these here bits in it", or "let me know about any of these events that happen". The server manages the screen and notifies the clients about things they're interested in.
I agree, it actually does make total sense - but that doesn't mean I won't get confused :).
My only prior exposure to "GUIs over the network" were web applications, where the roles are essentially reversed. That is, the part responsible for accepting user input and rendering the UI is the client (the browser), and the part that performs the application logic is the server.
I naively assumed that X would work the same way, but it wasn't too hard to unlearn that misconception.
But I don't have an iPhone, I have an android phone, I use syncthing, but this isn't the kind of sync I hope, I want both the OSes to be quite same with inbuilt sync not through the internet but through my LAN
Apple will never outright tell you this but the answer to that is "you're using OSX wrong". I really think for best results you have to be vertically integrated and have Apple gear for all things you want to work together and to do it well. If not I guess rely on someone making a third party app that does what Apple does for its devices.
I have syncthing for syncing files, that isn't an issue. I want a universal OS which allows me to just plug my phone into my machine at home and it'll do magic and I can then continue my work. I have no other alternative than reading when I am on the bus. I want the mobile to be a native extension to the laptop
Yes, for a beginner who does not need the advanced stuff, they can just ignore it right?
As of now, I never use Google drive sync, I use syncthing to sync folders between mobile and my Mac.
Universal OS rocks! (I hope it is in line with my vision of how the concept of universality is) I want to just visually ssh the phone and the machine, or rather the OS is in the phone and I just connect it to the machine, there was some project recently I don't know if it is available now.
I don't know why the downvotes, but your "beginners can just ignore advanced stuff" comment strikes me as naive.
Beginners are typically terrified of anything they don't understand. I used to teach computers 101 to university students, and they'd pretty much freeze up every time they saw something they weren't expecting.
Why naive? I was a beginner 3yrs ago in web development and Go. I wanted to learn how to build a webapp (I didn't and still don't know enough JS), I didn't get lost in the big maze of angular, react. I ignored the complicated stuff, I learned how to write a webapp[1], that was using pure HTML, then I learned Go, then I wrote a webapp. I wrote a todo list manager [2]
Then, after I was comfortable with everything did I start learning AJAX, I chose Vue.JS and I migrated the app I wrote in pure HTML to use Go [3] and wrote a guide about it [4].
I pissed a lot of people of VueJS project when I raised this [5] issue, yes, in hindsight I do realize that I was rude to them, but their documentation had a problem (and I had already said sorry if I was rude)
I still don't know how to use websockets and what not, or how to write load balancers or distributed database, or web proxy or cache or other things to be done at scale, I choose to ignore them as of now, as I build my capability to understand or until I need of them.
This is what I meant by that statement.
>they'd pretty much freeze up
You know, in 2010, I still remember the first C programming class (I had not understood a single word) I had in my college, I froze and for a minute questioned if I had made the right decision to enter computer science. The point is that newcomers need to know what they can ignore while they learn the basics, it is not possible to learn everything in one go.
Nobody teaches you real life, it just happens, and as a newbie it is my responsibility to learn in the best way I can without getting overwhelmed, and no, it is not a disparaging statement!
Also, this is why I started Multiversity[6], this is a YouTube channel which teaches by example.
This is what Smalltalk was intended to be, back in the day. The answer is yes, but you may not be able to get more than a few people to adopt it anyways. (There were no smartphones back then, but it did get to the point where grade school children, professional developers, and researchers were using basically the same programming environment, just with customized interfaces for their particular group.)
Why stop there? I want to dock my phone to the TV and work with a remote control, I want to dock it to the car and control it with steering wheel buttons.
I'd say to have a common interface towards hardware that is quickly becoming similar across smartphones, tablets, and even laptops (read Chromebooks)?
I think why they would _not_ have the same interface between similar hardware and similar applications is a better question.
As for the user interface and bundled applications, let's not confuse "Operating System" with that although it's popular for some stupid reason. The one and same OS could of course have e.g. completely different window managers adapted for different human-device interactions and use cases. But that's very distanced from the actual OS, that is pretty much only interested in how to run and expose the hardware to the software.
You may "definitely need" a universal OS but I'm far from convinced I do.
I don't buy that a finger and a mouse/trackpad pointer are equivalent input devices. One obscures the display and is imprecise. The other, well, isn't.
I'm fine with a different server OS than desktop. I see no compelling reason why I need a single OS for all of my personal devices.
Not only does the OS UI reflect the input method, every single application you run does as well. A touch-optimized application will be clumsy and primitive when using a mouse; a mouse-optimized application will be miserable when using a finger.
If an application can be written once for both, often it'll be a poor compromise or only properly support one of the two input methods.
Look at how awful early Java "write once run everywhere" applications were. Yes, some of that was the Java platform itself, but developers were given the opportunity to ignore platform-specific UX concerns and many eagerly embraced it.
I think a single platform for all our devices: mobile, tablet, desktop, etc, is a mistake. The word platform means more than just the OS and includes the entire L&F/experience with the UI.
I think a single OS for them all is fine.
Consider gnome+linux vs android+linux. They're both linux, and they're not the same platform.
Again, the problem is pretending to use the same UI for all input methods. And I agree that is a mistake.
But what if you could use the same language and frameworks on all devices? The same tools (IDE, code editor, compiler, etc)? That's what I'm referring to.
Does Tim lack vision, or does he just not share your vision? You might think we "need" this but not everyone agrees. Combining Chrome OS and Android is uninteresting to me, since I wouldn't be able to develop on it or really do any of the things I use a computer for. Unless they plan to really build on it and attempt to compete with more mature desktop operating systems.
He lacks vision, not because he doesn't share my vision, but because of everything he has done in Apple. That's not to say he is a bad CEO, he isn't IMO, but he is only polishing the same ideas from 10-15 years ago. I'm not even arguing that's a bad thing per se, it's just how things are.
Also, I really don't see how a developer could argue against the notion of having a single language, API, IDE, compiler, etc, for working on all devices.
> Combining Chrome OS and Android is uninteresting to me, since I wouldn't be able to develop on it or really do any of the things I use a computer for.
As much as I'd like to see it, I don't think Windows will ever quite get there. Not, at least, in any recognisable form. They value backwards-compatibility way to much (which is to be commended in some ways, but won't save them here).
While they seem to have everything lined up to be able to turn it into something, developers seem too reluctant to get on-board too.
Apple will have to go through all of the growing pains Microsoft has already weathered, so they're miles off, but maybe they can do it faster because they don't care as much about what people think of them, and are willing to do whatever they think is right (if it is or not is to be seen).
Google is well placed because, while they have a bunch of platforms, the only one in the desktop space is basically dead, and really didn't ever have too much investment in it, so not too many feel put out if they get rid of it. But that not even the case, because they're able to engineer everything so that it stays relevant.
> developers seem too reluctant to get on-board too
Might be limited to your specific environment though. As a counter-example among the people I know there are far more .NET devs than the total sum of iOS/Mac/Android devs.
I'm not referring to .NET. I know tonnes of people getting on board to .NET train. I'm referring to the UWP apps. Nearly no one seems to be getting on board that.
Operating System is about applications. Even if Google comes up with a universal OS there will be many applications that only run on Windows forcing people to continue to use it
And this is why we need an open source clone of Windows, which is king of the desktop OS. Beside geeks, the average people doesn't care about operating systems, they care about being able to run their apps.
It's sad that ReactOS doesn't get more support from the community.
I think there are several different characteristics that make us categorise a device as a tablet vs. a laptop, input methods being just one of them; there are many others e.g. form-factor, weight, battery life etc.
How many touch optimized apps are on the Surface? I haven't seen many. The majority are still desktop apps and using desktop apps on a tablet isn't a very good UI experience.
Yes I know where you are coming from but as I said in another comment I don't think that the input method should be the main element that defines the difference between a laptop and a tablet.
Exactly, Google is in the best situation. Their Android is by far the most used OS/shell (world wide market share).
Apple's CEO lacks the vision and is milking the status quo. Their iOS market share is a lot smaller and limited to a few devices.
Microsoft's CEO lacks the vision and is aggressively milking the status quo. They aggressively try to enforce a switch to software-as-a-service plus they are no in the gray adware/spyware business capturing way too much end user data which shades bad light. And the killed their QA. Their products since 2010 are a disaster. That's why XBoxOne tanked in all market beside US, WinPhone tanked world wide, Win8 and Win10 marketshare is lot smaller than Win7, which is the major desktop OS - and there is little reason to switch away from Win7. MSFT would profit from a 180 degree U-turn with a new management.
We don't need a universal OS. I'd go as far to say that a universal OS is bad. A universal OS leaves no place for experimentation, no place for different UI concepts, no place for people to customize things to the way they want. Would you really want every shirt to look the same? Every refrigerator, every door? Style is important.
Do you really want Google, that has DNS, fiber, search engine, emails, calendar, phone contacts, ads, deep learning, app store, CDN, analytics, web browser, maps, power plants to ALSO handle your desktop OS ?
That seems very, very dangerous to me.
Actually we already are in the red zone, I just wish we don't go crimson. But I doubt people will care. They didn't up to now, no reason it changes.
Article author here. Posted this in the notes, but possibly too buried:
For anyone interested, I intend to write quite often about consumer technology on this blog. Topics will include hardware, software, design, and more. You can follow via RSS or Twitter, and possibly through other platforms soon. Sorry for the self promotion!
Thanks for reading. Please do send any corrections or explanations.
I have nothing constructive to add aside from that I appreciate the simple uncluttered design of your blog. The typography and glasses logo are very pleasing to my eyes as well. Good luck and I look forward to reading more.
Very nice article but I found the washed-out text hard to read on my phone, which is a 6+ so it's a decent size. I actually gave up and pulled out my iPad.
Great first post, hope you keep it up! Only feedback is that I had to reread this sentence several times before I was confident I'd parsed the negations correctly: "I also can’t imagine the Android update problem (a symptom of Linux’s modularity) won’t at last be solved by Andromeda, but one can never be too sure."
Wondering what your background is as you state you're not a programmer but you can obviously parse code (at least at a high level) and have familiarity with the OS ecosystem. Market research? Great analysis btw.
I think you alluded to this, "cue endless debates over the semantics of that, and what it all entails," but it might be worthwhile to add the official statement.
But there are frequent commits to multiple repositories on the fuchsia code base[1]. I don't really see where Google is going with this, if it's neither meant to replace chrome OS or Android.
Maybe a long term project? I think Google is at a position where they can write a great OS from scratch, learning from the mistakes of others, and it has a chance of becoming the greatest OS that ever was.
With the talent of it's engineers, they can bring new ideas that can be better implemented, from scratch on a new OS. They already have a bunch of languages, web frameworks, and so many more technologies from Google that can be well integrated in this.
And looks like the project is mostly BSD licensed, which is great! I'm excited for just that alone.
This is like Apple saying they are committed to PPC right before they announced the intel transition, or Nintendo stating that "The DS will not replace the GBA". If they become successful in building that OS, that statement will be thrown away as something they had never said. If they stumble upon roadblocks while trying to build this, they will have this statement to back them up.
Is this an actual plan of Google as a company, or is this some sort of Microsoft-style war between divisions where the Chrome team has just decided on its own that the future is based on Chrome and Dart?
Also, considering the way that the ARC runtime for Chromebooks was a failure and had to be replaced by a system that apparently essentially runs Android in a container, will it really be possible for a completely different OS to provide reasonable backward compatibility?
I think Google just wants to transition to an OS with a micro-kernel architecture with the smallest possible attack surface. Also, user space drivers should help with the update problems they've always had with Android.
I would say that Google is trying to replace JavaScript with dart in any way they possibly can. The reason is simple, JavaScript is an open standard, dart is owned by google.
Their reasons that "dart is better" is the typical google koolaid before they attempt a market takeover. As we've seen over and over with Android, chrome, and AMP especially. Google loves to make glass house open source projects you can't touch. You're free to look at how great it is, feel it's well refined curves and admire the finish, but God help you if you don't like how the project is going and want to fork it for yourself.
Don't bother trying to commit a new feature to any of Google's software that they don't agree with. It will languish forever. Don't bother forking either, because they'll build a small proprietary bit into it that grows like a tumor until it's impossible to run the "open source" code without it.
Fuck dart, I don't care how great it is. Microsoft is being the good one in this case by extending js with typescript, google is trying to upend it into something that they control
Yeah, you can fork. Take AMP or Android for example.
With AMP, the instant you fork and change a single character of code it becomes incompatible because part of AMP is a verifier that makes sure only the official version is used with Google's cache. Without being able to serve your custom AMP pages from Google's AMP cache the entire point to its existence goes away. The reason? Typical "security". "Tampered" versions of AMP could "do bad things", laughable considering that vanilla web pages allow you to do absolutely anything javascript allows and google has no problem showing those pages in search results or letting them freewheel in a Chrome tab. If Google wanted AMP to be open they would have built it into their chrome browser so the browser could enforce restrictions while allowing users to run whatever customized AMP implementation they want.
And Android. Android used to honor the promise of being open. Years ago. This was before every manufacturer was encouraged to lock bootloaders, and back when platform SDK's and drivers for hardware were generally available even if they were kinda hard to get. This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.
Nowadays you can only run your own Android on devices specifically built for it. Open distributions like CyanogenMod are dead or dying. Google Play services is closed and proprietary, and probably about 95% of popular apps require it to work. Even if you manage to get your own Android distribution built and running you will need to side load all your apps, and most apps just don't work because they've been built to depend on proprietary bits that Google has snuck in all over the place.
Google is better at the "embrace, extend, extinguish" strategy than Microsoft ever was. So good, in fact, that they have many well intentioned people defending them to the death even as they choke off the very open source projects they created. Virtually every platform that Google runs for more than about 5 years goes from completely open to something impractical to run yourself. If you don't believe me look into any of their older projects that are "open source".
After a certain point it's free software as in "free coupons". Somewhere in the mix, eventually, the price of of their "charity" is passed on to you.
Thanks so much. I get a lot of downvotes and use throwaways because of comments like this, so it's nice to hear some praise every once in a while.
Google's projects all seem very inviting from a distance. Usually it's not until you're ready to implement something that you find out that you're fucked, and how.
Serious ranting below but something I never get a chance to say:
I'm a born skeptic and avoid the silicon valley mindset even though I'm a driven person. I used to find myself often in disagreement with others because they don't or refuse to see the truth. Some people don't like to be told they're wrong. Many of those will fight other opinions just to justify their own decision, but will secretly reconsider. Others will hang onto beliefs with every ounce of strength as their mistake builds into a Maelstrom that consumes everything they care about.
With some people, after challenging their beliefs, they will end a friendship rather than admit you were right in the first place. Especially if you refused to do something their way and it saved them from disaster. Some can't stand to be THAT wrong. As if I was some asshole who saved them from their fate, and now they're a spirit left wandering the earth until they can fulfill their original destiny. Its like I helped them cheat without telling them about it, stealing the joy from victory. This is something I learned the hard way more than once.
In real life I keep my opinions to myself to avoid this nastiness, and offer opinion only when asked. The people open to advice even if they disagree learn to ask my opinion since I always tend to have one. The majority of people I know, including some good friends, have no idea what my personal opinions are on many subjects. It would cause pointless pain and argument with people I care about regardless of their beliefs.
I'm not loyal to any platform or company and I will freely throw a strongly held notion to the wind if I find disturbing evidence that I was mistaken. Most people are not so malleable.
A lot of people take their beliefs too seriously to the detriment of society. At least on the internet I can express my opinion, however "uncool" using throwaways.
In the real world the best and most meticulously researched advice I've ever given is at exit interviews. The one time you can be open, honest, and politically incorrect with coworkers. Multiple companies made serious operational changes after giving my exit interview. Others have told me in nicer words "that's really fucking great to hear I'm pretty happy I never have to talk to you again".
The problem is, you never know how somebody will respond. During exit interviews I'm treated more like a person than a subordinate since the boss relationship is formally over, which helps I'm sure.
In real life, the way to influence a strongly held opinion is best decribed by watching the movie Inception. You introduce nothing more than minor inconsistencies while outwardly expressing little opinion, then wait to see if your clues are enough to lead them to towards the promised land.
My other common tactic is to do things without asking any opinions first. You at most come off as insensitive, aloof, rather than someone to intentionally disregard their advice. Usually the opinion matters less in practice than if you had asked in the first place. Classic forgiveness is easier than permission.
Ive sometimes wondered if this makes me a physcopath or if that's just how some people tick. Anyways, god bless throwaways and the internet
At the risk of down votes, I'll be as blunt and honest as you claim to be - after reading this screed - you mostly come off as a someone with an inflated view of your own importance and abilities. While I might agree with you that the silicon valley mindset is harmful - anyone who would rather keep a friendship and watch a friend go over a cliff in a barrel, isn't really worth keeping around - either as a friend or an employee.
Fighting the good fight, fighting for the things that are just, and true, and good - are nearly always worth it, the key is to back off before it becomes a pyrrhic victory.
I think parent poster is using the term "friend" in a more liberal sense. I would counter that anyone who you're afraid would berate you for honest feedback can't honestly be considered a "true" friend. In most cases anyway. Even then, some people just have to learn the hard way.
I'll save somebody but only if it's worth the cost of losing a friend. The better the friend the more I let them learn from their mistakes. The truth is that losing a good friend would hurt us both more than helping them mend the wounds after smaller stuff.
It's not being evil or that I'm always right. The comment was mostly in reference to those that have been calling me a shill the past few days and how they should keep in mind that their opinion is not fact.
I gave up the good fight years ago. The worst was when I helped turn around a failing small business. We all wanted the same goal, the company to be successful. It sucked so bad that I learned that it's better to be nice to your friends than to dedicate yourself to a cause or try to fix all their problems.
If that means letting them fall sometimes that's okay, as long as you don't let them get any deeper than you can reach. If you help pull them out in the end you're still a good friend.
So the company turnaround, it worked in the long run but at great cost. Cutting employees that sucked at their jobs but were friends and helped us with the initial plan. Cutting moochers that I loved but were sucking the company dry with constant unscheduled time off and freebies. Redoing our systems to automate as much as possible made us our first profit in years but a lot of that was from jobs eliminated. Hiring people of a higher caliber than existing employees by raising application requirements above what most of the current employees would meet. Offering our new more qualified people more money than Bob who's been here for 15 years but did our financials on pieces of scrap paper.
By the end of that process a few years later, my lesson was that I made the owners a lot of money at the expense of losing about half my friends. Most of the other half resented me for what I had done and thought I was a traitor, even though I had just helped implement exactly what we had agreed upon a few years back.
We planned to cut dead weight and streamline and automate operations. To add new talent with up to date skills. To cut our benefits slightly to money to invest in the company's future. Everyone wanted this until it was their benefits or their job being automated. I followed through with the cause and at the end I felt like a Judas figure and packed up and left in shame.
You could say it was a pyrrhic victory for sure, but after that I'm very wary to set anything in motion that's too heavy for me to stop on my own
I agree with a lot of your sentiments and am only responding to rubbish your psychopath claims. I don't think you need to worry, in particular if you don't exhibit cruel or violent tendencies. You demonstrate concrete moral reasoning, even if at odds with others, so not sociopathic. "Psychotic" perhaps but your reasoning seems lucid enough. The one reservation I would have is about your "omega man" mentality; that you could be suffering unescessary mental anguish as a result. Also if I were operating an online community I'd be somewhat concerned with your obvert circumvention of moderation checks and balances using throw aways etc. However - I think you're submitting perfectly valid opinions in a respectful way and I share your unease at how there seems to be a groupthink at play shaping the quality of discussion.
Hahaha psychotic ish ramblings are fun to write sometimes though :). I'm about to retire this throwaway so IDGAF about what I'm writing as much as usual.
Omega Man is an interesting term, never heard of that before. You're totally right that it's how I try to operate but only when I'm doing controversial things. Perhaps I'm doing it right if I seem to be going about it in the most quiet and passive way possible :) .
You don't have to worry about me running any communities online. I'm a productive member on a bunch of online communities including HN and I don't use my throwaways to respond to, upvote, or otherwise sockpuppet my regular account except a couple times I admittedly may have upvoted the same thread on different accounts by mistake. Most of my less opinionated stuff is under my real name
The only reason I respond sometimes is because I disagree. Sometimes my controversial opinions prove to be a lot more popular than I thought. And possibly miraculously, all of my throwaways eventually gather substantial positive karma despite the fire and brimstone rained upon some of my comments :)
Glad to hear there are similar minded folks out there. These days I mostly just shut the fuck up and do what I need to do. Besides, if everyone listened to my advice, I wouldn't have the advantage that comes with the foresight.
Hardware made a big difference with Linux and its growth. It could run on PC/x86, alpha, sparc because those are platforms. ARM is a spec sold to manufactures that all have their own SoC that attach random shit to random pins and implement the worst kernel hacks that can never be upstreamed.
We can't have the 90s Linux revolution for handhelds because they each need customized kernels and drivers. Many fall into disrepair and go unmaintained, even in things like Cyanogen. (On two phones I tried running newer CM images on old hardware and ran into speed and performance issues).
This is why things like Plasma and Ubuntu mobile have such limited phone support. Porting is difficult.
Also notice that I said "PC" above. There are plenty of x86 systems that are just as difficult to port to (PS4, Wonderswan, those old T1 cards with 4x486 processors on them). At least Microsoft forced their ARM manufactures to use UEFI. Too bad those platforms have locked bootloaders. I'd love to see some Lumia running Plasma.
> This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.
How diverged is it? Would the ever be merged back together?
Last I checked some devices were running mainline kernels many years old, like 2011, with zero code back to mainline. One of the other posters mentioned rampant hacks to the kernel to get things to work in stupid ways which I've heard a lot of as well.
Android is missing a ton of new Linux features on many devices and the kernel is getting increasingly unusable by ARM devices in vanilla form because of these badly done third party modifications
First up - I do not argue with you. Android is not as open as it was in the old days. But I think its not fair to only blame Google here.
Google making Google play services was a natural reaction to manufacturers never updating Android on their phones for years leading to all kinds of vulnerabilities and bugs on Android that kept it far behind iOS in quality and features. Lets face it - Android used to be sneered at, the red-headed problem-child OS that used to the butt of jokes till it grew out of puberty and pimples in Ice Cream Sandwich. If manufacturers had truly honoured OS updates, Play Services may never have been built - it allows Google to update Android without updating the OS. And yes, they will retain full control over Play Services - I completely understand the need to fully possess it and ensure a high level of quality assurance.
Also blaming the fall of CyanogenMod on Google is ridiculous. CM fell because of mistakes made by Kirk Mc Master and several others. He attempted to be a dictator even going to the extent of banning OnePlus phones selling in India - this was fought and resolved in the courts. All goodwill for CM was destroyed. OnePlus ditched CM and moved to Oxygen OS. CM had a stroke and died. Now Lineage is the new shiny OS rising from the cooling corpse of CM.
Interesting info about CM, didn't know there was more to it.
I still disagree with play services because it wouldn't be that hard to force manufacturers to support updates when you command such a large part of the market
There are these things called contracts, and if there are clauses for an OEM to be allowed to have access to Google services, Google lawyers could certainly add a few more sentences regarding compulsory updates.
Android is open source, and OEMs see long-term updates as a money-losing proposal. If the "lost sales" (to them) costs outweigh the benefit of shipping Google services, OEMs will fork/ship AOSP and call it a day - they want profits more than they respect/fear Google. Google's negotiating position is not unassailable.
It sounds like you have no idea how deep Google's MADA contracts with OEMs already go. =) Shipping devices with Google services included requires you sign over your entire business decisionmaking to Google: They have approval/veto power over every single device and software update you release that contains their services, and they also forbid you to sell any devices running Android that don't contain their services, just to make sure you don't try to exert any independence on the side.
Android isn't open source, except in the hearts and minds of fanboys everywhere. =)
>And Android. Android used to honor the promise of being open. Years ago. This was before every manufacturer was encouraged to lock bootloaders, and back when platform SDK's and drivers for hardware were generally available even if they were kinda hard to get. This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.
The only thing Google is directly responsible is Google Play Services, and
1. A good of that is a shim to Google's servers.
2. Is small and emulate-able (especially if you don't really intend to connect to their servers).
3. One can run plenty of apps without it. Mostly Open Source, but I've heard of people running CM without Google Play. I've never heard anyone run Windows 10 or iOS in OpenSource mode only.
This reduces to the old argument that the Four Freedoms model of open-source software is basically moot in a world where the value of software is dominated by network effect, not modifiability.
It continues to be a weakness of the Four Freedoms model.
Give me a break. It's just as accurate to say "Dart is an open standard, Javascript is owned by Mozilla". There may be valid technical, pragmatic or moral reasons to prefer Javascript, but this is just FUD.
Really? Google's once rosy history with open source project isn't looking too friendly these days.
And yeah ECMA is a totally open standard with committee members from all sorts of companies and backgrounds. Dart is not. I don't care if JS is slightly worse, as least I know that for now and the foreseeable future I won't be paying a google tax to use it.
After the open source community "stole" mapreduce and hbase google has begun offering maglev and spanner as "services" rather than giving them to the OSS community. Maglev was supposed to be open sourced a while ago, and google now offers DDoS protection service on Google cloud instead, most famously with their Krebs PR stunt. Maybe they forgot about it? Did I mention they removed "don't be evil" as their motto a while back because it was "immature"?
Google has begun down a decidedly different path since the Alphabet transition a while back. It's no longer the brainchild of Sergey and Larry, it's losing its soul and becoming a shareholder cash machine. Maybe the floundering of some of their moonshot projects is taking a toll on the companies' confidence to remain a market leader while maintaining their traditional values of openness and shunning of questionable marketing tactics? I'll admit that's pure speculation but I really wish I knew what happened to the Google I remember.
Since I'm being accused of FUD I might as well throw a bunch more speculation in for the hell of it. Their most recent papers are conspicuously lacking enough detail to make your own implementation, and read more like marketing whitepapers on how to use their services and how great they are. Their tensorflow library was probably released as truly open only because they couldn't hire enough devs with machine learning experience to meet their needs. They needed to introduce the world to enough of the secret sauce to meet their own demand and they remain completely silent on how their real moneymakers work.
My extreme speculation? They started using machine learning for search a few years back and found out just how easily their previous search algorithms, developed and perfected for years, were utterly outclassed within months. A start-up with these techniques could have been their undoing. This oversight cannot be repeated, they cannot offer too much of their technology back to the world anymore lest they risk being beaten to death by their own weapons. Thus google threw away a lot of what made them google, and rebuilt themselves as a semi monopolistic oligarch that's much more in line with traditional too big to fail companies.
They now spend more on political lobbyists than any tech company by far. They like to release nice things for free when a competitor just happens to be a making a decent living charging for the same thing. They engage in a lot of the typical corporate warfare now that doesn't seem natural for a company with a nice playful exterior and an original motto of "don't be evil".
As far as the FUD accusation, does it count that I don't work for or with any company that has anything to do with google or the other tech giants? These are just my opinions based on observations, and a lot of those opinions are backed by verifiable facts.
You're free to put the same data together and make your own conclusions, which would lead to more interesting discussion than dismissing my points just because.
One addition I would like to make, every corporation is a shareholder cash machine, and Google has always been one, it didn't suddenly become one. The problem is in the institution of corporations itself, which has a lot of flaws.
"Don't be evil" is the first and last thing stated.
Why do you post stuff that's trivially searchable and trivially called out as bullshit? Why would I bother reading any of your rant if you can't get trivial details right?
Microsoft is lobbying to get their favorite syntax into JS6/7. Who wanted the class syntax? etc And TypeScript and WebAssembly are part of their plan. Ultimately, they want to recompile their 27 year old Office codebase from C/C++ to web browser.
To be fair, it seems to me like the typical webdev coming from C#/Java really wants the class syntax. I disagree with it, but I don't think it's just MS that's pushing it through, and even if it is, there's definitely an audience for it.
I've used a ton of languages over the years and vastly prefer Java type syntax when working on larger projects. The forced organization tends to lead towards some level of mandatory code clarity. Something greatly lacking in Js land.
OO is a bad word these days and functional is all the rage, even though functional languages were largely superceded by OO languages eons ago for many reasons people are slowly redicovering.
There's a huge push to put more structured language concepts into js now that it's being used for substantial projects and it's out of necessity more than convenience.
When I'm hacking together a quick Python script all that stuff gets in the way but when working on larger systems strong typing and object syntax are practically a neccesary evil for maintaining readability
Erlang and common lisp have been around for a long time, and functional programming is nothing new.
The reality is that most business problems map conceptually to communication between objects, and that IDE's which greatly help developer productivity work a lot better with objects.
Functional programming has origins in lambda calculus and academia because mathematical problems map more easily from pure math to functional programming. It's really popular in the circles where it's more useful/easier than OO.
Honestly I don't think the people 20 years ago chose OO for most business languages over functional out of ignorance. They had a choice and decided that OO was better for business problem solving languages like Java even though a large majority of programmers from that era were math majors and familiar with functional syntax.
I feel like we're in one of those cycles where a large number of a previous generation have retired and it's time to learn some of these lessons all over again.
Notice how many wood commercial buildings have been going up in the last 15-20 years? A lot, and just long enough after everyone involved in all the great city fires of WW2 to be too dead to object.
Who "choose" OO 20 years ago and (much more importantly) why?
I'm going to ignore the social component... that said, we work in a wonderful profession where the world is changing completely every decade and many design decisions from the previous generation make no sense anymore. The business case for developing your application in COBOL rather than Common Lisp may have been sound 20 years ago, but today many of the reason why you didn't choose lisp are invalid (e.g., garbage collection takes milliseconds rather than seconds).
Note that this is not the case in more mature fields such as construction.
> strong typing and object syntax are practically a neccesary evil for maintaining readability
No, it's not like that.
You can write readable code in any language as long as you can write readable code. It sounds tautologic, but what I mean is that ability to write readable code is a skill separate from writing code or knowing a particular language.
Strong static typing - as just about any tool and language feature - can have both good and bad effects on code readability. In the end, the readability (so also maintainability and other related metrics) depends on the skill of a particular developer in the largest part.
Both OO and FP techniques, as well as all the language features, are the same. You can misuse (or ignore) them all.
What we need is to make an "average developer" better at writing code, not more bondage and discipline in our tools. The latter is (a lot) easier, so that's where we focus our efforts, but - in my opinion - it's not going to solve the problem.
Eh? Dart was trying to replace JavaScript in some fashion, but that obviously failed (they had good intentions, but bad execution). Seeing that Chrome hasn't included it yet, I doubt it will. So that dream is dead.
Dart is a replacement for GWT at this point. See AdWords being written in dart now[0]. Though it's not clear now Flutter.io will play into all this (that's targeting mobile with no web target).
As for typescript, Google actually embraced that fairly heavily with Angular2 being written in it.
JavaScript sucks because it has a weak standard library, ugly syntax, and its monopoly in web development has the industry stuck in a state of mediocrity, in my opinion. I have a VERY hard time believing that the apex of engineering intelligence and ingenuity is found in JavaScript. Also, as much as I love Elm, for instance, languages that transpile to JavaScript are just lipstick on a pig, and do little to solve the underlying problem. I'm not a fan of Dart either, but at least Google made an attempt to solve the JavaScript issue in the best way possible with Dart; by aiming to get rid of it.
I agree with you that JavaScript sucks balls in far more ways than is reasonable for such a widely used language. The design is seriously shit when compared directly to really any popular language, even PHP.
I disagree with transpilers not being a reasonable answer. Eventually JavaScript will be okay to work with, some day. Until then, transpilers offer nearly unlimited freedom in redesigning the bad parts of the language while maintaining 100% fowards and backwards compatibility. It's really as good as it can get.
Since they compile down to a Turing complete language there's really no limit to the heaps of dog shit they can abstract away. Historically, c++ is nothing more than an insanely complicated C preprocessor and it has more than proven that such a strategy can be viable long term. In fact, the first c++ compiler made, cfront, is still available and literally outputs raw C code from c++.
Typescript is easily my favorite since it's designed to compile down to very human friendly JS. Getting typescript out of your stack requires nothing more than one last compilation with optimizations turned off. Unlike most transpilers (looking at you babel) the output JavaScript uses standard JS workarounds like the crockerford privacy pattern for classes. This gives typescript fairly practical fowards and backwards compatibility. You can always target output to a newer version of js or convert your codebase out of typescript back to js at any time.
If it catches enough traction, browsers will begin implementing native typescript parsing since it offers many potential performance optimizations on top of what js is capable of. At this point you just maintain your typescript codebase and use some library to give your legacy clients some transpiled J S on the fly.
If typescript gets enough adoption it will fix JavaScript for good, in the same way the original c++ compiler (which just transformed to c) led to native support, so I'm really rooting for it.
I can see your point about transpilers. Of all the transpilers I've used, I like Elm the best, due to its functional nature, syntax, strong typing, compiler, and debugger. It isn't fully stable yet, as a language, and there have been breaking changes in each release since I started using it, but it offers the most promising departure from JavaScript. I guess anything that facilitates the de-turding of web development in general is a good thing.
Haha de-turding is a great way to put it. I just don't think a new language is a reasonable option. There's what maybe... 50,000 different versions of the ~500 web browsers from different eras still running out there somewhere?
If having code work almost everywhere is important for a project, that project will be using vanilla ES3-5 JavaScript for the next 10+ years. Maybe not the latest startups but all sorts of enterprisey ancient stuff that needs to run needs some path forward. If typescript can provide that it will become the lowest common denominator at any company that ships both new and legacy codebases.
Typescript to JS transpilation is extremely similar to the strategy that produced C++ from C. We know it will work, and it's been done before to great success. C++ isn't perfect but I think everyone agrees it's definitely a lot nicer to work with than C, and that's exactly how I describe Typescript as well
I do see your point about C++. I was programming when it first came out, back in 1985. However, I've always thought C++ felt "Band-aid-y." It never felt elegant and cohesive to me, the way Objective C does. C++ is like a chainsaw-hang-glider-shotgun-bat; badass, to say the least, but still a clumpy work of bailing wire and duct tape. Typescript feels the same way, only not quite so badass. It's more like the Robin to C++'s Batman.
Having said that, my only exposure to Typescript has been in Angular 2. Having used other tools like Ember, React, and Elm, Angular 2 seems like a magic step backwards to me. I will concede that my opinions on Typescript may be tinted by my experience with Angular 2 though, so I'll give Typescript a stand-alone, honest evaluation, and adjust my opinions as necessary.
Looks like alternative facts have reached the tech world too?
You can take as hard look at Google as you would like, but choosing Microsoft over Google (one for-profit company over another), while not caring how the technology, the licensing or the workflow compares is a bit hypocrite. (e.g.they are both open, and they both have rules of commits).
I'm wondering, why do you need a throwaway for such heavily invested FUD? Your other comments here are in similar tone, and I'm surprised to see such hatred without any obvious trigger. Maybe if you would come forward with your story, it would be easier to discuss it?
disclaimer: ex-Googler, worked with Dart for 4+ years, I think it is way ahead of the JS/TS stack in many regards.
Typescript and dart are completely different animals. I can leave typescript for good by compiling to js once and it's designed to output human readable code. The js it produces will be immediately usable as javascript, and I'm totally free from the semi open language that MS controls.
Dart is a different language, it has no fallback to something familiar. I don't doubt that it's many years ahead of TS in every way but it's still rather proprietary compared to TS that I can shut off at any time with minimal effort.
The openness of typescript and dart are comparable. Both being run primarily by their champion companies with code free to review and fork but with limited ability to commit changes. They both require you to sign over copyright of code committed which I don't like for my own reasons but the license is open source.
The big difference to me is that typescript offers an escape hatch and dart does not, because one is pretty much a JavaScript enhancement and the other is completely different. I hate vendor lock-in and loss of the open web in general and you will see this as a common theme to most of my more flamey(controversial) comments. The web is closing off in so many directions and as an open source developer in my free time this is of great personal concern. I don't like that hackernews and reddit can be an echo chamber and posting contrary opinions usually makes the discussion more balanced even if a lot of people don't like it.
I'm not ex google, MS, or any of the tech giants. I'm not smart or dedicated enough to work anywhere you've heard of :). Most of my comments on throwaway accounts are unpopular, that's why I don't use my normal account. I'm not some invisible super shill, hackernews knows all the accounts I use and I'm fine with that.
I've just got my own opinions and when they're controversial it's not in my best interest to comment using my normal account. It wouldn't be for anyone. It would be utterly stupid to hurt my open source projects or reputation as a developer just because somebody doesn't like my opinions. My code and my work have no opinions, and I like to keep it that way. Throwaways are my way of keeping my opinions to myself, and I don't see anything wrong with that. Separation of church and state if you will.
I'm not totally against Google or any company in general. Microsoft in particular has an extremely rocky history when it comes to open source projects. They've probably done more harm to Linux than any company in existence. If typescript and dart both had equal migration paths I would choose dart in a heartbeat. I love tsickle and the closure compiler and the fact that the angular team is using typescript. Still, I feel like my criticism of dart has some truth to it at least.
I've taken aim at Google for the past week for what they've done to the openness of Android, AMP, and dart. Am I wrong? It's hard to argue that any of Google's platforms are as open as they were a few years ago. Some of my really unpopular opinions were posted in reponse to other poster calling me FUD or a shill, and can you blame me? It's one thing to say "I disagree and this is why" but pretty rude to just say "I don't believe you because you're obviously lying or getting paid to say that". To that I say well screw you I'll post what I want without being polite at all if you're going to be so rude. I'm replying nicely to you because you genuinely asked why I used a throwaway and said that you worked with dart at Google, way more than most would admit.
Having an unpopular opinion just gets you labelled as a shill or FUD and that's a lot of the reason I use throwaways. I've actually gotten death threats before for disagreeing with people on the internet. It's hard to say I would be better off getting death threats from people that can easily find my name, occupation, and address. Look at more...
Your worries about being locked in may have been valid 2-3 years ago (1), but things have changed a lot since:
Dart has an ongoing project (Dart Developer Compiler) which has a goal, among others, to produce readable, idiomatic EcmaScript 6. That is as close to your TypeScript fallback as it can get. (2)
Somebody also demonstrated Dart to LLVM compilation is possible. The language has a decent library for parsing the Dart sources, worst case, if you are that heavily invested in your product, you could also write something that does transpile your codebase. I did try to do it on small scale and specific examples, it is actually not _that_ hard to do, if my business relied on it, it would be certainly within reach.
(1) I'm not sure if you can call it lock-in as it is entirely open source, you can fork it, build it for yourself, change it if you have special needs. The same goes for perl, php, python, go, whatever language you prefer. Yeah, most people don't do it. Why? Because most people don't need it. If you become Facebook-size, it may look better to invest in the PHP toolchain and VM than in transpilers. YMMV.
(2) From the pure technical point of view, I wouldn't call it reassuring that the default fallback platform is JavaScript for so many people (even on the server-side). It is sure depressing that we are stuck with "1" == 1 and wrong ordering of "[1, 2, 10].sort()" for as long as we fall back to JS, and TypeScript does not improve on it.
I didn't know of the developer compiler, when that reaches production I won't have any real citicism of Dart.
For now Js fallback is the only realistic option for running code on the web. Even if we get native typescript or dart support tomorrow we will still need to put up with JavaScript for like 7-10 years. For this reason a readable JS fallback seems like a vital feature to me at least. It's depressing but reality for the majority of web projects.
Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's? That would make it a lot easier to write your own conversions.
One more point in Typescipt's favor though... It would be a lot easier to modify the JS VM in browsers to support native typescript than dart. In my mind it's a lot more likely to happen because of this(less work)
> when that reaches production I won't have any real citicism of Dart.
It's still got bugs, of course, but we have internal customers working on real projects using it on a daily basis.
I agree totally that picking a language is a huge commitment and you want to do that with an organization (company, standards committee, group of open source hackers, whatever) that you trust.
Google is a huge company and has done lots of good and bad things, so it's easy to find enough evidence to support assertions that we should or shouldn't be trusted based on whichever view you want to demonstrate.
One way I look at it is that instead of answering the absolute question "Can I trust Google to shepherd the language well?", consider the relative question "Can I trust it to shepherd the language as well or better than the maintainers of other languages I might choose?"
Assuming you've got some code to write, you have to pick some language, so the relative question is probably the pertinent one. I hope that we on the Dart team are a trustworthy pick, but different reasonable people have different comfort zones.
> Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's?
All of our stuff is open source[1], including all of our compilers and the libraries they are built on. Most of it isn't explicitly pluggable because plug-in APIs are hard and Dart in particular doesn't do dynamic loading well.
But it's all hackable, and much of it is reusable. In particular, the static analysis package[2] that we use in our IDEs also exposes a set of libraries for scanning, parsing, analyzing, etc. that you can use.
>I think it is way ahead of the JS/TS stack in many regards.
In what ways do you consider it ahead of Typescript? Personally as someone who's particularly fond of static type systems (Haskell and the like), Typescript's type system seems way more advanced and powerful than Dart's (union and intersection types, in particular, and non-nullable types). Map types (introduced in Typescript 2.1) also seem pretty interesting.
Some of my earlier notes are in this thread (it is more about the day-to-day feature I actually use and like, and less about the fine details of the type system)
https://news.ycombinator.com/item?id=13371009
Personally I don't get the hype around union types: at the point where you need to check which type you are working with, you may as well use a generic object (and maybe an assert if you are pedantic).
Intersection types may be a nice subtlety in an API, but I haven't encountered any need for it yet. Definitely not a game-changer.
I longed for non-nullable types, but as soon as Dart had the Elvis-operator (e.g. a?.b?.c evaluates null if any of them is null), it is easy to work with nulls. Also, there is a lot of talk about them (either as an annotation for the dart analyzer or as a language feature), so it may happen.
Mapped types are interesting indeed. In certain cases it really helps if you are operating with immutable objects, and mapping helps with that (although does not entirely solves it, because the underlying runtimes does allow changes to the object).
I agree about union types. They can quickly result in insane variable declaration statements that are hard to understand.
I dislike nulls though, I always wish people would just use a flag or error handling when objects are undefined, instead of "hey this object is the flag and sometimes it's not actually an object!"
You'd think language designers would learn after dealing with null pointers :)
So Dart hasn't really incorporated any lessons from 20 years of Java, has it? Google's answer to Tony Hoare's billion-dollar mistake is... "The Elvis operator"?
Typescript is definitely an improvement over type-free JS, but it's still wedded to the JS type system so unfortunately, it will still let you shoot yourself in the foot in ways you might not anticipate if you have experience with other languages with a stronger type system.
For example, If you have a string-typed foo and a number-typed bar, "foo + bar" is still a valid statement in TS because they have to maintain backwards-compatibility with JS's unfortunate language design choices.
TypeScript has some really cool type system features. Union and intersection types are fun and really handy when interacting with dynamically typed code. (If you go back through history, you'll find almost every language with union types also has a mixture of static and dynamic typing. See: Pike, Typed Racket, etc.)
Self types (the "this" in the return type) is handy.
I can see us adding some of those to Dart eventually.
Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up.
The main difference between TypeScript and Dart's type systems (and by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound.
This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too.
In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct.
If Dart ever became the real thing, it must be supported in not just Google Chrome, but also Firefox, Edge, Safari, etc. At that point Google will lose its control.
I have my doubts. Hiroshi Lockheimer, the SVP of both Android and ChromeOS stated, "There is no point in merging them. They're both successful. We just want to make sure that both sides benefit from each other," referring specifically to rumors at the time that said that ChromeOS and Android were merging.
I suspect this is true, in that Fuchsia is simply a potential replacement for both... not a "merge". But bear in mind, marketing voices like Hiroshi's job is to promote and sell people on the existing product... right up until the day they decide to officially announce something else.
So, even if they were presently 100% focused on merging the two OSes, Hiroshi's job would be to convince you they aren't as not to risk impacting the bottom line of their sales and their partnerships with OEMs that are continuing to print money for them.
But bear in mind, marketing voices like Hiroshi's job is to promote and sell
people on the existing product... right up until the day they decide to
officially announce something else.
Absolutely. I'm reminded of how Steve Jobs claimed that Apple was absolutely, 100% committed to PPC... right up until he announced the first Intel Macs at Macworld in 2006. And Apple, at that point, didn't even have OEM partners to worry about.
Like the plan9 people working at google pivoted plan9 into golang, this is the BeOS people working at google re-inventing BeOS into something new.
But golang could be started in internal use with incredimental steps. fuchsia/andromeda in contrast have non-code barriers for entry like management approval and industry adoption. My guess is that it will pivot from a full-blown android replacement into something more focused.
Dart is part of Ads, not Chrome. Chrome didn't want them, while Ads Frontend is heavily dependent upon them.
Aside from Google+ (which was pushed directly by Larry and grudgingly integrated-with by the rest of the company), Google hasn't really had plans "as a company" since the mid-2000s. Big companies (other than Apple under Steve Jobs) don't actually work like that; once you've got a product-focused org chart and strong executives that push their own focus areas, you will necessarily get product-focused initiative that respond to resource availability & market opportunity. The executives are not doing their jobs otherwise.
Are you saying that big companies shouldn't have company-wide plans or that big companies tend not to have company-wide plans (because of poor leadership)?
The idea of factions in Microsoft fighting for control is interesting to me from a historical perspective - do you have any books or sources I can read to get the full story?
I don't have any detailed links handy, but it's definitely common knowledge that this is the case (or used to be, anyway). Manu Cornet's comic captures it well: http://www.bonkersworld.net/organizational-charts/
I think it's just a speculative effort that probably won't go anywhere.
I googled for "google magenta", and all the top hits are actually about an entirely separate (I assume?) project about AI music: https://magenta.tensorflow.org/welcome-to-magenta. So they didn't think very hard about the name for a start.
I'm also skeptical that a big new effort like this would be done entirely in the open. The Chrome team has something of a history of doing that and then throwing stuff away (e.g. Chromium mods and hardware configuration for a Chrome tablet that never got off the ground).
The Android team, on the other hand, seems to prefer developing stuff in private before open sourcing it. And their stuff seems to have more traction (or maybe we just don't see all the aborted efforts because they're private).
I feel like the Chrome team really believes in open source, and developing in the open, whereas the rest of the company (and especially Android) doesn't care as much and prefers being secretive. But as Sundar Pichai used to run Chrome, maybe he's changing things up a bit?
Since Fuscia is a new kernel, that means it will probably only support Google hardware.
The status quo right now among android hardware vendors is to violate the GPL, and they have faced few if any repercussions for doing so. I wonder if Fuscia is sort of viewed as the way forward to addressing that.
You can release code and still violate the GPL in other ways. For example, there are binary blobs out there and the GPL is pretty unequivocal on this point: "The source code for a work means the preferred form of the work for making modifications to it."
I'm a minority I know but I don't like material design because it's terrible at "scaling." It looks great, it's beautiful, but you lose too much damn functionality. When I had to redo apps to material design we had to completely remove multiple buttons due to them not fitting material design standards. I really hope they have some way to alleviate this problem without using 50px icons for all the extra buttons.
They weren't vital components but useful for the user. We moved most of the "excess" buttons to the top bar and overflow menu but still had to remove a button here and there completely (we still had the functionality in a different part of the app it was just more tedious to use from our testing).
"The pitch will clearly be that developers can write a Flutter app once and have it run on Andromeda, Android, and iOS with minimal extra work, in theory."
How's that going to work? iOS, specifically? Is Dart a supported language?
"The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved)."
The author calls it Andromeda OS, but is this really the Andromeda OS we've been hearing about? I'm not so sure about that. What we do know right now is that the OS is currently code named Fuchsia.
A bit weird to use the past tense here since it's not reached 1.0 yet. You can try it out today (tech preview) to create apps in Dart that run on Android and iOS:
> The pitch will clearly be that developers can write a Flutter app once and have it run on Andromeda, Android, and iOS with minimal extra work, in theory.
This is worrying for Apple. I can see the following playing out
- Apple continues releasing machines like the TB MBP, much to exasperated developer dismay.
- Other x86 laptop industrial design and build quality continue to improve.
- Fuchsia/Andromeda itself becomes a compelling development environment
- Developers begin switching away from Mac OS to Fuchsia, Linux and Windows
- Google delivers on the promise of a WORA runtime and the biggest objective reason not to abandon Mac OS, i.e. writing apps for iOS, disappears.
- Apps start to look the same on iOS and Android. iOS becomes less compelling.
- iOS devices sales begin to hurt.
Granted that the App Store submission requires Mac OS (Application Loader) and the license agreement requires you only use Apple software to submit apps to the App Store and not write your own, but it seems flimsy to rely on that.
If nothing else comes out of this, I hope we end up with an Android OS that works better than the current one.
I've been running Android since the Nexus One so I'm no newbie to the platform, but the ease with which iOS manages to get all UI interactions at ~unnoticable FPS and outstanding battery life is staggering when you're used to Android. It feels like some really fundamental choices were made badly on the platform that make it incredibly inconsistent and unreliable. A fresh start would be fantastic.
As a fellow Nexus user, I've owned the Nexus One, 5, and currently use a 6P, how much of this is due to the OS versus hardware? Will Google ever be able to achieve Apple level battery life or overall UI smoothness, not to mention update support, without having their own custom SoC?
I was very happy with the 5, even with the intermittent lags, especially considering it's price at release. I suppose I'm not a very heavy phone user, and I never play mobile games, but I've been very happy with the 6P on Android 6.0-7.1. Battery life could definitely be better, and it does get fairly warm at times, but overall it's been a very good experience for me considering the Snapdragon 810 it's using is generally poorly regarded.
Apple has had fluid UIs since the start, despite off-the-shelf, low resource Samsung SoCs. They only started making custom ones after with the 4S, as I recall.
Yep. Out of the starting gate, Apple forced tight constraints on background and multi-threaded processing---so tight that the first versions of the iPhone OS couldn't support some types of application that the Android OSs could unless Apple wrote the program and could take advantage of the private APIs in the OS. But the advantage to that B&D approach was responsiveness and battery life, relative to an Android OS where any developer could write an app that would spawn an ill-behaved background thread and suck your battery.
i have a nexus 6 and its ruining android 7.
its better then samsung devices, but it has its own problems.
i run the screen at min brightness because thats the only way i can get reasonable battery life. my car is parked -2 so i lose signal every time i have to go there. and sometimes i have to restart the device to get the signal back ( no tricks like airlaine mode work) the ui sometimes gets so slow i dont know why.
I wonder how much of the performance issues are related to Android being Java vs iOS being C? The old Blackberry OS was also implemented in Java and I remember well the spinning hourglass and the odd pauses in its UI.
Not much, modern devices and modern Android runtime is fast enough that GC and Java aren't a problem. There's bunch of other issues around though, mostly coming from the fact that devices use problematic and slow I/O controllers, apps do blocking I/O and OEMs add bloat and misconfigure behaviour of the OS to prioritize their services at the expense of apps you're actually using.
But bad I/O is the killer (e.g. fun things like triggering 2 image load requests at once which then take 2500ms vs. doing them sequentally which takes 400ms on some Samsungs. This happens also if several processes collide). Apple side-steps that by throwing money at the problem (good controllers, expensive flash) which probably won't happen in budget Android market.
I don't read about Android and iOS [hardware] nearly as much as I'd like to, and HN doesn't seem to generally cover the subject too well. What are some sources you could recommend I read to stay updated?
iOS devices routinely ship with batteries ~60% the size of flagship android devices and have competitive amount of battery life. If apple chose to ship an iphone with a 3000mah battery like what can be found in Android flagships it would absolutely crush the competition in terms of battery life.
Unfortunately, the hard part of an operating system isn't in a cool API and a rendering demo. It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. People don't like dropped frames when they plug in USB :) Writing device drivers for demanding hardware is much harder than saving registers and switching process context. The Linux kernel has an incredible agglomeration of years of effort and experience behind it - and the social ability to scale to support diverse contributors with different agendas.
Microsoft, with its dominant position on the desktop, famously changed the 'preferred' APIs for UI development on a regular cadence. Only Microsoft applications kept up and looked up to date. Now Google has such a commanding share of the phone market - Android is over 80% and growing http://www.idc.com/promo/smartphone-market-share/os - they have a huge temptation to follow suit. Each time that Microsoft introduced a new technology (e.g. https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... WPF) they had to skirt a fine line between making it simple and making sure that it would be hard for competitors to produce emulation layers for. Otherwise, you could run those apps on your Mac :)
There are many things to improve (and simplify) in the Android APIs. It would be delightful to add first class support for C++ and Python, etc. A project this large will be a monster to ship so hopefully we'll soon (a few years) see the main bits integrated into more mainstream platforms like Android/Linux - hopefully without too much ecosystem churn
it doesn't need to be a general purpose OS and is probably going to target mobile devices and laptops. I don't think supporting a wide range of hardware is even on the road map.
Given that it's Google, I wonder if it will support the languages favored by bootstrappers and small startups—Obj C, Ruby, JavaScript and more recently Swift and Elixir. I get the distinct impression that they're heavily optimizing large team productivity and aren't a fan of functional or highly expressive languages.
It's too bad, given how much nicer their app approval process, etc is than Apple's that the Android dev experience has been so much worse all these years.
Driver support should not be a problem for Google. They can reuse existing drivers with a rump kernel approach [1].
And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise...
A product I worked on was a victim of Microsoft changing preferred APIs. Their competing product which the prior year had less market share somehow sported the new UI instantly when the UI became publicly available. Monopolistic behavior if you ask me.
It's why I got out of the MS ecosystem. I bought quite heavily into WPF for the Vista launch, and it was obvious that was a dead end within a couple of years. Not only that, but I could see exactly the same thing happening to all the other neat stuff I was planning to look into at the same time. That was not the way to encourage my long-term membership of the Visual Studio clan.
> and it was obvious that was a dead end within a couple of years
As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.
How were you doing it? It's definitely possible to embed DirectX in a WPF control, and not particularly hard to do, with SlimDX or SharpDX, in my experience.
Declarative 3D data in XAML, not touching DirectX directly at all. Viewport3D at the root, then doing the right magic to get the sort order of the objects right (working around the built-in logic, in other words).
> It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads.
So much this; Linux Plumbers conference years ago was bitching about how every gorram vendor wanted to be a special snowflake, so even though the architecture was ARM, you basically had to port the kernel all over again to every new phone. I haven't kept up with it, but I can't imagine it's gotten better. The problems they're listing as reasons to move to a new kernel aren't caused by Linux and they won't go away until you slap the vendors and slap them hard for the bullshit they pull, both on developers and users.
As for kernel ABI, this has been rehashed to death: just release your fucking driver as open source code, and it will be integrated and updated in mainline forever: http://www.kroah.com/log/linux/free_drivers.html
Overall I agree with your sentiment but it's not just a case of "releasing your drivers" but also of getting it accepted by maintainers. If you don't have an awareness of this process from the beginning of your development cycle then it can be a massive amount of work.
> I don’t see the average garbage-collected language using a virtual machine allowing for a target higher than 60fps realistically.
But... "average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust. Nor Javascript.
I get greater than 60 fps with my existing Vive three.js WebVR-ish electron/chromium linux stack. Even on an old laptop with integrated graphics (for very simple scenes). Recent chromium claims 90 fps WebVR, and I've no reason to doubt it. So 60 fps "up to 120fps" seems completely plausible, even on mobile.
> But... "average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust.
I'm curious; what would be an example of something you would describe as an "average garbage collected language using a virtual machine"? Java would certainly be the first language I'd think of for that description.
Java is not using a VM on Android since ART was introduced, although on Android 7, it is a bit more complicated, given the mix of pure Assembly interpreter, PGO driven JIT and AOT compiler.
Python was included in the list of things considered not to be in this category; I probably agree with you on that one, but the idea behind my question was that the languages listed as not "average garbage-collected language using a virtual machine" included several that I'd include in that category.
What do you think makes Ruby and Lua more "average" than Java?
In addition to the 2 nice previous answers (though I'd not include CPython myself, as writing high-performance CPython means writing/using C libraries; and note that Lua and LuaJIT are different)...
I italicized "average", and wouldn't include Java, because most languages are very small efforts, and thus are different than the top few. A person-century or person-kiloyear of optimization effort has an impact. Observations that "implementations of strategy X generally have characteristic Q" can be true, but there's a hidden context there of "severely resource-limited implementations of X".
But two caveats:
Sometimes you are trapped. In CPython and PyPy (but not in Jython or IronPython), parallelism remains defined by the GIL.
Language implementation tooling sucks less than it used to. Now even toy languages have JIT and rich compilation infrastructure.
Aside: In the late 80's, before ARPA was hit by Bush I, project managers had a great deal of autonomy. There was discussion of "what more neat things could we do to accelerate progress?" One observation was that JIT expertise was highly localized, and we could either wait many years for it to slowly spread, or pay someone to stand on people's desks and catalyze its being written up. But that kind of micro-grant didn't yet exist, and time ran out on creating it. Society chose option 1, but a human generation has now passed, and we finally have accessible JIT infrastructure. So, yay?
(In fairness, note autonomy and "old boy network"ness was a less happy thing for potential researchers at other than the few main research institutions. Some change was needed, it's just not clear it required societally critical tech to remain largely unfunded for decades. We don't even have a (language) wiki. Though even national science education improvement efforts have failed (but oh so close) to attempt one.)
Some people seem to have skimmed over the discussions about the pros and cons of garbage collection and come away with the idea that all garbage collected languages function by stopping the world for 50-100 millisecond pauses four or five times per second, minimum. There are real performance issues that GC can create, but there's a looooooot of vigorous overstating of the issues.
Slightly in those people's defense, it is true that while GC relieves you of the need to track lifetimes and worry about using dead pointers, it doesn't relieve you of the need to consider performance as one of many factors that go into your code. So while I think the performance issues of GC'd languages are very frequently overstated, it definitely is true that a UI framework written in a GC'd language by someone who isn't giving any thought to performance implications of allocation can very quickly exceed its targets for 60 fps, let alone 120 fps, even on very simple GUI screens. But that's only maybe 10% the fault of garbage collection... 90% is that someone is writing a GUI framework without realizing they have to pay a lot of attention to every aspect of performance because GUI frameworks are very fundamental and their every pathological behavior will not only be discovered, but be encountered quickly by all but the most casual programmers. It doesn't take long before someone is using your text widgets to assemble a multi-dimensional spreadsheet with one text widget per spreadsheet node or something, just as one example.
In a manually managed language, the performance of the application's memory management code is limited by the skill of the application developer. In a managed language, it's limited by the skill of the GC developer.
GCs have gotten a lot better in the past twenty years, in large part because they have the luxury of amortizing their work across a million applications. That makes it financially viable to throw a ton of person-years at your GC. That's not the case for the malloc()s and free()s in a single application.
So just through economies of scale, we should expect to see, and indeed have seen, managed languages catch up the the memory performance of the average manually managed app.
It bothers me that Google does not seem particularly interested in doing the one thing that would make their Android platform absolutely dominant: Allow Chrome to run Android apps on Mac and Windows.
Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a limited, buggy way [1]. If Google had put meaningful effort into developing such a strategy we would by now have a relatively simple way to develop software which runs on 99% of laptops and 85% of smartphones and tablets. Developers would now be targeting 'Android first' instead of 'web app first then iOS then maybe Android'.
The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.
For people who've already committed to Chrome, it might just be a one-time annoyance. But the time when Chrome had an seeming lock on the top seat in the browser wars has come and gone. I can definitely see this hurting new adoption, which would rightly make Google nervous.
It could make sense as an optional download if you do want Android support. But, Google would never increase the download size of their browser to that extent.
> The amount of additional code required to support Android apps on the Chrome browser would be far too great. No one wants to download a 500MB+ browser.
So, divide up by services, and download only the services needed by installed apps with the first app that needs them. Adds basically nothing to the browser install.
My Realtek sound drivers for PC were around 450 MB (!!!). Nvidia drivers are around 350 MB and update quite frequently. That's insane. And Chrome has great update mechanism.
Sun tried that, back in the day. Maybe you heard about Java applets, maybe you didn't. They were the slowest thing about the web, insecure even with a sandbox, and just an overall pain. Short of having a jvm always running on your machine, the performance of Android-via-Chrome will completely turn people off the Android ecosystem.
The first is no longer an issue. They can just use a modern just in time compiler and it wont run slower than Java on Android. Chrome already has one to deal with JavaScript powered Web 2.0 applications.
The second was as far as I can tell an API issue. Applets would block everything by default until they were loaded. A really bad idea in a single threaded environment when you had to send several MB over low bandwidth and the JVM itself took long to start. Just making the load async with a completion callback could have solved this issue and I remember a few Applets that actually used an async download to reduce the hang.
You missed the biggest issue: "write once, mediocre everywhere." Windows, Mac, and X were all different, and Java Applets were necessarily bad at emulating all of them. While there are fewer Unices today, there are more GUIs, and cross-platform apps suck at least as much.
So were Java Applets with AWT. Users hated that, so Sun tried PLAF, a half-assed emulation of each platform. That didn't work either, so Applets died.
If Chrome manages to provide better versions of most applications on most platforms, it may win. Otherwise, people who use those applications will hate it with the heat of a thousand Suns, and it will go the way of the Java Applet.
> So were Java Applets with AWT. Users hated that, so Sun tried PLAF
Uh, Java AWT was the native toolkit. Swing was the non native UI with the ugly METAL default Look and Feel. There are some nice custom Look and Feel implementations that don't try to emulate a platform, I think Matlab uses one for its UI.
Oddly you see non-native toolkits these days for many apps, and users don't seem as bothered anymore, unless I am mistaken?
For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
What choice do we have? Everyone's doing their own walled garden, so it's not like I can go and find an alternative SaaS / operating system with same features but better UI...
> For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
One of the last straws for me was the built in mail app that had this awful background image. Too many flashbacks of shitty access apps.
And the Metal plaf was the least ugly of the three that were originally shipped with JVM (other two tried to match how AWT would look on Windows and Unix). But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that.
One thing that strikes me as weird is that almost any widget set that does it's own drawing or even just it's own automatic layout and tries to match look and feel of native UI invariably does not match even the basic look because various UI components use wrong size, are placed slightly differently and so on. For example everything I've ever seen that tried to match how windows 3.1 Ctrl3D looked draws window decorations one pixel narrower than the original, which is plainly visible and ugly, similarly things that attempt "looking like Motif" usually use different thickness for various lines and borders and also often mix-up meaning of focus rectangle (which should move by tab) and bevel around default button (which should stay in the same place irrespective of which control has focus). I see no technical reason why either of these things cannot be done right, is there some legal reason for introducing such small differences, that are small, but big enough to be annoying?
> But IIRC, AWT was not native (in the sense of "calls native OS GUI components") but only tried to look native and failed horribly at achieving that.
A quick check of wikipedia backs my memory, the Java classes were just a thin wrapper around the native components. AWT was mostly bad because it was limited, it does not even have a Table.
> even the basic look because various UI components use wrong size, are placed slightly differently and so on.
The windows API does not come with a layout manager AFAIK. I vagualy remember setting every bit of relevant size/position data by hand last time I used it directly. Same could be done with AWT, so this is mostly likely caused by programmer lazyness.
The part about sizing being wrong was not that much about AWT (although IIRC it also has this problem, at least on Unix, where it looks decidedly non-motif) as about just about any non-native toolkit that tries to look native. Windows does not have layout manager, but has API for getting preferred sizes for various low-level UI parts (in Windows 3.1 small part of of this was even user configurable).
"Write once, mediocre everywhere" was a problem with Sun's implementation, not with the concept of cross platform code. There are tons of webapps which are very successful, despite being written 'once'.
In any case, Google doesn't need to be as strict as Sun was. It is free to implement "write 90% of your code once and 10% customised for each platform".
Webapps in the sense of "fancy JavaScript" are no better than Applets. Google has the infrastructure, money, and business model to put most of the code on their servers and write native clients. Modulo privacy issues, they have found a solution.
Oh I bet they are! Like, anything is better than those slow, buggy and annoying Java Applets and I'm so thankful to god they're over. Did anyone ever notice how slow they were not only to 'run', but to initiate and start doing just about anything. I always knew it was a java applet even before it started anything because of its characteristic loading behavior.
Webapps today are the same. Their characteristic behaviour is rendering the skeleton of their UI, and then greeting you with a spinner. They take about as much to start up as Java Applets did.
Now, consider the orders of magnitude improvement in computing power over the years, and notice that webapps aren't really doing anything more complicated than old applets did...
> There are tons of webapps which are very successful, despite being written 'once'.
Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues) and our expectations have lowered. How many of these web apps obey the native OS themeing for instance?
> Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues)
If an issue no longer affects anyone in any way, is it still an "issue"? Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
> If an issue no longer affects anyone in any way, is it still an "issue"?
I said it was masked, not gone. It still causes a lot of issues for people on resource constrained machines.
> Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
For much of computing history where were making clear gains with newer hardware. Up to the 90's software was getting more bloated but it was doing more. Most apps today really aren't doing much/any more than we were doing in the 90's but require vastly more powerful machines.
1) The fact that webapps can run relatively well strikes me as hopeful, considering how much more inefficient using HTML/CSS/JS is compared to Java applets. Or is the latter not the case (honest question)?
2) I'm not sure if our expectations have lowered much. Perhaps it's more that mobile interfaces are generally simpler and thus easier to make 'native enough'?
Although I think there's more going on in regards to 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native. And while it's certainly possible to make a web app just as shitty, if you rely on 'stock' html elements, a lot of the subtle native behavior carries over.
Just a few weeks ago, for example, I built a web-app for mobile devices. It felt off immediately because the scrolling didn't feel right. All I had to do was turn on the momentum scrolling (with a line of ios-specific css), and the scrolling suddenly felt native. Had I used a hypothetical Java applet equivalent, I might've had to either go for a non-native-feeling scroll or build it myself.
While I of course can't prove any of this, I think what people care about is that things feel native, not the 'skin' used to display it.
> 2) I'm not sure if our expectations have lowered much. Perhaps it's more that mobile interfaces are generally simpler and thus easier to make 'native enough'?
I think people finally called the bluff that users have any expectations. And even if they had, what they don't have is choice. The current market is that everyone is building a walled garden around their selling proposition, so if a company decides to make a web app instead of a native one, then that's all you have. Nobody will make a better one and risk getting sued. If a service doesn't want third party applications, then they won't happen.
As you note in your comment, if one sticks with default, "stock" elements in their web app, things look and behave OK on a given platform. But nobody does that, for some reason everyone has to screw this up with tons of CSS and JavaScript that make the whole thing maybe prettier, but also noticeably slower and without all the native idiosyncrasies.
> considering how much more inefficient using HTML/CSS/JS is compared to Java applets. Or is the latter not the case (honest question)?
It's a really interesting question actually because it's so hard to compare the two. On any objective measure, today's web apps are much better than applets in terms of responsiveness, etc. But then again, an applet could run on machines with 16MB of RAM total. I think you'd be hard pressed to get plain html page in a modern browser to run on a machine like that. Either way, in both cases we had a much better solution in native apps.
> 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native.
Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
> Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
Oh yeah, complex UI stuff is definitely a good reason to avoid web apps.
But for many, probably even most apps it's precisely scrolling, text input, and other 'basic' stuff that matters, and in those cases a web app's 'default' will be more native.
> For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
I agree on a personal level, but I suspect we're outliers. Can't substantiate that at the moment though, so I might be wrong.
> How many of these web apps obey the native OS themeing for instance?
Forget the theme - how many of these web apps obey the native OS GUI features? TAB-navigation, arrow navigation (in e.g. lists), accelerator shortcuts, editing shortcuts, not to mention a lot of visual idiosyncrasies that together make the interface feel "right"? Ironically, if you use default HTML controls, most of the things will be OK on a decent browser. But no, designers and developers absolutely have to make it worse by applying tons of CSS and JavaScript.
This applies to web apps pretending to be mobile apps, too. You can quickly tell one from another; the web app is the one with mediocre UI that behaves "wrong" in more or less subtle ways.
The problem is not technical and never was, it's that Apple and Microsoft would do anything to maintain an 'application barrier' that makes genuine cross-platform coding as hard and inconvenient as possible. It's all about developer lock-in and control over the customer, even more today than it used to be in the 90s.
How would you caracterize Microsoft's open-sourcing of the .NET stack, support to run it on Windows and RHEL (actually support to run RHEL on Azure), VS code universal electron app, the whole Office 365 paradigm, and multiple apps like Remote?
It seems to me that the 'new' Microsoft (since Satya Nadella took leadership) is changing their closed/proprietary stance on many topics. Not everything of course, they still have to sell stuff, but as far as "genuine cross-platform" is concerned, they are certainly giving developers all the tools to both make and target all major operating system.
> How would you caracterize Microsoft's open-sourcing of the .NET stack
Giving anyone not on Windows a second rate experience? Core as the name says provides only a subset of the Windows .Net framework and most .Net code in the wild is written with the implicit assumption that it runs on the Windows framework.
> VS code universal electron app
Instead of making their main IDE a proof of concept for .Net Core they wrote a Web3.50/NodeJS IDE. I am very sensitive to high latency IDEs so that is something I wont ever touch.
> the whole Office 365 paradigm
Trying to keep up with the competition, Google Docs ring a bell?
> since Satya Nadella took leadership
Nadella 2014. Linux on Azure 2012. Office 365 2011. Mono based on Microsoft’s promise not to sue 2004. Open sourcing parts of .Net is really the only thing you can assign to Nadella, everything else was still done by the good old triple E leadership.
I never understood the need to "emulate" all of them. Linux has always been a mess of tools written against different UI styles ( GNOME, KDE, MOTIF, ... ), Microsoft also reinvents its UI with every release leading to outdated application UIs and I don't know how consistent Apple was. I think the best you can do is choose one and stick with it, its not like most websites look and feel native.
There is one BIG difference.
The Android frameworks are already the default on a major platform.
Googles Material Design already looks native on both Android (majority phone platform) and ChromeOS.
Java did not have a major platform where it was the default framework. It was not the default on Windows or Mac, not even on Unices (with the exception maybe of SunOS or Solaris, but not even there).
If Java framework was not the default anywhere, then the primary reason to use Java was because it works everywhere. The primary reason to use the Android frameworks and Material Design is to publish on Android. Having it work everywhere else is a great bonus.
Android and Material Design will not be "write once, mediocre everywhere". It may become "write once, great on Android (majority of phones) and ChromeOS, mediocre elsewhere." But writing for Android does not exclude creating native versions for other platforms. Using Java did exclude creating native versions because that was the reason to use Java, to not have to write native versions.
I thought it was "write once, test everywhere" because the ideal of cross-platform software forgot about developers doing system-specific things (eg. file system paths)
So were Flash and JavaScript and I still don't fully trust either. It helps that blacklisting almost everything with NoScript actually speeds up 90% of the sites I visit.
Maybe you somehow haven't noticed that even mobile devices now are an order of magnitude faster than desktop computers were back in the days of applets. Desktop computers can run Java applications with no significant overhead.
Not totally. We support a number of java applets at work. The clients still take "way too long" to load and feel bloated. "Way too long" is a subjective measure based on the current hardware/OS. For a JVM to not feel slow it would have to speed up relative to itself...and I haven't seen them do that.
If it's specific apps, usually it is just bad coding. 'Enterprise Java' style coding where performance is not even tested for, let alone designed into the algorithms.
Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation.
That's not really anything to do with the technique (code in browsers) or the runtime (JVM) or even the programming language (Java) -- and everything to do with poor development.
They're not really enterprise apps. They're just betting odds displays. But I hear you on the criticism of enterprise software still. I just don't think it's the thing here.
They could still be enterprise apps. From what I've seen of them, they appear to be little more than what you'd get off espn if espn were 100% betting. My point is it's not the system that they use to sync up lines and whatever...I think.
No. I'm not saying terribly designed, lazily coded enterprise apps are ok, I'm saying if Java can be fast on a $200 mobile phone, it can be fast on a desktop.
IMHO, the history was different. Java applets were initially secure in a sandbox and faster than what was possible with the "javascript" of that era.
Applets have become slow to start many years latter when bloated "enterprise" applications have been produced in abusive ways.
The security of applets has started to deteriorate a bit slightly before the death of Sun. It has become a security hell only since it is in the hands of Oracle.
The startup time was horrible. The speed, once it was running, was good, but the startup time made it completely unusable on the web. The ugly default UIs in Java did not help.
I did my fair share of applets back in the day, starting with the very first public versions and have very vivid memories of the loading screen :)
I always wonder -- if Sun had forced people to build their own loading screen UI per applet -- how the perception of Java (and Java Applets) would be different.
You should also take into account that internet speeds of that era were not as great. Today, we download multiple megabytes of javascript. Back then downloading the same multiple megabytes of java was slow because of network.
I recall loading webpages in IE where the browser would completely stop for 30 seconds while the JVM fired up.
JavaScript at the time was mainly used for snow flakes on the web page or annoying mouse trails on the web page, as I recall. Oh, and maybe rollovers. I remember Microsoft pushing DHTML and seeing IE4 as a leap forward compared to IE3 but I do recall Java being slow. And slow.
It's fairly rare to have web UI's built with canvas and WebGL - usually because they need to do something that is impractical using the DOM. They'll still use the DOM for the more conventional parts of the UI.
I think the key difference is you get to that incrementally. You start by "making the monkey dance" on an otherwise-static page, and you can work your way up to rendering everything on a fully-programatically-controlled canvas, a little bit at a time. Forcing you to do everything yourself from the start as TCL (remember tklets?) and Java did makes the barrier to entry much higher.
Java did have an API for accessing and manipulating the DOM since (iirc) JDK1.4 -- org.w3c.dom and sub-packages. It was not at all well known or publicised, though.
I agree on all counts, but have to say that Java Webstart was cool, it was a pretty neat way of installing and running applications directly from the web. Maybe not very secure, though.
One problem I see with Google's ecosystem is that they've betted on the wrong horse - Java is a pain in the ass and Android's Java foundations are its second largest weakness. (The first one being the Google-Vendor relationship that makes all but the very latest Android devices unpatched and 100% insecure.)
> ... Short of having a jvm always running on your machine ...
This is basically how Dalvik/Zygote worked on actual Android.
From what I know, Chrome too uses always-running background processes even if you don't have a browser window open (for mainentance work and to improve startup times).
You're forgetting something: This will not work for iOS. Why develop something which excludes a big chunk of the cake? I'm happy Google is not going this way... Apple is doing already enough damage with exclusive features.
> This will not work for iOS. Why develop something which excludes a big chunk of the cake?
By that logic nobody should even create native Android apps today. You're saying that if Android apps could run on even more platforms it would somehow stop being worth it to create them because iOS is excluded? Makes absolutely zero sense.
I would also go even further and would say it makes in MOST cases no sense to develop a purely native app today. From a economic standpoint most native, one platform apps make no sense nowadays (also many people are unwilling to install more apps) unless you have deep enough pockets. I'm happy that Chrome embraces the web and pushes web application even further. I see really no benefit in running Android apps on my Mac (this results in mixed touchscreen, non touchscreen experience). So Chrome is pushing technology for this 80-90% of devices but it is not Android (with its touchscreen focus) and I'm really happy it is the web which I can use on more devices with different UX handling and without installing stuff.
Would android apps be a good fit for desktop? Most of them do not even work well on a tablet and I think they would scale very badly to even touchscreen laptops.
I doubt that most developers would do any effort to have their apps "responsive".
I wish I could run the Trello app on my touchscreen laptop, if only so I could drag cards to the top to archive them (for some reason the web UI doesn't offer that). I wish I could get Google's suggested pages there. And for a lot of Amazon's apps, the Windows version feels like an out-of-date port of the Android version where I'd be better off running the Android version.
Phones and desktops are completely different form factors with different constraints. Running an Android app on Windows would be a horrible experience.
I'm not saying that the app would have exactly the same UI on a phone and a desktop computer - the developer is free to customise the UI for the device.
'Most' apps do not get used even once [1] so their user experience doesn't really matter.
Most popular apps are designed for both tablet and phone. The ones that haven't specifically been designed for tablet are usually basic things like Guitar Tuner or Flashlight which don't suffer much from having a phone layout on a tablet.
Sure, you will still sometimes encounter a crappy app which has a horrible user experience on your device - similar to web pages and webapps which assume you have a 24-inch display - but not often enough for users to avoid the platform.
> I think editors more like acme and less like vim might rise up.
Acme, and anything like it, would be completely horrendous on a touch interface. I use it regularly (although I find that I prefer Sam).
Edit: Then again, I have touchscreeens on many of my laptops. I don't find them useful. With the exception of drawing art, I wouldn't miss them if they disappeared.
I'm no so sure about "anything like it". A pen for easily selecting text, a one-two-three finger tap and/or a wheel/secondary input might work with a similar interface to ACME?
What does acme do to help on touch screens? I while ago I toyed around creating a vim keyboard for android, instead of having a virtual keyboard popup it show commands/motions instead. I abandoned the idea, but if text edition on a touch screen ever becomes feasible then I think the virtual keyboard has to go.
Unlike emacs or vim, acme leverages the mouse/gui for powerful editing - and I believe (multi)touch screens have the potential to be better guis than than screen+mouse. For one thing mice generally utilise at most three fingers and one hand - and IMNHO while eg blender/photoshop combine mouse and keyboard - the combination is awkward and not very intuitive.
I think (but am far from certain) that acme is a more promising approach.
Now this is a reasonable objection. Small form factor touch screen interfaces just don't work the same way as mouse-based desktop interfaces with acres of space. Trying to use a phone UI on a desktop is heinous (as is pointed out above with Windows 10 as the example.)
I used to regularly remote into a windows box (GUI mode, classic desktop) from my phone. 2560x1440 pixels of 21st century glory. Believe me when I say you do not want to use a desktop UI on a phone either. No, pinch-zooming hasn't proved to be a sustainable workaround.
This would have been the way to build Linux into the next great desktop platform. I dont think people mind a 1GB Chrome runtime if it opens up a billion apps for them.
I think apps can be handled well by both browser and mobile phones. Considering that ART runtime also JIT compiles the java code to native, performance should also not be a worry.
I worked with a company that was part of the beta for ARC Welder and it was a very experimental product experience. Things were hit or miss on chromebooks. Support from Google engineers was amazing though.
Google has Chromebooks securely locked down, down to the hardware crypto -- there may be (speculating) inherent security issues with running mobile apps in the browser when you can't lock down the external environment.
The fact that it is an android app doesn't really matter. Your question becomes essentially "why would I want to run any app on Mac?" which I think you can figure out the answer to.
Android is already dominant on mobile. Desktop market is shrinking. "Running" doesn't correlate to a good experience. Google probably thinks about that stuff.
I don't think we really need another locked down OS where the vendor will control everything.
The other issue I have is that I don't see Android apps as efficient way of getting my work done, applications that don't need to worry about the mobile form factor will most of the time offer a superior user experience.
You already have a 99% cross platform way to ship an app, you can create a web app.
I don't think we really need another locked down OS where the vendor will control everything.
The other issue I have is that I don't see Android apps as efficient way of getting my work done, applications that don't need to worry about the mobile form factor will most of the time offer a superior user experience.
You already have a 99% cross platform way to ship an app, you can create a web app.
You could argue that webpages were never meant to host the kind of rich experiences and workflows native applications are known for. We just made it that way through years and years of momentum.
Why can't the pure web replace apps and programs? All the pieces are almost there: hardware acceleration, service workers, notifications, responsive design...
I currently "add to home screen" for most things. I edit my images online, and develop code using cloud9 ide, etc. There are few things I need apps/programs for right now, and that's improving day by day.
iPhone is dropping heavily in world wide market share, but they still have a lot of the wealthy users. There is a non-zero chance they get niched out of prominence by Android (aka every other manufacturer in the world), at which point network effects start encouraging Android-first or Android-only development. There might be a point where Apple needs to double down on the web, and/or maybe kill off apps, like they did flash, to still have the latest "apps".
That's just my anecdotal view, but I have never tried a web based app (electron native app thing or webapp in the browser) that is as great an experience (UX and UI) as the best of the best native apps on Mac and iPhone, and I'm not sure it's possible to push web tech that far without reimplementing everything in the web stack and making it as close to native that we're better off just writing native apps.
> but I have never tried a web based app (electron native app thing or webapp in the browser) that is as great an experience (UX and UI) as the best of the best native apps on Mac and iPhone
I would say I have never tried a web based app better than average native apps. (Except for GMail, because I don't like the sync feature of mail clients).
Because it just sucks, browsers were designed for interactive documents, not applications.
No HTML5 UI/UX comes close to what is possible to achieve with native APIs in any platform.
For old dogs like myself, it always seems that younger web dev generations are rediscovering patterns and features we were already doing in native applications during the 90's.
Also solutions like service workers look like some sort of kluge to sort out the problem to do offline applications in browsers.
WebOS, ChromeOS (barely used outside US) and FirefoxOS are all proofs that the experience is substandard.
I take photos miles from where there's cell signal. I write code on the bus while heading to doctors appointments. The web is about as far from a panacea as you can get. It's slow, it's bloated, falls apart when you don't have a connection, useful applications die when the company dies. Were some of the midi devices I use for music "web-based" they'd have probably become doorstops decades ago. A web-based IDE would be horrible for trying to develop code with an intermittent connection. The web is not a good time.
The intermittency issues can be fixed but I agree that the dependency on web app providers and their fickle business models is scary.
The way it works is to funnel all the profits into a few huge conglomerates that benefit from exclusive access to all personal data and train users to never depend on anything that isn't a core product of one of these conglomerates.
Using their 80% margins they can afford to at least give us some time before scrapping software that doesn't look it's ever going to reach 4bn consumers.
The result is stability. Until they all get toppled by the next technology revolution. Years later, regulators will crack down hard on some of the side issues of their former dominance and once again miss the currently relevant issues :)
The main reason I wouldn't want web apps, even if they somehow became as fast and integrated as native apps, to become the standard, is because they automatically update at the developers' whims. Vim won't change unless I make it change.
"Almost there" does not count. It has not just be there but be better at everything. And I will argue it is far far away from even "being here". I am getting tired of repeating this each time, but "web everywhere" folks simply have no idea what native SDKs offer.
> iPhone is dropping heavily in world wide market share
And taking all the profits. Android being everywhere does not mean that every Android device is being used as smartphone, quite often they are just replacements for a feature phones.
This blogpost has waaaay too much assumptions. When reading about this it seems easy to rip out Kernels, OS & Software and put it like a layer on a cake on top of a new OS. Even for Google this is crazy complicated. It will not be that easy. For sure not... and I also see no clear strategy WHY somebody should do that. It's like baking the cake with too much ingredients. ;)
I can see the kernel thing happening. Just the licensing and breaking ABI is one of the biggest factors in not being able to have an easily upgradable android.
I only see this as a good thing if this ensures an easier upgrade path than in Android; and if vendor ROMs can easily be replaced by a stock OS (like on Windows).
I definitely can not see the Kernel thing happen. Ever thought of power management and keeping the whole system fluent? This are all not easy problems which you solve in 1 or 2 years. It may only work for very specialized hardware... speaking of hardware. Hardware driver support is also something most other Kernels suffer from in comparison to e.g. Linux.
> Hardware driver support is also something most other Kernels suffer from in comparison to e.g. Linux.
So?
Google doesn't have to support all hardware, they can pick to support only the hardware they want. That's what they already do with ChromeOS. Installing ChromiumOS on unsupported hardware can have its issues. The reverse is true too, installing not-ChromeOS Linux or another OS on Chromebook does not always work well, although it's fine on some specific models.
Android is like that too, and in a much worse way than for Chromebooks. We're not talking about stellar linux kernel support for all the custom ARM SOC that are out there. All manufacturers write their own closed source hardware support for android and this is how android ends up having issues with updating, since whenever Google updates the linux kernel it breaks the ABI and all the support manufacturers wrote for the previous version, and manufacturers do not want to spend so much time on needless busywork such as keeping up with kernel API churn that exists just to satisfy the dev team sense of perfection.
This could be the first time Apple needs to truly worry about Google. The one massive lead Apple still has over Google (and the other major players) is the incredible OS they inherited back in 1997 and continue to extend and maintain today.
Neither Android nor Windows nor Chrome OS nor your favorite Linux distro have ever been able to truly compete with the NeXT legacy as it lives on in Apple.
Google is smart enough as a whole to see this, and so it's not surprising that they're attempting to shore up their platform's competence in this particular area. What IS surprising is that it has taken them this long.
Perhaps what's truly surprising is just how much mileage Apple has gotten out of NeXT. It's astounding, and I know Apple realizes this, but I question whether or not they know how to take the next step, whatever that may be. And if Google manages to finally catch up...
Android's global market share, even with Apple, is 85%. Bear in mind, the iPhone is only popular in the US, which is responsible for most of the remaining 15%. Outside the US, Android is a completely unquestioned monopoly.
> Neither Android nor Windows nor Chrome OS nor your favorite Linux distro have ever been able to truly compete with the NeXT legacy as it lives on in Apple.
I find this a funny statement. Apple has not seen runaway success in terms of market share, not on desktop platforms (where the top OSes are various versions of Windows), not on mobile platforms (where it is a distant second to Android in the worldwide market), not on server or supercomputer platforms (where it's effectively nonexistent).
Nor is it influential in terms of operating system paradigms. The only thing I can see people citing as a Darwin innovation is libdispatch. Solaris, for example, introduced ZFS and DTrace, as well as adopting containers well before most other OSes did (although FreeBSD is I think the first OS to create the concept with BSD jails)--note that Darwin still lacks an analogue.
AFAIK the flutter UI framework is a react-like framework written in Dart (with C++ as OS glue) including the UI -> graphics rendering layer. It builds upon Skia and Blink. I am not sure how that will allow compatibility with other languages. The only language for UI apps looks to be Dart. Which isn't bad - its a pretty well designed language, but I don't see how apps can be written in a wide variety of language as the author suggests.
From a developer's point of view, on one hand, I like this idea. Just about any development environment is better than Android:
1. Callbacks are horrendous. I hate inner classes, they're ugly and unwieldy. I'd honestly rather something like AWT's (Yes, that 90s tech) callbacks over inner classes.
Just have a main function with a large switch. It's much easier to reason that then the current mess-up of trying to figure out your app's lifecycle.
2. Inter-thread communication is horrendous. Android is Java based, so can I pass classes?
No.
Only Strings.
And even that is horrendously ugly.
3. It's a Frankenstein model. It's a Desktop OS like process/file model, but not everything is a file. Now they suggest opening using the new file-picker.
But in many ways files are easier to use.
4. They add new libraries (Material Design, for example) which no one will ever use, because everyone needs to use appcompat. And even in five years, when Lollipop will be like Android 2.2 is now, everyone will still have to use appcompat to get Android Z libraries on Android O, or something. And by the way, now most apps rely on appcompat-7 which relies on appcompat-4.
5. Many classes are broken - Take TextView. You can style it with HTML, but only a small subset (so you can't use it as a WebView). So it's not meant as a "web browser" replacement. But it can parse broken HTML. Wow, so developed.
But you can't style a link color, or change underline color.
------------
But on the other hand, I'd find it horribly annoying (and I think that many others would feel the same way) having to rewrite everything from scratch into Dart or whatever.
I didn't see in the article explanations why those decisions were taken and not others. On the surface it feels like this is an OS insufficiently different from others to justify switching to.
560 comments
[ 5.0 ms ] story [ 354 ms ] thread[1]https://lwn.net/Articles/597293/
Source: https://github.com/kubernetes/kubernetes/blob/master/LICENSE
A good example of that is Visual code. I am sure some at github (atom's paprent) is pissed.
https://fuchsia.googlesource.com/fuchsia/+/master/LICENSE
https://fuchsia.googlesource.com/magenta/+/master/LICENSE
https://fuchsia.googlesource.com/
Having said that, the reports I've seen contain scant actual evidence that Google actually plan for Andromeda to replace Android, or even that Andromeda is at all important to Google. I take these reports with a mountain of salt. I remember that the "Pixel 3" was definitely just about to be announced back in late 2016, and was definitely going to be running Andromeda OS.
https://android.googlesource.com/platform/ndk/+/master/docs/...
<quote>
Remove GCC
GCC is still in the NDK today because some of gnustl's C++11 features were written such that they do not work with Clang (threading and atomics, mostly). Now that libc++ is the best choice of STL, this is no longer blocking, so GCC can be removed.
</quote>
(or that's the story as I remember it)
Imagine how easier contribution would be if you could write the OS parts with less lines, guarantied to no introduce most security and concurrency bugs we know about.
It would really surprise me if Apple got there first. Tim lacks vision and will keep on milking iOS even if the iPad Pro is a failure as a laptop replacement.
Windows is still king in the desktop space, at least as far a user base goes, but it's terrible on tablets and phones. MS has all the tech in place with UWP, but it's still pretty far in the race in terms of simplicity and usability.
Chrome OS ticks all the right boxes, and is experiencing a huge growth, but it's not universal. If Andromeda is real, and it's able to become a universal OS that merges Chrome OS and Android it might be the best thing since sliced bread.
All hail Universal OS!!
There is a small terminology issue here: a "server" is a program that offers services to remote "client" programs. The clients make requests and the server responds to them. A client program will make a request like "allocate me a chunk of the screen and put these here bits in it", or "let me know about any of these events that happen". The server manages the screen and notifies the clients about things they're interested in.
IT MAKES PERFECT SENSE, DAMMIT!
I agree, it actually does make total sense - but that doesn't mean I won't get confused :).
My only prior exposure to "GUIs over the network" were web applications, where the roles are essentially reversed. That is, the part responsible for accepting user input and rendering the UI is the client (the browser), and the part that performs the application logic is the server.
I naively assumed that X would work the same way, but it wasn't too hard to unlearn that misconception.
As of now, I never use Google drive sync, I use syncthing to sync folders between mobile and my Mac.
Universal OS rocks! (I hope it is in line with my vision of how the concept of universality is) I want to just visually ssh the phone and the machine, or rather the OS is in the phone and I just connect it to the machine, there was some project recently I don't know if it is available now.
Edit: Why the downvotes?
Beginners are typically terrified of anything they don't understand. I used to teach computers 101 to university students, and they'd pretty much freeze up every time they saw something they weren't expecting.
Then, after I was comfortable with everything did I start learning AJAX, I chose Vue.JS and I migrated the app I wrote in pure HTML to use Go [3] and wrote a guide about it [4].
I pissed a lot of people of VueJS project when I raised this [5] issue, yes, in hindsight I do realize that I was rude to them, but their documentation had a problem (and I had already said sorry if I was rude)
I still don't know how to use websockets and what not, or how to write load balancers or distributed database, or web proxy or cache or other things to be done at scale, I choose to ignore them as of now, as I build my capability to understand or until I need of them.
This is what I meant by that statement.
>they'd pretty much freeze up
You know, in 2010, I still remember the first C programming class (I had not understood a single word) I had in my college, I froze and for a minute questioned if I had made the right decision to enter computer science. The point is that newcomers need to know what they can ignore while they learn the basics, it is not possible to learn everything in one go.
Nobody teaches you real life, it just happens, and as a newbie it is my responsibility to learn in the best way I can without getting overwhelmed, and no, it is not a disparaging statement!
Also, this is why I started Multiversity[6], this is a YouTube channel which teaches by example.
[1] https://github.com/thewhitetulip/web-dev-golang-anti-textboo...
[2] https://github.com/thewhitetulip/Tasks
[3] https://github.com/thewhitetulip/Tasks-vue
[4] https://github.com/thewhitetulip/intro-to-vuejs/
[5] https://github.com/vuejs/vuejs.org/issues/565
[6] https://github.com/thewhitetulip/multiversity
...about that steering wheel...
Wait, do we? Why?
I think why they would _not_ have the same interface between similar hardware and similar applications is a better question.
As for the user interface and bundled applications, let's not confuse "Operating System" with that although it's popular for some stupid reason. The one and same OS could of course have e.g. completely different window managers adapted for different human-device interactions and use cases. But that's very distanced from the actual OS, that is pretty much only interested in how to run and expose the hardware to the software.
I don't buy that a finger and a mouse/trackpad pointer are equivalent input devices. One obscures the display and is imprecise. The other, well, isn't.
I'm fine with a different server OS than desktop. I see no compelling reason why I need a single OS for all of my personal devices.
Not only does the OS UI reflect the input method, every single application you run does as well. A touch-optimized application will be clumsy and primitive when using a mouse; a mouse-optimized application will be miserable when using a finger.
If an application can be written once for both, often it'll be a poor compromise or only properly support one of the two input methods.
Look at how awful early Java "write once run everywhere" applications were. Yes, some of that was the Java platform itself, but developers were given the opportunity to ignore platform-specific UX concerns and many eagerly embraced it.
I think a single OS for them all is fine.
Consider gnome+linux vs android+linux. They're both linux, and they're not the same platform.
That's clearly not what the original poster was arguing.
But what if you could use the same language and frameworks on all devices? The same tools (IDE, code editor, compiler, etc)? That's what I'm referring to.
It's obvious that the UI has to be different depending on the device, input, etc.
Also, I really don't see how a developer could argue against the notion of having a single language, API, IDE, compiler, etc, for working on all devices.
> Combining Chrome OS and Android is uninteresting to me, since I wouldn't be able to develop on it or really do any of the things I use a computer for.
Time will tell.
Apple will have to go through all of the growing pains Microsoft has already weathered, so they're miles off, but maybe they can do it faster because they don't care as much about what people think of them, and are willing to do whatever they think is right (if it is or not is to be seen).
Google is well placed because, while they have a bunch of platforms, the only one in the desktop space is basically dead, and really didn't ever have too much investment in it, so not too many feel put out if they get rid of it. But that not even the case, because they're able to engineer everything so that it stays relevant.
Might be limited to your specific environment though. As a counter-example among the people I know there are far more .NET devs than the total sum of iOS/Mac/Android devs.
Then I have to agree with you; UWP will go the way of Windows RT & the dodo, unless MS forces it as the main dev paradigm (which seems unlikely).
It's sad that ReactOS doesn't get more support from the community.
Surface tablets seem to be doing OK though.
We need competition. A single OS controlled by a single corporation with their own conflicting interests is a million miles from what we need.
Apple's CEO lacks the vision and is milking the status quo. Their iOS market share is a lot smaller and limited to a few devices.
Microsoft's CEO lacks the vision and is aggressively milking the status quo. They aggressively try to enforce a switch to software-as-a-service plus they are no in the gray adware/spyware business capturing way too much end user data which shades bad light. And the killed their QA. Their products since 2010 are a disaster. That's why XBoxOne tanked in all market beside US, WinPhone tanked world wide, Win8 and Win10 marketshare is lot smaller than Win7, which is the major desktop OS - and there is little reason to switch away from Win7. MSFT would profit from a 180 degree U-turn with a new management.
Obviously different devices need different UIs.
That seems very, very dangerous to me.
Actually we already are in the red zone, I just wish we don't go crimson. But I doubt people will care. They didn't up to now, no reason it changes.
For anyone interested, I intend to write quite often about consumer technology on this blog. Topics will include hardware, software, design, and more. You can follow via RSS or Twitter, and possibly through other platforms soon. Sorry for the self promotion!
Thanks for reading. Please do send any corrections or explanations.
https://chromeunboxed.com/some-andromeda-perspective-hiroshi...
I think you alluded to this, "cue endless debates over the semantics of that, and what it all entails," but it might be worthwhile to add the official statement.
Maybe a long term project? I think Google is at a position where they can write a great OS from scratch, learning from the mistakes of others, and it has a chance of becoming the greatest OS that ever was.
With the talent of it's engineers, they can bring new ideas that can be better implemented, from scratch on a new OS. They already have a bunch of languages, web frameworks, and so many more technologies from Google that can be well integrated in this.
And looks like the project is mostly BSD licensed, which is great! I'm excited for just that alone.
[1]:https://github.com/fuchsia-mirror
It's typical market-o-speech.
They are not actively working on this :
https://github.com/fuchsia-mirror/modular/commits/master
For no reason.
Also, considering the way that the ARC runtime for Chromebooks was a failure and had to be replaced by a system that apparently essentially runs Android in a container, will it really be possible for a completely different OS to provide reasonable backward compatibility?
Their reasons that "dart is better" is the typical google koolaid before they attempt a market takeover. As we've seen over and over with Android, chrome, and AMP especially. Google loves to make glass house open source projects you can't touch. You're free to look at how great it is, feel it's well refined curves and admire the finish, but God help you if you don't like how the project is going and want to fork it for yourself.
Don't bother trying to commit a new feature to any of Google's software that they don't agree with. It will languish forever. Don't bother forking either, because they'll build a small proprietary bit into it that grows like a tumor until it's impossible to run the "open source" code without it.
Fuck dart, I don't care how great it is. Microsoft is being the good one in this case by extending js with typescript, google is trying to upend it into something that they control
But every open source project has standards about what they merge. Try getting a patch into Linux and see what they say; it won't be a rubber stamp.
With AMP, the instant you fork and change a single character of code it becomes incompatible because part of AMP is a verifier that makes sure only the official version is used with Google's cache. Without being able to serve your custom AMP pages from Google's AMP cache the entire point to its existence goes away. The reason? Typical "security". "Tampered" versions of AMP could "do bad things", laughable considering that vanilla web pages allow you to do absolutely anything javascript allows and google has no problem showing those pages in search results or letting them freewheel in a Chrome tab. If Google wanted AMP to be open they would have built it into their chrome browser so the browser could enforce restrictions while allowing users to run whatever customized AMP implementation they want.
And Android. Android used to honor the promise of being open. Years ago. This was before every manufacturer was encouraged to lock bootloaders, and back when platform SDK's and drivers for hardware were generally available even if they were kinda hard to get. This was also before the Android kernel heavily diverged from mainline Linux, and before "google play services" grew from a tiny app to a framework that powers half the OS features.
Nowadays you can only run your own Android on devices specifically built for it. Open distributions like CyanogenMod are dead or dying. Google Play services is closed and proprietary, and probably about 95% of popular apps require it to work. Even if you manage to get your own Android distribution built and running you will need to side load all your apps, and most apps just don't work because they've been built to depend on proprietary bits that Google has snuck in all over the place.
Google is better at the "embrace, extend, extinguish" strategy than Microsoft ever was. So good, in fact, that they have many well intentioned people defending them to the death even as they choke off the very open source projects they created. Virtually every platform that Google runs for more than about 5 years goes from completely open to something impractical to run yourself. If you don't believe me look into any of their older projects that are "open source".
After a certain point it's free software as in "free coupons". Somewhere in the mix, eventually, the price of of their "charity" is passed on to you.
Google's projects all seem very inviting from a distance. Usually it's not until you're ready to implement something that you find out that you're fucked, and how.
Serious ranting below but something I never get a chance to say:
I'm a born skeptic and avoid the silicon valley mindset even though I'm a driven person. I used to find myself often in disagreement with others because they don't or refuse to see the truth. Some people don't like to be told they're wrong. Many of those will fight other opinions just to justify their own decision, but will secretly reconsider. Others will hang onto beliefs with every ounce of strength as their mistake builds into a Maelstrom that consumes everything they care about.
With some people, after challenging their beliefs, they will end a friendship rather than admit you were right in the first place. Especially if you refused to do something their way and it saved them from disaster. Some can't stand to be THAT wrong. As if I was some asshole who saved them from their fate, and now they're a spirit left wandering the earth until they can fulfill their original destiny. Its like I helped them cheat without telling them about it, stealing the joy from victory. This is something I learned the hard way more than once.
In real life I keep my opinions to myself to avoid this nastiness, and offer opinion only when asked. The people open to advice even if they disagree learn to ask my opinion since I always tend to have one. The majority of people I know, including some good friends, have no idea what my personal opinions are on many subjects. It would cause pointless pain and argument with people I care about regardless of their beliefs.
I'm not loyal to any platform or company and I will freely throw a strongly held notion to the wind if I find disturbing evidence that I was mistaken. Most people are not so malleable.
A lot of people take their beliefs too seriously to the detriment of society. At least on the internet I can express my opinion, however "uncool" using throwaways.
In the real world the best and most meticulously researched advice I've ever given is at exit interviews. The one time you can be open, honest, and politically incorrect with coworkers. Multiple companies made serious operational changes after giving my exit interview. Others have told me in nicer words "that's really fucking great to hear I'm pretty happy I never have to talk to you again".
The problem is, you never know how somebody will respond. During exit interviews I'm treated more like a person than a subordinate since the boss relationship is formally over, which helps I'm sure.
In real life, the way to influence a strongly held opinion is best decribed by watching the movie Inception. You introduce nothing more than minor inconsistencies while outwardly expressing little opinion, then wait to see if your clues are enough to lead them to towards the promised land.
My other common tactic is to do things without asking any opinions first. You at most come off as insensitive, aloof, rather than someone to intentionally disregard their advice. Usually the opinion matters less in practice than if you had asked in the first place. Classic forgiveness is easier than permission.
Ive sometimes wondered if this makes me a physcopath or if that's just how some people tick. Anyways, god bless throwaways and the internet
Fighting the good fight, fighting for the things that are just, and true, and good - are nearly always worth it, the key is to back off before it becomes a pyrrhic victory.
That's a lesson I had to learn the hard way.
It's not being evil or that I'm always right. The comment was mostly in reference to those that have been calling me a shill the past few days and how they should keep in mind that their opinion is not fact.
I gave up the good fight years ago. The worst was when I helped turn around a failing small business. We all wanted the same goal, the company to be successful. It sucked so bad that I learned that it's better to be nice to your friends than to dedicate yourself to a cause or try to fix all their problems.
If that means letting them fall sometimes that's okay, as long as you don't let them get any deeper than you can reach. If you help pull them out in the end you're still a good friend.
So the company turnaround, it worked in the long run but at great cost. Cutting employees that sucked at their jobs but were friends and helped us with the initial plan. Cutting moochers that I loved but were sucking the company dry with constant unscheduled time off and freebies. Redoing our systems to automate as much as possible made us our first profit in years but a lot of that was from jobs eliminated. Hiring people of a higher caliber than existing employees by raising application requirements above what most of the current employees would meet. Offering our new more qualified people more money than Bob who's been here for 15 years but did our financials on pieces of scrap paper.
By the end of that process a few years later, my lesson was that I made the owners a lot of money at the expense of losing about half my friends. Most of the other half resented me for what I had done and thought I was a traitor, even though I had just helped implement exactly what we had agreed upon a few years back.
We planned to cut dead weight and streamline and automate operations. To add new talent with up to date skills. To cut our benefits slightly to money to invest in the company's future. Everyone wanted this until it was their benefits or their job being automated. I followed through with the cause and at the end I felt like a Judas figure and packed up and left in shame.
You could say it was a pyrrhic victory for sure, but after that I'm very wary to set anything in motion that's too heavy for me to stop on my own
Omega Man is an interesting term, never heard of that before. You're totally right that it's how I try to operate but only when I'm doing controversial things. Perhaps I'm doing it right if I seem to be going about it in the most quiet and passive way possible :) .
You don't have to worry about me running any communities online. I'm a productive member on a bunch of online communities including HN and I don't use my throwaways to respond to, upvote, or otherwise sockpuppet my regular account except a couple times I admittedly may have upvoted the same thread on different accounts by mistake. Most of my less opinionated stuff is under my real name
The only reason I respond sometimes is because I disagree. Sometimes my controversial opinions prove to be a lot more popular than I thought. And possibly miraculously, all of my throwaways eventually gather substantial positive karma despite the fire and brimstone rained upon some of my comments :)
http://penguindreams.org/blog/android-fragmentation/
We can't have the 90s Linux revolution for handhelds because they each need customized kernels and drivers. Many fall into disrepair and go unmaintained, even in things like Cyanogen. (On two phones I tried running newer CM images on old hardware and ran into speed and performance issues).
This is why things like Plasma and Ubuntu mobile have such limited phone support. Porting is difficult.
Also notice that I said "PC" above. There are plenty of x86 systems that are just as difficult to port to (PS4, Wonderswan, those old T1 cards with 4x486 processors on them). At least Microsoft forced their ARM manufactures to use UEFI. Too bad those platforms have locked bootloaders. I'd love to see some Lumia running Plasma.
How diverged is it? Would the ever be merged back together?
Android is missing a ton of new Linux features on many devices and the kernel is getting increasingly unusable by ARM devices in vanilla form because of these badly done third party modifications
Google making Google play services was a natural reaction to manufacturers never updating Android on their phones for years leading to all kinds of vulnerabilities and bugs on Android that kept it far behind iOS in quality and features. Lets face it - Android used to be sneered at, the red-headed problem-child OS that used to the butt of jokes till it grew out of puberty and pimples in Ice Cream Sandwich. If manufacturers had truly honoured OS updates, Play Services may never have been built - it allows Google to update Android without updating the OS. And yes, they will retain full control over Play Services - I completely understand the need to fully possess it and ensure a high level of quality assurance.
Also blaming the fall of CyanogenMod on Google is ridiculous. CM fell because of mistakes made by Kirk Mc Master and several others. He attempted to be a dictator even going to the extent of banning OnePlus phones selling in India - this was fought and resolved in the courts. All goodwill for CM was destroyed. OnePlus ditched CM and moved to Oxygen OS. CM had a stroke and died. Now Lineage is the new shiny OS rising from the cooling corpse of CM.
I still disagree with play services because it wouldn't be that hard to force manufacturers to support updates when you command such a large part of the market
There are these things called contracts, and if there are clauses for an OEM to be allowed to have access to Google services, Google lawyers could certainly add a few more sentences regarding compulsory updates.
Android isn't open source, except in the hearts and minds of fanboys everywhere. =)
Good luck getting all those apps running without Google services, or getting the devs to re-written them to use alternative APIs.
It only works in countries like China because of the way the government controls everything.
I pretty much doubt anyone cares about Amazon or Jolla's fork, or cared for the Blackberry's one.
It is just about not caring one second to enforce updates.
The only thing Google is directly responsible is Google Play Services, and
1. A good of that is a shim to Google's servers.
2. Is small and emulate-able (especially if you don't really intend to connect to their servers).
3. One can run plenty of apps without it. Mostly Open Source, but I've heard of people running CM without Google Play. I've never heard anyone run Windows 10 or iOS in OpenSource mode only.
It continues to be a weakness of the Four Freedoms model.
(See http://www.ecma-international.org/publications/standards/Ecm...)
And yeah ECMA is a totally open standard with committee members from all sorts of companies and backgrounds. Dart is not. I don't care if JS is slightly worse, as least I know that for now and the foreseeable future I won't be paying a google tax to use it.
After the open source community "stole" mapreduce and hbase google has begun offering maglev and spanner as "services" rather than giving them to the OSS community. Maglev was supposed to be open sourced a while ago, and google now offers DDoS protection service on Google cloud instead, most famously with their Krebs PR stunt. Maybe they forgot about it? Did I mention they removed "don't be evil" as their motto a while back because it was "immature"?
Google has begun down a decidedly different path since the Alphabet transition a while back. It's no longer the brainchild of Sergey and Larry, it's losing its soul and becoming a shareholder cash machine. Maybe the floundering of some of their moonshot projects is taking a toll on the companies' confidence to remain a market leader while maintaining their traditional values of openness and shunning of questionable marketing tactics? I'll admit that's pure speculation but I really wish I knew what happened to the Google I remember.
Since I'm being accused of FUD I might as well throw a bunch more speculation in for the hell of it. Their most recent papers are conspicuously lacking enough detail to make your own implementation, and read more like marketing whitepapers on how to use their services and how great they are. Their tensorflow library was probably released as truly open only because they couldn't hire enough devs with machine learning experience to meet their needs. They needed to introduce the world to enough of the secret sauce to meet their own demand and they remain completely silent on how their real moneymakers work.
My extreme speculation? They started using machine learning for search a few years back and found out just how easily their previous search algorithms, developed and perfected for years, were utterly outclassed within months. A start-up with these techniques could have been their undoing. This oversight cannot be repeated, they cannot offer too much of their technology back to the world anymore lest they risk being beaten to death by their own weapons. Thus google threw away a lot of what made them google, and rebuilt themselves as a semi monopolistic oligarch that's much more in line with traditional too big to fail companies.
They now spend more on political lobbyists than any tech company by far. They like to release nice things for free when a competitor just happens to be a making a decent living charging for the same thing. They engage in a lot of the typical corporate warfare now that doesn't seem natural for a company with a nice playful exterior and an original motto of "don't be evil".
As far as the FUD accusation, does it count that I don't work for or with any company that has anything to do with google or the other tech giants? These are just my opinions based on observations, and a lot of those opinions are backed by verifiable facts.
You're free to put the same data together and make your own conclusions, which would lead to more interesting discussion than dismissing my points just because.
It is not clear how they would "contribute" that to OSS
https://abc.xyz/investor/other/google-code-of-conduct.html
"Don't be evil" is the first and last thing stated.
Why do you post stuff that's trivially searchable and trivially called out as bullshit? Why would I bother reading any of your rant if you can't get trivial details right?
Dart is an ECMA standard: https://www.ecma-international.org/publications/standards/Ec...
OO is a bad word these days and functional is all the rage, even though functional languages were largely superceded by OO languages eons ago for many reasons people are slowly redicovering.
There's a huge push to put more structured language concepts into js now that it's being used for substantial projects and it's out of necessity more than convenience.
When I'm hacking together a quick Python script all that stuff gets in the way but when working on larger systems strong typing and object syntax are practically a neccesary evil for maintaining readability
Functional programming has origins in lambda calculus and academia because mathematical problems map more easily from pure math to functional programming. It's really popular in the circles where it's more useful/easier than OO.
Honestly I don't think the people 20 years ago chose OO for most business languages over functional out of ignorance. They had a choice and decided that OO was better for business problem solving languages like Java even though a large majority of programmers from that era were math majors and familiar with functional syntax.
I feel like we're in one of those cycles where a large number of a previous generation have retired and it's time to learn some of these lessons all over again.
Notice how many wood commercial buildings have been going up in the last 15-20 years? A lot, and just long enough after everyone involved in all the great city fires of WW2 to be too dead to object.
I'm going to ignore the social component... that said, we work in a wonderful profession where the world is changing completely every decade and many design decisions from the previous generation make no sense anymore. The business case for developing your application in COBOL rather than Common Lisp may have been sound 20 years ago, but today many of the reason why you didn't choose lisp are invalid (e.g., garbage collection takes milliseconds rather than seconds).
Note that this is not the case in more mature fields such as construction.
No, it's not like that.
You can write readable code in any language as long as you can write readable code. It sounds tautologic, but what I mean is that ability to write readable code is a skill separate from writing code or knowing a particular language.
Strong static typing - as just about any tool and language feature - can have both good and bad effects on code readability. In the end, the readability (so also maintainability and other related metrics) depends on the skill of a particular developer in the largest part.
Both OO and FP techniques, as well as all the language features, are the same. You can misuse (or ignore) them all.
What we need is to make an "average developer" better at writing code, not more bondage and discipline in our tools. The latter is (a lot) easier, so that's where we focus our efforts, but - in my opinion - it's not going to solve the problem.
Dart is a replacement for GWT at this point. See AdWords being written in dart now[0]. Though it's not clear now Flutter.io will play into all this (that's targeting mobile with no web target).
As for typescript, Google actually embraced that fairly heavily with Angular2 being written in it.
[0] http://news.dartlang.org/2016/03/the-new-adwords-ui-uses-dar...
https://webdev.dartlang.org/angular
I disagree with transpilers not being a reasonable answer. Eventually JavaScript will be okay to work with, some day. Until then, transpilers offer nearly unlimited freedom in redesigning the bad parts of the language while maintaining 100% fowards and backwards compatibility. It's really as good as it can get.
Since they compile down to a Turing complete language there's really no limit to the heaps of dog shit they can abstract away. Historically, c++ is nothing more than an insanely complicated C preprocessor and it has more than proven that such a strategy can be viable long term. In fact, the first c++ compiler made, cfront, is still available and literally outputs raw C code from c++.
Typescript is easily my favorite since it's designed to compile down to very human friendly JS. Getting typescript out of your stack requires nothing more than one last compilation with optimizations turned off. Unlike most transpilers (looking at you babel) the output JavaScript uses standard JS workarounds like the crockerford privacy pattern for classes. This gives typescript fairly practical fowards and backwards compatibility. You can always target output to a newer version of js or convert your codebase out of typescript back to js at any time.
If it catches enough traction, browsers will begin implementing native typescript parsing since it offers many potential performance optimizations on top of what js is capable of. At this point you just maintain your typescript codebase and use some library to give your legacy clients some transpiled J S on the fly.
If typescript gets enough adoption it will fix JavaScript for good, in the same way the original c++ compiler (which just transformed to c) led to native support, so I'm really rooting for it.
If having code work almost everywhere is important for a project, that project will be using vanilla ES3-5 JavaScript for the next 10+ years. Maybe not the latest startups but all sorts of enterprisey ancient stuff that needs to run needs some path forward. If typescript can provide that it will become the lowest common denominator at any company that ships both new and legacy codebases.
Typescript to JS transpilation is extremely similar to the strategy that produced C++ from C. We know it will work, and it's been done before to great success. C++ isn't perfect but I think everyone agrees it's definitely a lot nicer to work with than C, and that's exactly how I describe Typescript as well
Having said that, my only exposure to Typescript has been in Angular 2. Having used other tools like Ember, React, and Elm, Angular 2 seems like a magic step backwards to me. I will concede that my opinions on Typescript may be tinted by my experience with Angular 2 though, so I'll give Typescript a stand-alone, honest evaluation, and adjust my opinions as necessary.
It doesn't, unfortunately. TypeScript's type system is unsound, so the VM can rely on types for optimization.
You can take as hard look at Google as you would like, but choosing Microsoft over Google (one for-profit company over another), while not caring how the technology, the licensing or the workflow compares is a bit hypocrite. (e.g.they are both open, and they both have rules of commits).
I'm wondering, why do you need a throwaway for such heavily invested FUD? Your other comments here are in similar tone, and I'm surprised to see such hatred without any obvious trigger. Maybe if you would come forward with your story, it would be easier to discuss it?
disclaimer: ex-Googler, worked with Dart for 4+ years, I think it is way ahead of the JS/TS stack in many regards.
Dart is a different language, it has no fallback to something familiar. I don't doubt that it's many years ahead of TS in every way but it's still rather proprietary compared to TS that I can shut off at any time with minimal effort.
The openness of typescript and dart are comparable. Both being run primarily by their champion companies with code free to review and fork but with limited ability to commit changes. They both require you to sign over copyright of code committed which I don't like for my own reasons but the license is open source.
The big difference to me is that typescript offers an escape hatch and dart does not, because one is pretty much a JavaScript enhancement and the other is completely different. I hate vendor lock-in and loss of the open web in general and you will see this as a common theme to most of my more flamey(controversial) comments. The web is closing off in so many directions and as an open source developer in my free time this is of great personal concern. I don't like that hackernews and reddit can be an echo chamber and posting contrary opinions usually makes the discussion more balanced even if a lot of people don't like it.
I'm not ex google, MS, or any of the tech giants. I'm not smart or dedicated enough to work anywhere you've heard of :). Most of my comments on throwaway accounts are unpopular, that's why I don't use my normal account. I'm not some invisible super shill, hackernews knows all the accounts I use and I'm fine with that.
I've just got my own opinions and when they're controversial it's not in my best interest to comment using my normal account. It wouldn't be for anyone. It would be utterly stupid to hurt my open source projects or reputation as a developer just because somebody doesn't like my opinions. My code and my work have no opinions, and I like to keep it that way. Throwaways are my way of keeping my opinions to myself, and I don't see anything wrong with that. Separation of church and state if you will.
I'm not totally against Google or any company in general. Microsoft in particular has an extremely rocky history when it comes to open source projects. They've probably done more harm to Linux than any company in existence. If typescript and dart both had equal migration paths I would choose dart in a heartbeat. I love tsickle and the closure compiler and the fact that the angular team is using typescript. Still, I feel like my criticism of dart has some truth to it at least.
I've taken aim at Google for the past week for what they've done to the openness of Android, AMP, and dart. Am I wrong? It's hard to argue that any of Google's platforms are as open as they were a few years ago. Some of my really unpopular opinions were posted in reponse to other poster calling me FUD or a shill, and can you blame me? It's one thing to say "I disagree and this is why" but pretty rude to just say "I don't believe you because you're obviously lying or getting paid to say that". To that I say well screw you I'll post what I want without being polite at all if you're going to be so rude. I'm replying nicely to you because you genuinely asked why I used a throwaway and said that you worked with dart at Google, way more than most would admit.
Having an unpopular opinion just gets you labelled as a shill or FUD and that's a lot of the reason I use throwaways. I've actually gotten death threats before for disagreeing with people on the internet. It's hard to say I would be better off getting death threats from people that can easily find my name, occupation, and address. Look at more...
Dart has an ongoing project (Dart Developer Compiler) which has a goal, among others, to produce readable, idiomatic EcmaScript 6. That is as close to your TypeScript fallback as it can get. (2)
Somebody also demonstrated Dart to LLVM compilation is possible. The language has a decent library for parsing the Dart sources, worst case, if you are that heavily invested in your product, you could also write something that does transpile your codebase. I did try to do it on small scale and specific examples, it is actually not _that_ hard to do, if my business relied on it, it would be certainly within reach.
(1) I'm not sure if you can call it lock-in as it is entirely open source, you can fork it, build it for yourself, change it if you have special needs. The same goes for perl, php, python, go, whatever language you prefer. Yeah, most people don't do it. Why? Because most people don't need it. If you become Facebook-size, it may look better to invest in the PHP toolchain and VM than in transpilers. YMMV.
(2) From the pure technical point of view, I wouldn't call it reassuring that the default fallback platform is JavaScript for so many people (even on the server-side). It is sure depressing that we are stuck with "1" == 1 and wrong ordering of "[1, 2, 10].sort()" for as long as we fall back to JS, and TypeScript does not improve on it.
For now Js fallback is the only realistic option for running code on the web. Even if we get native typescript or dart support tomorrow we will still need to put up with JavaScript for like 7-10 years. For this reason a readable JS fallback seems like a vital feature to me at least. It's depressing but reality for the majority of web projects.
Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's? That would make it a lot easier to write your own conversions.
One more point in Typescipt's favor though... It would be a lot easier to modify the JS VM in browsers to support native typescript than dart. In my mind it's a lot more likely to happen because of this(less work)
It's still got bugs, of course, but we have internal customers working on real projects using it on a daily basis.
I agree totally that picking a language is a huge commitment and you want to do that with an organization (company, standards committee, group of open source hackers, whatever) that you trust.
Google is a huge company and has done lots of good and bad things, so it's easy to find enough evidence to support assertions that we should or shouldn't be trusted based on whichever view you want to demonstrate.
One way I look at it is that instead of answering the absolute question "Can I trust Google to shepherd the language well?", consider the relative question "Can I trust it to shepherd the language as well or better than the maintainers of other languages I might choose?"
Assuming you've got some code to write, you have to pick some language, so the relative question is probably the pertinent one. I hope that we on the Dart team are a trustworthy pick, but different reasonable people have different comfort zones.
> Does dart have a pluggable compiler framework similar to Roslyn or Antlr AST's?
All of our stuff is open source[1], including all of our compilers and the libraries they are built on. Most of it isn't explicitly pluggable because plug-in APIs are hard and Dart in particular doesn't do dynamic loading well.
But it's all hackable, and much of it is reusable. In particular, the static analysis package[2] that we use in our IDEs also exposes a set of libraries for scanning, parsing, analyzing, etc. that you can use.
[1]: https://github.com/dart-lang/sdk [2]: https://github.com/dart-lang/sdk/tree/master/pkg/analyzer
In what ways do you consider it ahead of Typescript? Personally as someone who's particularly fond of static type systems (Haskell and the like), Typescript's type system seems way more advanced and powerful than Dart's (union and intersection types, in particular, and non-nullable types). Map types (introduced in Typescript 2.1) also seem pretty interesting.
Personally I don't get the hype around union types: at the point where you need to check which type you are working with, you may as well use a generic object (and maybe an assert if you are pedantic).
Intersection types may be a nice subtlety in an API, but I haven't encountered any need for it yet. Definitely not a game-changer.
I longed for non-nullable types, but as soon as Dart had the Elvis-operator (e.g. a?.b?.c evaluates null if any of them is null), it is easy to work with nulls. Also, there is a lot of talk about them (either as an annotation for the dart analyzer or as a language feature), so it may happen.
Mapped types are interesting indeed. In certain cases it really helps if you are operating with immutable objects, and mapping helps with that (although does not entirely solves it, because the underlying runtimes does allow changes to the object).
I dislike nulls though, I always wish people would just use a flag or error handling when objects are undefined, instead of "hey this object is the flag and sometimes it's not actually an object!"
You'd think language designers would learn after dealing with null pointers :)
For example, If you have a string-typed foo and a number-typed bar, "foo + bar" is still a valid statement in TS because they have to maintain backwards-compatibility with JS's unfortunate language design choices.
Self types (the "this" in the return type) is handy.
I can see us adding some of those to Dart eventually.
Non-nullable types are great, which I've said for a very long time[1]. We are finally working to try to add them into Dart[2]. It's early still, but it looks really promising so far. It kills me that I've been saying we should do them for Dart since before TypeScript even existed and still they beat us to the punch, but hopefully we can at least catch up.
The main difference between TypeScript and Dart's type systems (and by the latter I mean strong mode[3], not the original optional type system) is that Dart's type system is actually sound.
This means a Dart compiler using strong mode can safely rely on the types being correct when it comes to dead code elimination, optimization, etc. That is not the case with TypeScript and at this point will likely never be. There is too much extant TypeScript code and JS interop is too important for TypeScript to take the jump all the way to soundness. They gain a lot of ease of adoption from soundness, but they give up some stuff too.
In addition to the above, it means they'll have a hard time hanging new language features on top of static types because the types can be wrong. With Dart, we have the ability to eventually support features like extension methods, conversions, etc. and other things which all require the types to be present and correct.
[1]: http://journal.stuffwithstuff.com/2011/10/29/a-proposal-for-...
[2]: https://github.com/dart-lang/sdk/pull/28619
[3]: https://github.com/dart-archive/dev_compiler/blob/master/STR...
http://bgr.com/2016/12/13/android-chrome-os-merging-google/
So, even if they were presently 100% focused on merging the two OSes, Hiroshi's job would be to convince you they aren't as not to risk impacting the bottom line of their sales and their partnerships with OEMs that are continuing to print money for them.
[1]: https://en.wikipedia.org/wiki/Osborne_effect
But golang could be started in internal use with incredimental steps. fuchsia/andromeda in contrast have non-code barriers for entry like management approval and industry adoption. My guess is that it will pivot from a full-blown android replacement into something more focused.
Aside from Google+ (which was pushed directly by Larry and grudgingly integrated-with by the rest of the company), Google hasn't really had plans "as a company" since the mid-2000s. Big companies (other than Apple under Steve Jobs) don't actually work like that; once you've got a product-focused org chart and strong executives that push their own focus areas, you will necessarily get product-focused initiative that respond to resource availability & market opportunity. The executives are not doing their jobs otherwise.
I googled for "google magenta", and all the top hits are actually about an entirely separate (I assume?) project about AI music: https://magenta.tensorflow.org/welcome-to-magenta. So they didn't think very hard about the name for a start.
I'm also skeptical that a big new effort like this would be done entirely in the open. The Chrome team has something of a history of doing that and then throwing stuff away (e.g. Chromium mods and hardware configuration for a Chrome tablet that never got off the ground).
The Android team, on the other hand, seems to prefer developing stuff in private before open sourcing it. And their stuff seems to have more traction (or maybe we just don't see all the aborted efforts because they're private).
I feel like the Chrome team really believes in open source, and developing in the open, whereas the rest of the company (and especially Android) doesn't care as much and prefers being secretive. But as Sundar Pichai used to run Chrome, maybe he's changing things up a bit?
The status quo right now among android hardware vendors is to violate the GPL, and they have faced few if any repercussions for doing so. I wonder if Fuscia is sort of viewed as the way forward to addressing that.
Anyone care to speculate why there isn't a community version of chromium os? I'd donate to it for sure. It sounds like getting android apps working on it would be pretty easy: https://groups.google.com/a/chromium.org/forum/?hl=en#!topic...
[1]: (https://www.neverware.com/freedownload/)
No it's not the status quo. The major OEM's do release their code. Yes, there are some Chinese OEM violators, but that's typical of China.
http://yarchive.net/comp/linux/gpl_modules.html
How's that going to work? iOS, specifically? Is Dart a supported language?
https://flutter.io/faq/#how-does-flutter-run-my-code-on-ios
and
https://flutter.io/faq/#can-i-interop-with-my-mobile-platfor...
"The engine’s C/C++ code is compiled with LLVM, and any Dart code is AOT-compiled into native code. The app runs using the native instruction set (no interpreter is involved)."
Thanks!
Fuchsia repository: https://fuchsia.googlesource.com/?format=HTML
A bit weird to use the past tense here since it's not reached 1.0 yet. You can try it out today (tech preview) to create apps in Dart that run on Android and iOS:
https://flutter.io/
(Googler, not on the Flutter team itself, but working on related developer tools.)
https://fuchsia.googlesource.com/
Won't the Dart's single thread nature be bad to take advantage of Murli core processors? Or they are embracing web workers?
https://lucamezzalira.com/2013/06/11/isolates-how-to-work-wi...
This is worrying for Apple. I can see the following playing out
- Apple continues releasing machines like the TB MBP, much to exasperated developer dismay.
- Other x86 laptop industrial design and build quality continue to improve.
- Fuchsia/Andromeda itself becomes a compelling development environment
- Developers begin switching away from Mac OS to Fuchsia, Linux and Windows
- Google delivers on the promise of a WORA runtime and the biggest objective reason not to abandon Mac OS, i.e. writing apps for iOS, disappears.
- Apps start to look the same on iOS and Android. iOS becomes less compelling.
- iOS devices sales begin to hurt.
Granted that the App Store submission requires Mac OS (Application Loader) and the license agreement requires you only use Apple software to submit apps to the App Store and not write your own, but it seems flimsy to rely on that.
I've been running Android since the Nexus One so I'm no newbie to the platform, but the ease with which iOS manages to get all UI interactions at ~unnoticable FPS and outstanding battery life is staggering when you're used to Android. It feels like some really fundamental choices were made badly on the platform that make it incredibly inconsistent and unreliable. A fresh start would be fantastic.
I was very happy with the 5, even with the intermittent lags, especially considering it's price at release. I suppose I'm not a very heavy phone user, and I never play mobile games, but I've been very happy with the 6P on Android 6.0-7.1. Battery life could definitely be better, and it does get fairly warm at times, but overall it's been a very good experience for me considering the Snapdragon 810 it's using is generally poorly regarded.
But bad I/O is the killer (e.g. fun things like triggering 2 image load requests at once which then take 2500ms vs. doing them sequentally which takes 400ms on some Samsungs. This happens also if several processes collide). Apple side-steps that by throwing money at the problem (good controllers, expensive flash) which probably won't happen in budget Android market.
I don't read about Android and iOS [hardware] nearly as much as I'd like to, and HN doesn't seem to generally cover the subject too well. What are some sources you could recommend I read to stay updated?
HTC One M9: 2840mAh
iPhone 6: 1810mAh
iPhone 6 Plus: 2915mAh
In streaming video playback, the iPhone beats out all of the other devices.
Galaxy S6: 6.3 hours
LG G4: 6 hours
HTC One M9: 5.5 hours
iPhone 6: 8.8 hours
iPhone 6 Plus: 11.1 hours
http://www.trustedreviews.com/opinions/which-phone-has-the-b...
Unfortunately, the hard part of an operating system isn't in a cool API and a rendering demo. It's in integrating the fickle whims of myriad hardware devices with amazingly high expectations of reliability and performance consistency under diverse workloads. People don't like dropped frames when they plug in USB :) Writing device drivers for demanding hardware is much harder than saving registers and switching process context. The Linux kernel has an incredible agglomeration of years of effort and experience behind it - and the social ability to scale to support diverse contributors with different agendas.
Microsoft, with its dominant position on the desktop, famously changed the 'preferred' APIs for UI development on a regular cadence. Only Microsoft applications kept up and looked up to date. Now Google has such a commanding share of the phone market - Android is over 80% and growing http://www.idc.com/promo/smartphone-market-share/os - they have a huge temptation to follow suit. Each time that Microsoft introduced a new technology (e.g. https://en.wikipedia.org/wiki/Windows_Presentation_Foundatio... WPF) they had to skirt a fine line between making it simple and making sure that it would be hard for competitors to produce emulation layers for. Otherwise, you could run those apps on your Mac :)
There are many things to improve (and simplify) in the Android APIs. It would be delightful to add first class support for C++ and Python, etc. A project this large will be a monster to ship so hopefully we'll soon (a few years) see the main bits integrated into more mainstream platforms like Android/Linux - hopefully without too much ecosystem churn
It's too bad, given how much nicer their app approval process, etc is than Apple's that the Android dev experience has been so much worse all these years.
And on mobile devices, many hardware component vendors provide custom drivers (with binary blobs) anyways. It will not be hard to convince them to support Fuchsia for new hardware releases. If they loose access to Android otherwise...
[1] https://en.wikipedia.org/wiki/Rump_kernel
"Linux is a free set of buggy device drivers." https://news.ycombinator.com/item?id=8470638 .
Just observe how systemd is overruling and countermanding Linux behavior any chance it gets.
Doing new WPF application development for the last three years for the biotech industry.
It is also the official API for classical desktop application and shares a lot with UWP.
As the other reply probably indicated, it's still not apparent to .net developers. MS really dropped the ball with providing a clear path for desktop development.
So much this; Linux Plumbers conference years ago was bitching about how every gorram vendor wanted to be a special snowflake, so even though the architecture was ARM, you basically had to port the kernel all over again to every new phone. I haven't kept up with it, but I can't imagine it's gotten better. The problems they're listing as reasons to move to a new kernel aren't caused by Linux and they won't go away until you slap the vendors and slap them hard for the bullshit they pull, both on developers and users.
As for kernel ABI, this has been rehashed to death: just release your fucking driver as open source code, and it will be integrated and updated in mainline forever: http://www.kroah.com/log/linux/free_drivers.html
But... "average garbage-collected language using a virtual machine" doesn't describe any of C/C++, Dart, Go, Java, Python, or Rust. Nor Javascript.
I get greater than 60 fps with my existing Vive three.js WebVR-ish electron/chromium linux stack. Even on an old laptop with integrated graphics (for very simple scenes). Recent chromium claims 90 fps WebVR, and I've no reason to doubt it. So 60 fps "up to 120fps" seems completely plausible, even on mobile.
I'm curious; what would be an example of something you would describe as an "average garbage collected language using a virtual machine"? Java would certainly be the first language I'd think of for that description.
Ruby 1.8, Lua, or CPython.
What do you think makes Ruby and Lua more "average" than Java?
I italicized "average", and wouldn't include Java, because most languages are very small efforts, and thus are different than the top few. A person-century or person-kiloyear of optimization effort has an impact. Observations that "implementations of strategy X generally have characteristic Q" can be true, but there's a hidden context there of "severely resource-limited implementations of X".
But two caveats:
Sometimes you are trapped. In CPython and PyPy (but not in Jython or IronPython), parallelism remains defined by the GIL.
Language implementation tooling sucks less than it used to. Now even toy languages have JIT and rich compilation infrastructure.
Aside: In the late 80's, before ARPA was hit by Bush I, project managers had a great deal of autonomy. There was discussion of "what more neat things could we do to accelerate progress?" One observation was that JIT expertise was highly localized, and we could either wait many years for it to slowly spread, or pay someone to stand on people's desks and catalyze its being written up. But that kind of micro-grant didn't yet exist, and time ran out on creating it. Society chose option 1, but a human generation has now passed, and we finally have accessible JIT infrastructure. So, yay?
(In fairness, note autonomy and "old boy network"ness was a less happy thing for potential researchers at other than the few main research institutions. Some change was needed, it's just not clear it required societally critical tech to remain largely unfunded for decades. We don't even have a (language) wiki. Though even national science education improvement efforts have failed (but oh so close) to attempt one.)
Slightly in those people's defense, it is true that while GC relieves you of the need to track lifetimes and worry about using dead pointers, it doesn't relieve you of the need to consider performance as one of many factors that go into your code. So while I think the performance issues of GC'd languages are very frequently overstated, it definitely is true that a UI framework written in a GC'd language by someone who isn't giving any thought to performance implications of allocation can very quickly exceed its targets for 60 fps, let alone 120 fps, even on very simple GUI screens. But that's only maybe 10% the fault of garbage collection... 90% is that someone is writing a GUI framework without realizing they have to pay a lot of attention to every aspect of performance because GUI frameworks are very fundamental and their every pathological behavior will not only be discovered, but be encountered quickly by all but the most casual programmers. It doesn't take long before someone is using your text widgets to assemble a multi-dimensional spreadsheet with one text widget per spreadsheet node or something, just as one example.
In a manually managed language, the performance of the application's memory management code is limited by the skill of the application developer. In a managed language, it's limited by the skill of the GC developer.
GCs have gotten a lot better in the past twenty years, in large part because they have the luxury of amortizing their work across a million applications. That makes it financially viable to throw a ton of person-years at your GC. That's not the case for the malloc()s and free()s in a single application.
So just through economies of scale, we should expect to see, and indeed have seen, managed languages catch up the the memory performance of the average manually managed app.
Google has already done 90% of the necessary work by adding Android apps to ChromeOS. Two and a half years ago it created "App Runtime for Chrome" which demonstrated that Android apps could run on Windows and Mac in a limited, buggy way [1]. If Google had put meaningful effort into developing such a strategy we would by now have a relatively simple way to develop software which runs on 99% of laptops and 85% of smartphones and tablets. Developers would now be targeting 'Android first' instead of 'web app first then iOS then maybe Android'.
Sundar, if you're reading this - do it!
[1] https://arstechnica.com/gadgets/2014/09/hack-runs-android-ap...
So, divide up by services, and download only the services needed by installed apps with the first app that needs them. Adds basically nothing to the browser install.
* Java itself was slow for a long time
* The Browser would hang while loading an Applet
The first is no longer an issue. They can just use a modern just in time compiler and it wont run slower than Java on Android. Chrome already has one to deal with JavaScript powered Web 2.0 applications.
The second was as far as I can tell an API issue. Applets would block everything by default until they were loaded. A really bad idea in a single threaded environment when you had to send several MB over low bandwidth and the JVM itself took long to start. Just making the load async with a completion callback could have solved this issue and I remember a few Applets that actually used an async download to reduce the hang.
If Chrome manages to provide better versions of most applications on most platforms, it may win. Otherwise, people who use those applications will hate it with the heat of a thousand Suns, and it will go the way of the Java Applet.
Uh, Java AWT was the native toolkit. Swing was the non native UI with the ugly METAL default Look and Feel. There are some nice custom Look and Feel implementations that don't try to emulate a platform, I think Matlab uses one for its UI.
For example, look at Windows 10 and the mishmash of controls (are they flat? or do they have a bevel?) available from the control panel, settings app, old COM dialogs, MMC etc. etc.
What choice do we have? Everyone's doing their own walled garden, so it's not like I can go and find an alternative SaaS / operating system with same features but better UI...
One of the last straws for me was the built in mail app that had this awful background image. Too many flashbacks of shitty access apps.
One thing that strikes me as weird is that almost any widget set that does it's own drawing or even just it's own automatic layout and tries to match look and feel of native UI invariably does not match even the basic look because various UI components use wrong size, are placed slightly differently and so on. For example everything I've ever seen that tried to match how windows 3.1 Ctrl3D looked draws window decorations one pixel narrower than the original, which is plainly visible and ugly, similarly things that attempt "looking like Motif" usually use different thickness for various lines and borders and also often mix-up meaning of focus rectangle (which should move by tab) and bevel around default button (which should stay in the same place irrespective of which control has focus). I see no technical reason why either of these things cannot be done right, is there some legal reason for introducing such small differences, that are small, but big enough to be annoying?
A quick check of wikipedia backs my memory, the Java classes were just a thin wrapper around the native components. AWT was mostly bad because it was limited, it does not even have a Table.
> even the basic look because various UI components use wrong size, are placed slightly differently and so on.
The windows API does not come with a layout manager AFAIK. I vagualy remember setting every bit of relevant size/position data by hand last time I used it directly. Same could be done with AWT, so this is mostly likely caused by programmer lazyness.
In any case, Google doesn't need to be as strict as Sun was. It is free to implement "write 90% of your code once and 10% customised for each platform".
Now, consider the orders of magnitude improvement in computing power over the years, and notice that webapps aren't really doing anything more complicated than old applets did...
Actually they suffer from most of the same problems, only computers have gotten faster (masking performance issues) and our expectations have lowered. How many of these web apps obey the native OS themeing for instance?
If an issue no longer affects anyone in any way, is it still an "issue"? Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
I said it was masked, not gone. It still causes a lot of issues for people on resource constrained machines.
> Odds are that all the code you've ever written would have been considered criminally bloated at some era of computing history, but it hardly matters now.
For much of computing history where were making clear gains with newer hardware. Up to the 90's software was getting more bloated but it was doing more. Most apps today really aren't doing much/any more than we were doing in the 90's but require vastly more powerful machines.
Although I think there's more going on in regards to 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native. And while it's certainly possible to make a web app just as shitty, if you rely on 'stock' html elements, a lot of the subtle native behavior carries over.
Just a few weeks ago, for example, I built a web-app for mobile devices. It felt off immediately because the scrolling didn't feel right. All I had to do was turn on the momentum scrolling (with a line of ios-specific css), and the scrolling suddenly felt native. Had I used a hypothetical Java applet equivalent, I might've had to either go for a non-native-feeling scroll or build it myself.
While I of course can't prove any of this, I think what people care about is that things feel native, not the 'skin' used to display it.
I think people finally called the bluff that users have any expectations. And even if they had, what they don't have is choice. The current market is that everyone is building a walled garden around their selling proposition, so if a company decides to make a web app instead of a native one, then that's all you have. Nobody will make a better one and risk getting sued. If a service doesn't want third party applications, then they won't happen.
As you note in your comment, if one sticks with default, "stock" elements in their web app, things look and behave OK on a given platform. But nobody does that, for some reason everyone has to screw this up with tons of CSS and JavaScript that make the whole thing maybe prettier, but also noticeably slower and without all the native idiosyncrasies.
It's a really interesting question actually because it's so hard to compare the two. On any objective measure, today's web apps are much better than applets in terms of responsiveness, etc. But then again, an applet could run on machines with 16MB of RAM total. I think you'd be hard pressed to get plain html page in a modern browser to run on a machine like that. Either way, in both cases we had a much better solution in native apps.
> 2. I was never bothered so much by the UI of a java applet looking different. What bothered me was that even very fundamental stuff like input fields and scrolling felt both alien and shittier than native.
Modern web apps can score better here, but quite often they don't. The more complex the become the less native they get, scrolling, text input, etc are generally OK (unless your an arshole that overrides scroll behaviour), but html still doesn't have an equivalent for native table views and the goodies (navigation, resizing, performance) that comes with them.
For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
Oh yeah, complex UI stuff is definitely a good reason to avoid web apps.
But for many, probably even most apps it's precisely scrolling, text input, and other 'basic' stuff that matters, and in those cases a web app's 'default' will be more native.
> For me the skinning does matter though, I have a beautiful, consistent desktop that browsers (not even electron apps) shit all over. When something doesn't look quite right from the second you open it it magnifies all the other differences.
I agree on a personal level, but I suspect we're outliers. Can't substantiate that at the moment though, so I might be wrong.
Modern web apps are non standard but pretty.
Forget the theme - how many of these web apps obey the native OS GUI features? TAB-navigation, arrow navigation (in e.g. lists), accelerator shortcuts, editing shortcuts, not to mention a lot of visual idiosyncrasies that together make the interface feel "right"? Ironically, if you use default HTML controls, most of the things will be OK on a decent browser. But no, designers and developers absolutely have to make it worse by applying tons of CSS and JavaScript.
This applies to web apps pretending to be mobile apps, too. You can quickly tell one from another; the web app is the one with mediocre UI that behaves "wrong" in more or less subtle ways.
It seems to me that the 'new' Microsoft (since Satya Nadella took leadership) is changing their closed/proprietary stance on many topics. Not everything of course, they still have to sell stuff, but as far as "genuine cross-platform" is concerned, they are certainly giving developers all the tools to both make and target all major operating system.
Giving anyone not on Windows a second rate experience? Core as the name says provides only a subset of the Windows .Net framework and most .Net code in the wild is written with the implicit assumption that it runs on the Windows framework.
> VS code universal electron app
Instead of making their main IDE a proof of concept for .Net Core they wrote a Web3.50/NodeJS IDE. I am very sensitive to high latency IDEs so that is something I wont ever touch.
> the whole Office 365 paradigm
Trying to keep up with the competition, Google Docs ring a bell?
> since Satya Nadella took leadership
Nadella 2014. Linux on Azure 2012. Office 365 2011. Mono based on Microsoft’s promise not to sue 2004. Open sourcing parts of .Net is really the only thing you can assign to Nadella, everything else was still done by the good old triple E leadership.
Android and Material Design will not be "write once, mediocre everywhere". It may become "write once, great on Android (majority of phones) and ChromeOS, mediocre elsewhere." But writing for Android does not exclude creating native versions for other platforms. Using Java did exclude creating native versions because that was the reason to use Java, to not have to write native versions.
I remember issue no.3 :
United States Court of Appeals,Ninth Circuit.
SUN MICROSYSTEMS, INC., a Delaware Corporation, Plaintiff-Appellee, v. MICROSOFT CORPORATION, a Washington corporation, Defendant-Appellant.
No. 99-15046.
Decided: August 23, 1999
http://caselaw.findlaw.com/us-9th-circuit/1260682.html
Usually culprits are things like downloading multiple data files in a single threaded block, or insanely deep object graphs with thousands of memory fetches per real operation.
That's not really anything to do with the technique (code in browsers) or the runtime (JVM) or even the programming language (Java) -- and everything to do with poor development.
It's not fast on a $200 mobile phone though. It's still pathetically slow.
Applets have become slow to start many years latter when bloated "enterprise" applications have been produced in abusive ways.
The security of applets has started to deteriorate a bit slightly before the death of Sun. It has become a security hell only since it is in the hands of Oracle.
I did my fair share of applets back in the day, starting with the very first public versions and have very vivid memories of the loading screen :)
Although yeah, even with our newfangled fibre connections applets are still pretty bloated.
At least that was the case for me...
JavaScript at the time was mainly used for snow flakes on the web page or annoying mouse trails on the web page, as I recall. Oh, and maybe rollovers. I remember Microsoft pushing DHTML and seeing IE4 as a leap forward compared to IE3 but I do recall Java being slow. And slow.
One problem I see with Google's ecosystem is that they've betted on the wrong horse - Java is a pain in the ass and Android's Java foundations are its second largest weakness. (The first one being the Google-Vendor relationship that makes all but the very latest Android devices unpatched and 100% insecure.)
This is basically how Dalvik/Zygote worked on actual Android. From what I know, Chrome too uses always-running background processes even if you don't have a browser window open (for mainentance work and to improve startup times).
So I'd assume the project would do exactly that.
By that logic nobody should even create native Android apps today. You're saying that if Android apps could run on even more platforms it would somehow stop being worth it to create them because iOS is excluded? Makes absolutely zero sense.
A fresh OS for devices that had chrome as an app and its android hornet behind it would make a bunch more sense.
Pushing the jvm kart is similar to something like bowser vs Yoshi
I doubt that most developers would do any effort to have their apps "responsive".
Most popular apps are designed for both tablet and phone. The ones that haven't specifically been designed for tablet are usually basic things like Guitar Tuner or Flashlight which don't suffer much from having a phone layout on a tablet.
Sure, you will still sometimes encounter a crappy app which has a horrible user experience on your device - similar to web pages and webapps which assume you have a 24-inch display - but not often enough for users to avoid the platform.
[1] http://www.phonearena.com/news/400000-apps-in-the-App-Store-...
I still think touch screens is the future - also on desktops (there either in tablet form or "drafting table" form).
I think editors more like acme and less like vim might rise up. Along with new input types like the power bar and surface wheel.
Acme, and anything like it, would be completely horrendous on a touch interface. I use it regularly (although I find that I prefer Sam).
Edit: Then again, I have touchscreeens on many of my laptops. I don't find them useful. With the exception of drawing art, I wouldn't miss them if they disappeared.
Unlike emacs or vim, acme leverages the mouse/gui for powerful editing - and I believe (multi)touch screens have the potential to be better guis than than screen+mouse. For one thing mice generally utilise at most three fingers and one hand - and IMNHO while eg blender/photoshop combine mouse and keyboard - the combination is awkward and not very intuitive.
I think (but am far from certain) that acme is a more promising approach.
This would have been the way to build Linux into the next great desktop platform. I dont think people mind a 1GB Chrome runtime if it opens up a billion apps for them.
I think apps can be handled well by both browser and mobile phones. Considering that ART runtime also JIT compiles the java code to native, performance should also not be a worry.
I've never tried it or seen anyone do it though.
'Running' can be pretty good, even when it's not a native app - there are plenty of successful web apps, including a few written by Google.
The other issue I have is that I don't see Android apps as efficient way of getting my work done, applications that don't need to worry about the mobile form factor will most of the time offer a superior user experience.
You already have a 99% cross platform way to ship an app, you can create a web app.
The other issue I have is that I don't see Android apps as efficient way of getting my work done, applications that don't need to worry about the mobile form factor will most of the time offer a superior user experience.
You already have a 99% cross platform way to ship an app, you can create a web app.
We already do. It's called a webpage.
I currently "add to home screen" for most things. I edit my images online, and develop code using cloud9 ide, etc. There are few things I need apps/programs for right now, and that's improving day by day.
iPhone is dropping heavily in world wide market share, but they still have a lot of the wealthy users. There is a non-zero chance they get niched out of prominence by Android (aka every other manufacturer in the world), at which point network effects start encouraging Android-first or Android-only development. There might be a point where Apple needs to double down on the web, and/or maybe kill off apps, like they did flash, to still have the latest "apps".
That's just my anecdotal view, but I have never tried a web based app (electron native app thing or webapp in the browser) that is as great an experience (UX and UI) as the best of the best native apps on Mac and iPhone, and I'm not sure it's possible to push web tech that far without reimplementing everything in the web stack and making it as close to native that we're better off just writing native apps.
EDIT: spelling.
I would say I have never tried a web based app better than average native apps. (Except for GMail, because I don't like the sync feature of mail clients).
No HTML5 UI/UX comes close to what is possible to achieve with native APIs in any platform.
For old dogs like myself, it always seems that younger web dev generations are rediscovering patterns and features we were already doing in native applications during the 90's.
Also solutions like service workers look like some sort of kluge to sort out the problem to do offline applications in browsers.
WebOS, ChromeOS (barely used outside US) and FirefoxOS are all proofs that the experience is substandard.
The way it works is to funnel all the profits into a few huge conglomerates that benefit from exclusive access to all personal data and train users to never depend on anything that isn't a core product of one of these conglomerates.
Using their 80% margins they can afford to at least give us some time before scrapping software that doesn't look it's ever going to reach 4bn consumers.
The result is stability. Until they all get toppled by the next technology revolution. Years later, regulators will crack down hard on some of the side issues of their former dominance and once again miss the currently relevant issues :)
I only see this as a good thing if this ensures an easier upgrade path than in Android; and if vendor ROMs can easily be replaced by a stock OS (like on Windows).
So?
Google doesn't have to support all hardware, they can pick to support only the hardware they want. That's what they already do with ChromeOS. Installing ChromiumOS on unsupported hardware can have its issues. The reverse is true too, installing not-ChromeOS Linux or another OS on Chromebook does not always work well, although it's fine on some specific models.
Android is like that too, and in a much worse way than for Chromebooks. We're not talking about stellar linux kernel support for all the custom ARM SOC that are out there. All manufacturers write their own closed source hardware support for android and this is how android ends up having issues with updating, since whenever Google updates the linux kernel it breaks the ABI and all the support manufacturers wrote for the previous version, and manufacturers do not want to spend so much time on needless busywork such as keeping up with kernel API churn that exists just to satisfy the dev team sense of perfection.
One of the great things about Android is that Linux is GPL, so at least the kernel code is open.
Neither Android nor Windows nor Chrome OS nor your favorite Linux distro have ever been able to truly compete with the NeXT legacy as it lives on in Apple.
Google is smart enough as a whole to see this, and so it's not surprising that they're attempting to shore up their platform's competence in this particular area. What IS surprising is that it has taken them this long.
Perhaps what's truly surprising is just how much mileage Apple has gotten out of NeXT. It's astounding, and I know Apple realizes this, but I question whether or not they know how to take the next step, whatever that may be. And if Google manages to finally catch up...
Er... what?
Apple has been worried, and actually threatened, by Google every day since 2008, when the first version of Android came out.
Without Android, Apple would probably have a 90% monopoly on mobile phones today. Saying they might be "worried" is beyond an understatement.
They are absolutely furious at Google, as Jobs was until he passed away.
I find this a funny statement. Apple has not seen runaway success in terms of market share, not on desktop platforms (where the top OSes are various versions of Windows), not on mobile platforms (where it is a distant second to Android in the worldwide market), not on server or supercomputer platforms (where it's effectively nonexistent).
Nor is it influential in terms of operating system paradigms. The only thing I can see people citing as a Darwin innovation is libdispatch. Solaris, for example, introduced ZFS and DTrace, as well as adopting containers well before most other OSes did (although FreeBSD is I think the first OS to create the concept with BSD jails)--note that Darwin still lacks an analogue.
market share won't feed nobody. that's all apple needs to care about. just look at their market cap and p/e ratio.
1. Callbacks are horrendous. I hate inner classes, they're ugly and unwieldy. I'd honestly rather something like AWT's (Yes, that 90s tech) callbacks over inner classes.
Just have a main function with a large switch. It's much easier to reason that then the current mess-up of trying to figure out your app's lifecycle.
2. Inter-thread communication is horrendous. Android is Java based, so can I pass classes?
No.
Only Strings.
And even that is horrendously ugly.
3. It's a Frankenstein model. It's a Desktop OS like process/file model, but not everything is a file. Now they suggest opening using the new file-picker.
But in many ways files are easier to use.
4. They add new libraries (Material Design, for example) which no one will ever use, because everyone needs to use appcompat. And even in five years, when Lollipop will be like Android 2.2 is now, everyone will still have to use appcompat to get Android Z libraries on Android O, or something. And by the way, now most apps rely on appcompat-7 which relies on appcompat-4.
5. Many classes are broken - Take TextView. You can style it with HTML, but only a small subset (so you can't use it as a WebView). So it's not meant as a "web browser" replacement. But it can parse broken HTML. Wow, so developed.
But you can't style a link color, or change underline color.
------------
But on the other hand, I'd find it horribly annoying (and I think that many others would feel the same way) having to rewrite everything from scratch into Dart or whatever.