On Thursday, 7 January 2016 at 04:43:28 UTC, Joakim wrote:
Eh, those removals are all well though-out and sensible, D has similar opinions. I was impressed that most of the stuff they say they _won't_ remove is related to C-style syntax:
Well, I am not complaining, but they seem to focus on keeping complexity out of the Swift syntax and avoid infrequently used features in the context of app programming (rather than system programming).
Most programmers have a C-style parser wired into their heads: you cannot replace it.
You get used to a different syntax rather fast if it is reasonably close to something familiar. I was sceptical to Python, but picked it up quickly.
headway in application programming, certainly not outside their enterprise niches, ie consumers don't use Java/C# apps, and are now both AoT-compiled on mobile.
Java demands lots of memory, but Java is suitable for consumer applications on new machines. The problem with consumer devices is that the majority of users are on the low end.
from C over the years, D could do even better with a lighter runtime. D hasn't really focused on that yet, but I think Walter wants to one day.
That would be a nice change of direction. I think the core language shouldn't require a runtime at all. But... probably too late for D.
Not sure how ABI stability/portability hurts that, but is Swift going after C or not? You seem to say they are, then they aren't.
No, they are not going after C, but making it less necessary to drop down to C from Swift. If they have a fixed ABI then you can FFI Swift functions?
Perhaps you haven't heard, but the original Facebook mobile app was simply their HTML5 site bundled on mobile, then they switched to native years ago for efficiency:
I don't know much about it, but I've heard that Facebook have serious internal software development process problems resulting in bloat across the board. Just a rumour. I thought that implied to their mobile apps too? (I don't use it.)
They may still use and release legacy HTML5 frameworks, ;) as that's where they started, but almost half of their users now only use the native mobile apps, and that mobile-only user share keeps growing:
Ok, well, Facebook and other juggernauts can afford to develop their apps on all kinds of platforms (from scratch even).
In any case, your point is still unclear: why would WebAsm not have the same browser support?
We'll see, but less motivation (demand) is my guess. Webasm is unreadable, runs as machine language and you don't have type info?
They cannot fix the real problem, the baroque architectural pasta of HTMl/CSS/DOM, but those moves make those two components much more efficient, which certainly helps.
I don't really think the DOM is baroque. It is like a scene graph. The only really bad thing about it is that you set css values as strings. It could use a redesign, but it is more flexible than regular GUI libraries (which are rather ugly and tedious).
over the web's spot. I've suggested a re-architecting of the web approach before, to focus on efficiency and extreme simplicity of graphical layout in the client:
There are 3 approaches for "re-architecting" gui-style components in the web DOM:
1. The approach taken by React which is to have a virtual DOM (a pure javascript DOM).
2. The approach taken by Angular which is to have special HTML-style attributes for templating functionality (like for-loops) and use observers (track change events).
3. The approach taken by Web Components using shadow DOM (invisible sub-DOM under custom elements/nodes).
think that entire client-server model is outdated. I suspect what's coming is more of a p2p approach, where smartphones simply pass data to each other
Smartphones support p2p? That's new to me. I thought they were deliberately limited to servers.
then construct UIs customized for the user out of the data they want to see. That's my guess, but whatever it is, it will kill the web.
No, it will not kill the web. Nothing can kill the web... you want it, but it ain't happenin'.
That approach is what modern javascript frameworks is supposed to support! The web is further down that path than GUI libs. Angular2 is basically a client side templating system, and so is web components...
