Aleman360

Official support, documentation, perf (presumably), debugging, and tooling support would be my main concerns.

Technically, XAML makes heavy use of C#'s events and properties (which C++\Cx adds to C++), which don't exist in plain old JavaScript. Also, both C# and C++\Cx support "await" natively, which is extremely nice for WinRT's async-heavy API's.

I'd still choose to use C++ or C# for cross-platform code if starting from scratch.

However, I've never had to work on cross-platform apps, and have never been subjected to JavaScript professionally, so my opinion is probably worthless.

Seems to be an official client: http://m.windowscentral.com/twitter-windows-10-pcs-and-table...

Do yourself a favor and use C# or even C++\Cx instead. They're both a much better fit for XAML.

Full disclosure: I work at Microsoft on XAML UI in C++. It's nice. Opinions are my own.

They just released a UWP client for Windows 10.

> If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.

You just described Windows 10's UWP.

The US government has three independent branches for a reason.

What about disabling the bricking mechanism that would have allowed the FBI to brute-force the PIN?

Don't assume your health will be good forever.

Still a thing, even in Windows 10. See the "Segoe MDL2 Assets" font.

I have to sympathize with Obama here. Although I am very much pro-encryption, the arguments here are not convincing at all; you'll have a hard time convincing people by dismissing their views or implying that they don't know what they're taking about or instilling fear that all the tech companies will leave the US.

The way you talk to people is more important than the points you're making.

How I did it for a Microsoft interview: cram for a weekend with a good algorithms text book. I do UI development where 99% of the work is figuring out the UI framework but the study session definitely got me into the right mindset for interviews.

This is exactly why sandboxed apps (e.g., iOS/UWP/etc.) are a good thing.

"Microsoft OS has monopoly power in the PC market."

Is there a legal difference between a "PC" and a tablet or phone? They all seem like general purpose computers to me. From that perspective, MS definitely doesn't have a monopoly.

Why would you want your grocery store on social media? I don't understand the world anymore.

As a C++/XAML mobile app dev, I'm baffled by how a common UI like this (lots of lists?) requires such a deep dive.

It would be great if Swift could target .Net Core.

The verbosity makes things easier to understand for beginners.

Developing markets where the only computer you have is a phone.

That's exactly what the FDA does for medical devices. They don't test devices, they audit your facilities, processes, and product documentation.

Both. It's extraordinarily complex. The data entry is highly structured. All the electronic record software I've seen has probably ~100 pages worth of forms, a big subset of which usually need to be filled out for each patient visit.

It's not being "disrupted" because it's extremely capital intensive to enter this market. The requirements seem intractable:

- Structured data with very high level of granularity.

- Patients often don't fit the mold exactly. It's hard to classify something that is going on with a patient; there are 68,000 ICD-10 codes.

- Data needs to be interoperable with existing and competing systems.

- Every hospital has their processes and documentation practices. As a result, most electronic record software is highly customizable, and a company representative is usually on call or on site to continuously customize it.

- Software needs extreme backwards compatibility. You need to be able to read records that are tens of years old.

- Need to be able to print everything.

- Need to meet regulatory requirements and security audits. Regulatory requirements vary by state and country.

- Healthcare institutions are inherently conservative with their technology, and for likely good reason. Plus they don't upgrade equipment very often. If they just spent $1 billion upgrading their entire IT infrastructure, they're not going to consider your startup's solutions for awhile.

- Patients don't like it when their provider is focused on a computer or taking notes instead of on them.

- Different UI for each provider (e.g., primary care physician vs. pharmacist vs. radiologist)

- Need to communicate with a wide variety of medical hardware that doesn't have good standard protocols, and much of which is very old.

And on and on...

There is still a requirement for highly structured data entry that is unavoidable. Even if you reduced the other documentation requirements, the "computerized physician order entry" systems (healthcare lingo) still require quite a lot of provider time. You need to be very explicit when entering things like chemotherapy regimens.

Girlfriend is an oncology PA. Writing notes are the absolute most dreaded part of her job. She has to spend about 8 hours every weekend catching up on them. The switch to electronic records vastly increased the amount of time to complete notes.

Scribes are a good solution. Her brother-in-law is an ED physician and doesn't really have to worry about notes because he has good scribes.

And UWP, which is the primary UI framework now.

> After all in every native UI framework you have instructions to draw the widget IN your code -- not as some external additional technology. A widget's C/C++/Obj-C/Swift/Java/C# etc code encapsulates everything about creating it and showing it.

With the notable exception of Windows. XAML strictly enforces code and markup separation. It makes the View layer more toolable and easier to edit by designers who usually don't program.

The biggest downside to me is games. I returned an iPad Pro for the 12" MacBook. Just as portable and Civ V and Steam/Xbox streaming is a much better use of my limited gaming time than anything on the app store.

Yea, the multi-tasking UI is especially half baked. You should be able to have two instances of the same app side-by-side (at least Safari).

You can use C# or JavaScript if you don't like C++.

That's just bad formatting on the website.

It's verbose but also extremely flexible and toolable. You're discounting how easy it is to add arbitrary animations between these two states, or how you can visualize them in Visual Studio without having to rebuild your app.

You can also create your own triggers so that you can be "responsive" to any arbitrary event.

> bmp Windows::WinForms::XAML::Imaging::Bitmap = ^new Windows::WinForms::XAML::Imaging::Bitmap(filestream)

That must be an outdated example. That namespace doesn't even exist. You can add images like this:

<Image Source="hello.jpg"/>