331–340 of 459 posts
Earlier quoted context omitted.
This is the confusing part for me, yes. Javascript is fine and well, but C# seems the better choice in general here.
What makes it the better choice in this situation? C# can't run in browsers whereas Office 365 can.
Earlier quoted context omitted.
Does this mean that VBA will finally die? Please tell me that VBA will finally die.
As much as I can imagine MS would love to kill VBA it would be a major loss of business if they did. Oil and Gas lives in the stuff and would probably even sue MS if VBA died. That said could it be getting a much needed fixup... probably. I suspect the same is true of COM plugins.
Is it money, fear or gatekeeping that keeps these VBA programs untouchable?
Earlier quoted context omitted.
"No they are not electron apps. They are compiled to native code. It's now finally one toolchain(#webpack) It's one codebase and it compiles to: Web Android IOS MacOS UWP WIN32 (only one that uses electron) 7:52 AM · Jun 13, 2018" https://mobile.twitter.com/TheLarkInn/status/100676113439583...
comment seems to be saying -- in modern windows (UWP) it'll be using native code, but microsoft is taking the easy path on win32. i guess some people are surprised that despite years of telling people that win32 is going away microsoft is finally making good. but I am not, I'm more excited than anything at another good sign that Microsoft is finally done with legacy windows.
It's kind of sad; all the good stuff I use is basically legacy Windows. None of what Microsoft has done since Windows 7 has appealed to me.
Earlier quoted context omitted.
Not true. The DOM in Electron is precisely the same as the one on the web, yes. But while React is faster than some of the other data-driven frameworks, it is not faster than "old school" DOM manipulation. The advantage of modern frameworks is developer experience, not performance. The DOM API is fundamentally slow because of how much work the browser has to do under the hood to respond to changes. Every framework, i…
My point stands if by “updating DOM” it is meant the developer approach to making DOM changes, which in React go implicitly through a virtual DOM first, yes, which is vastly faster than updating the DOM directly. And an Electron app doesn’t need to be slow just because it uses a browser DOM. I work on a React project that has a faster UI than its native desktop counterpart.
Let me illustrate the DOM question with an example.
Let's say you've got an "old style" jQuery to-do app. The user types something into the field, and clicks "Add".
- The input field will be cleared
- A new element will be added to the list, containing the string
- The counts for "total items" and "items remaining" will be updated
Now let's say you rewrite this app in React. The user types something into the field, and clicks "Add".
- The input field will be cleared
- A new element will be added to the list, containing the string
- The counts for "total items" and "items remaining" will be updated
Your code that accomplishes this will look completely different - much more readable and less fragile - but the exact same DOM API calls will be made, and it will perform exactly the same.
The "speed" we associate with React is not in comparison to "old school" libraries, but to the naiive way of achieving data-driven syntax. You could just nuke the page entirely and re-render everything from scratch each time your data changes. This would be the easiest way of achieving data-driven syntax, but it would indeed be extremely slow. React gives you (something approaching) the performance of jQuery-style mutation, with the developer experience of reconstructing the DOM from scratch every time data changes.
Earlier quoted context omitted.
No mention of Linux despite how much they claim to "love" it.
If by "They" you mean me, someone who doesn't work on the project itself, but is advising over a toolchain for it. Also, I do not know what the Linux plans are (but hey maybe a great time to voice that special love you have for Linus T. and his masterpiece)!
[1] https://cloudblogs.microsoft.com/windowsserver/2015/05/06/mi...
Why not C#? Seems a bit of a missed opportunity to feed some of the APIs undoubtedly created for this into the new .net core stuff. I guess i'll just keep dreaming of the day when i can reliably convert a docx into a pdf without using office interop.
Also, I expect the existing code base isn’t small, so a rewrite won’t be ready soon.
That makes cross-compiling from whatever they have now to WebAssembly or JavaScript seem even better options.
Earlier quoted context omitted.
What makes it the better choice in this situation? C# can't run in browsers whereas Office 365 can.
You mean JavaScript not Office 365 right? They are working on compiling C# to Web Assembly FYI.
Earlier quoted context omitted.
C# doesn’t easily compile to the web. This is why they are rewriting office 365 in the first place right?
They just demoed running a winforms app in the browser using .NET CORE so maybe it would be less work/more successful to explore this path instead of trying to somehow re-implement the oxygen-sucking monster that is Excel using only the "new hotness (tm)". I bet this is only the new stuff like Delve and the less functional, more social apps/components. I can't imagine how they could pull this off for a full version o…
Besides, office currently isn’t written. In .net, they would be migrating away from C++ code.
Earlier quoted context omitted.
This thread is getting weird. Now we're arguing an entire language is trash because the Set type doesn't have native methods you want? Really?
It's just a tiny example of how silly this whole thing is. What's the point of having a committee to draft and design an language that can't even be bothered to have a working Set implementation? It simply doesn't make sense.