Hey Sean from webpack, this was really just about our third party plugin ecosystem needing to catch up to v5. If you are feeling IRL Stress, then please don't update yet. Sometimes you have to break things to create progress and ship major versions+bring new features. You don't have to use them, you can just use webpack's zero config out of the box.
We're trying to figure out on my team what the Edge Team's plan for rollout on OSes with IE11 already installed looks like; e.g., will Edge Chromium outright pull and replace Legacy Edge _and_ IE11 from Win7? And is "IE Mode" going to be an option on the non-Enterprise version of Chromium Edge?
I'd love to see more messaging around the rollout intentions; plenty of us out here still supporting IE11 (non-Government, non-Enterprise) and trying to read between the lines to a point where we can start legitimately calling the time of death.
As long as MS supports IE, we are mandated that we have to support IE. As far as I know, only IE11 is still supported by MS, but support will continues until 2025. The thought of all websites we build having to be compatible with IE11 until 2025 makes me sick. Is there any hope that rolling IE into Edge will shorten the time that IE11 is supported?
If it becomes a feature of Edge rathe than a standalone product, what is supported is now Edge (which has a feature allowing it to support legacy IE websites), not IE. That is, no one will be using a supported browser that only supports IE functionality, so while Edge users can access IE websites, there's no reason for anyone else to support IE in order to cater to those users, since they will actually be using a modern browser, not IE.
Will it be possible to 'remove' IE from Windows 10 (for example, via: Disable-WindowsOptionalFeature –Online -FeatureName Internet-Explorer-Optional-amd64) and then only allow users to access IE through the new Edge?
So implementing this took zero work? Probably not. Do you think it will cost nothing to maintain? Probably neither. So I don't see how "in no way" could be true.
Technically, maybe. In practice, each language has its culture, its ecosystem. Its set of tools to pick from. Is it reasonable to expect the JavaScript Office will really just bind directly to all the native APIs it was using before, thus incurring only 7% penalty (+/- FFI)? Or is it more likely that it'll have web rendering shoved in everywhere, and then layers upon layers of off-the-shelf JS libraries, thus incuring more like 700% penalty in resource use?
Doesn't it depend on the benchmark? Yes, for some numeric problem as described here (https://www.linkedin.com/pulse/algorithmic-performance-compa...), the 7% figure seems reasonable. But for a real world app with object creation/deletion, the C++ memory model at a lower level would provide a much better performance over a garbage collected higher level one.
And even if (hypotheically) the performance difference a constant 7%, that is still a tangible cost.
Yup, and that really was what the tweet was trying to portrait. JavaScript, and many scripting (or maybe author meant interpreted languages), are incredible languages to start with.
I have a love for the "sharper" langs like Rust, and AssemblyScript, however the ease of use, hyper backwards compatible, super super accessible package manager, and OSS Ecosystem for JavaScript are what make it world-eating. Plus its only 7-11% slower then C++ execution (last I checked).
Hi there, original tweeter here. Just to clarify: no one said when this work would land, simply that we are working on it! Sorry to disappoint XD, but I guess blame the OP.
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.
I rewrote a 3000 line VBA function into C# earlier this year for a Oil/Gas company. It was surprisingly easy. Sometimes tedious, but easy. It runs faster, it's easier to maintain and now they can slap whatever front-end they want on it.
Is it money, fear or gatekeeping that keeps these VBA programs untouchable?
I used to be in the Medical Devices field. A couple years ago, I was told to add a feature to a massive VBA app hosted in Excel that we (S/W development) inherited from another department. It was hands down the worst code I have ever seen. Everything was a global variable. I flat out told my boss that it barely worked, didn't come close to meeting the weakest of our development standards, and since it was used to disposition product (determine whether or not it was acceptable to be used on Patients) it was an FDA audit nightmare waiting to happen. I added the features, but made some pretty unpleasant commit comments since I didn't want to have my fingerprints all over it.
In all fairness, it was originally developed by a scientist with no SW dev training (I knew him well) for his own use, and just grew over the years as he was told to add more features to it. I have no idea how a company with that level of process strictness ever allowed this fiasco to happen.
[rant over]
I estimated the rewrite at 6-12 months. It was really not a very complex program and since we already had the Validation tests written and documented, we at least knew what tests its replacement would need to pass. The problem was all the stuff that we knew it was doing that wasn't in any of the tests. That would have been the majority of time spent to replace it.
Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.
> Since I left, I heard ownership of it was transferred to Corporate IT and they were making it into a web app to run on their intranet. Heaven help those guys.
At my last job, I developed automated processes. Some software companies sell tools to automate clicks and keypresses. The idea is then to reuse that Excel macro no one understands inside a VM on a server, and adding a friendly webservice on top of it. Users of the web services don't know an actual screen is running and and an Excel file is being clicked for them.
It's simply that the people doing the development only get to use VBA. Not that having a chemical engineer teach themself C# over their lunch break is going to turn out great software...
Having worked at a big company as a mechanical engineer and produced a few crappy VBA apps, I did it because it would take significantly more time and effort to get approval for an IT project, than to learn VBA and do it myself.
Most of them aren't maintained by technical people. Someone wrote some excel file years ago and every month it's copy pasted and the new data put in place of the old and it usually works until it doesn't.
> Is it money, fear or gatekeeping that keeps these VBA programs untouchable?
I was involved in work with a regional financial institution. They had a suite of line-of-business apps written in Access and VBA.[0] This was in a pure support and maintenance mode. This series of apps was written over the course of a decade by one developer nee business user. It represented a literal Great Wall of Chesterton.[1] There was so much process and institutional knowledge tied into this suite and the original developer left after being absorbed into the IT organization.
Some fun observations from work that was done on this suite of applications:
- "We can tell where the original developer learned various programming techniques and when something was written based on that."
- There was a source control and deployment app written entirely in Access DBs and VBA
- There were two scheduling applications, one designed to replace the other, but the first never fully retired. These launched jobs based on dependencies and timings.
- The applications ran in Access 2010. No upgrade was possible due to observed breakages when attempting to change.
- A Windows security update caused an outage for a day.
- Some data was centralized into a SQL Server instance and Access was a thin app layer on these tables. Others held data in the Access database.
- Different apps could reach into and run arbitrary queries on data of other apps. This was sort of RPC. Huge spooky action at a distance.
- There is a ticking time bomb based on Access database size limits. They run compaction jobs on a regular basis, with increasing frequency. One of the core apps will simply stop working one day in the not so distant future when its database cannot be compacted to be smaller than the Jet engine limit of 2GB.
I mentioned that this thing was in perennial support and maintenance mode. There were several assessments over the years for a migration to .Net. All were eventually scuttled due to cost and fear of functionality shifts. No one knew if what was there was correct, and some of the bugs we fixed demonstrated that there was plenty that was incorrect, though scope and impact were difficult to measure. No one wanted to own a migration due to the likely fallout. Different would be wrong, even in the face of huge evidence to the contrary. A C-suite executive was ousted largely over this suite of applications. The Access lives on.
Eventually a migration, in part or whole, will be necessary. It will be expensive. It will be painful. Each day increases the expense and pain. But every day, it is cheaper and easier to run and maintain.
[0] This thing hit commercial and customer facing processes, internal things like HR, letter generation, asset management, and basic reporting, among other things.
Don't count yourself so sure - A lot of shadow IT gets done by that excel expert in finance or the engineer who took a programming elective. If anyone ever gave them a database login password, odds are they're pulling into excel or access and writing VBA!
I dealt with it peripherally in my last job. Apparently the only reason Office has a 64bit version at all is Oil and Gas was causing Excel to run out of ram and demanded it. We were developing a COM addin, and we had clients complain that we broke some of their VBA they were using (turned out it was another VBA addin they were using that wasn't doing proper error handling). But it was definitely common for us to see clients that were deep into VBA.
My last job in finance(still am in finance fwiw) used much more VBA to price out billion-dollar swaps and swaptions than I was comfortable admitting to...
If it has a library that provides interop with the Common Language Runtime, then it's the next best thing.
And by the next "best" thing, I actually mean the next worst thing, because I've written apps that interop with VBA macros and no man or woman should ever suffer such an experience.
Writing apps to interop with VBA may be terrible, but embedding VBA in documents is a really useful feature that doesn't require your users to have a bunch of runtimes installed.
It's really not. YAML is a superset of JSON, but you wouldn't call a YAML document a JSON document. The set of all colors is a superset of the set containing only orange, but calling every color orange makes no sense.
I don't think it's exactly right to call it a superset either..
It adds types and constraints that have no effect on the resulting transpiled code besides an insurance that said type constraints are being met.
To better illustrate what I mean, in the start of a Unix script you sometimes have them augmented with #!interpreter. But this extra contextual information is not a superset of the scripting language itself. Likewise Typescript is also an augmentation that lives within the code that provides contextual information to the Typescript transpiler itself, but does not necessarily effect the actuall produced JavaScript.
All colours don't boil down to "orange" in Human eyes, so calling all colours orange really would be pointless. Typescript does compile down to JS, without which it can't even run. So yeah, when you're talking about the runtime or performance, Typescript === Javascript.
> Typescript does compile down to JS, without which it can't even run. So yeah, when you're talking about the runtime or performance, Typescript === Javascript.
By this kind of logic, C++ === machine code. It compiles down to it, right?
