There's a Skype for Business written in JavaScript? I know there is Skype, but it doesn't talk to our Skype for Business (Lync) server.... I have to use Pidgin for that. (Linux)
Definitely not. Unless it's the godawful Mac client that doesn't work for most things, which is possible, since it's using UCWA under the covers.
The Skype for Business Windows client was barely reskinned from the Lync 2013 client. I think they are still only a couple dozen patch revisions apart on the version number.
"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"
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.
From what I understand they are using React Native.
I too find it hard to believe they would drop the native Windows and OSX versions of Outlook, Word, Excel, for apps written in React Native. But Microsoft has offered many surprises lately...
This isn't Office for Windows the suite. WIN32 is a platform they're not really supporting any more, I think they're basically saying if you're on WIN32 then you're getting the web version in future, not the real deal.
UWP doesn't run on win7. If you think getting rid of WinXP was hard, wait to see the phasing out of Win7. If you write for the desktop, chances are you are writing an internal app. Lots of large enterprises (including my present employer) just switched to Win7. Win10 is a looong way ahead. A significant part of your userbase won't be able to touch a UWP app for a long time.
The whole thread and all later clarifications just look like a guy spewing random stuff loosely related with what he's working on at Microsoft. There's not much meaningful information to take from there.
I’m an engineer in Office. This is not the case. The desktop app’s are fully native, and will remain so. They utilize React Native for a few components, but otherwise are written in C & C++.
In my experience most people in Microsoft have only a vague idea of what other teams are doing, even when none of it is really secret. If Office is starting to adopt React Native for some of its new UI components, and meanwhile there's a lot of work happening on the Office 365 web portal and Office web apps, internal telephone rumor circulation can morph that into "all of Office is being rewritten in javascript"
Whoever makes the first neural model capable of returning interesting insights after being installed in the telephone switchboard/backbone is going to have a most unique life.
Edit: Just realized ISPs have probably been trying to do this for years. I'm talking about the first individual. It'll probably happen routinely in 20 years or so.
Nobody who truly participated in or contributed to the "complete" rewriting of Office in JS would be capable of expressing the positive emotions the subject of OP does...their soul would have been drained of the capacity to express joy long before the project would be completed. The tone smacks of the delusional cluelessness that MSFT's culture seems to uniquely foster.
Not only that, billions of hours of invested time and knowledge will be thrown out of the window instantly and everyone who integrates anything with Office will have to start again from scratch. Literally at least a third of the world is built on bits of spaghetti and duct tape on Office.
For developers though, this is chargeable so I'm on the fence :)
Kool-aid in the sense that JS is extremely attractive to MBA types that don't have to write anything with it. There is a huge pool of JS developers (quality is questionable but price range is mostly low), browsers run everywhere, Node.js made it possible to run the whole stack on it, so that's a win for MBA types and a great value proposition. The fact that it's a historically atrocious language doesn't matter as they have peasants (i.e. us) to deal with it (to be honest, it got much better since async/await was introduced, but hacks/warts are still there to be abused in horrible ways).
I wrote bleeding-edge games and other crazy stuff in JS you might be using right now in your business, so my opinion is not unfounded.
We're mostly just bitter from years of being beaten with it. I can't actually face using node.js as an example. It is physically painful compared to other options that I have dealt with (flask, asp.net). Also for me, I've been burned before. Do you remember when everyone jumped on the PHP bandwagon? That. Again. Look where we are now.
On the web, and now suddenly on the desktop, velocity is not what we need. We need quality and consolidation. Down the line can you see any ES6 based API lasting as long as win32? Hell no. Why would I want to risk building a major capital product on such guarantees?
The language has some very ugly warts (although ES6+ fixes many things), I find that the quality/maturity/stability of third party libraries lags behind other languages, and the whole build/dev environment best practices is constantly in flux and breaking things all the time. Also Electron, for all it's advantages, is renowned for being a massive resource hog making what is otherwise a fairly fast and efficient language appear horribly slow at times.
That being said, developing in JS today is a lot better than 3-4 years ago, and I suspect that that pattern will continue.
I wrote crypto algorithms and protocols, compression algorithms, browser engine sandboxes and similar in JS professionally for 5 years (don't ask why), and often had to deal with fun things like mis-compilations from JS engines and other fun bugs. I'd argue that I have quite extensive knowledge of JS, far beyond the average JS programmer (but far from the highest of experts, of course).
JS's only unique, redeeming quality is its availability through the deployment of web browsers, and the benefits that come with such widespread use. JS wins marketshare because it has marketshare. Any language could have taken JS's place, and most would have been better. WebAssembly, when DOM integration and others become a thing, might allow us to throw JS off its throne.
JS doesn't have advantages on its own to make of for its disadvantages, and relies heavily on extremely advanced JITs to make it borderline acceptable. The language itself still has very clear signs of having been designed on the back of a used napkin (its number type, its "array of int16's" string, "this", "prototype", ...).
I would like to acknowledge that ES2016 brought some things that did remove some retarded areas of JS (like arrow functions, which do not have its own "this" context, unlike the old function expression, class definitions that can briefly make you forget the terrible underlying "prototype" madness, and ways to access proper unicode code points in strings), but we are very far away from having actual advantages here.
JS has bad parts. That's why there is a popular book called Javascript the Good Parts. So sure old-school JS could be gnarly, but as the book says, you just use a linter and ignore the bad parts, and what you're left with is a very straight forward, clean and practical language. And now with Typescript on top too, we got the wonders of static typing also. What's not to like?
I think most devs who dislike it because it reduces the barrier to entry which undermines both their own prestige and quality of coworkers. Its similar to dislike of outsourcing in many ways.
From a technical perspective, there are couple disadvantages in the long run that can make large codebases unmaintainable. In particular JS and PHP are resistant to static code analysis since they support functions like exec. So it becomes difficult to deprecate functions because the references are not necessarily explicit, thus can lead to tech debt buildup. ES6 does a better job but its backwards compatibility can leave the code vulnerable.
> I think most devs who dislike it because it reduces the barrier to entry which undermines both their own prestige and quality of coworkers.
I think the prestige comment is a bit unfair, but today at work I had to educate a JS dev on what headers are in a HTTP request/request and some other pretty basic things (a dictionary/record type object and a JSON string are not the same thing for one). They were like "I know I've got to do these things, but I don't know why/how they work".
So yeah, I don't think disliking it because that's the average quality of JS dev I see is an unreasonable position. I'm sure there's some great ones out there doing impressive things, but I'm sure you could point them towards nearly any language and they'd produce something equally cool.
How much more real world evidence does HN need to see before the "JS isn't a real language" meme is abandoned?
Pretty sure we're up to billions of real world value created by software written in Javascript. If you're still dismissive at this point, it's time to catch up. You've missed the boat.
It's a "real" language, it's just not a terribly good or fast one. It's works decently when its use is limited to what it was made for: manipulating web pages. For anything else, the "designed on the back of a used piece of toilet paper" starts to shine through.
And no, a JIT can't save you from this, it can only make things acceptable.
That it can create "real world value" is an extremely low bar, which is passed by any turing complete language. COBOL creates "real world value".
From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that.
>not terribly good
This one never has made sense. What is it missing that makes you hate it so? I think it has rather robust asynchronous handling, 'everything is an object' has lots of nice implications when paired with functionality like Object.keys / .assign, ... So what are the issues you see that make it 'bad'?
"4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.
> so I'll disregard that.
You shouldn't. Claiming a JIT'ed language is fast due to being faster than Python, an entirely interpreted language, is like saying a moped is a fast vehicle because it's faster than biking. Apples and oranges.
Being faster than PyPy, the JIT'ed Python implementation, is a more interesting thing, but this is still very far off "fast" languages.
> What is it missing that makes you hate it so?
Most language features, really. "Everything is an object and objects are hashmaps, EVEN ARRAYS" (terrible for performance, type safety), "array of int16" strings with totally broken unicode codepoint handling (ES2016 brought new ways to deal with codepoints, but the standard way is still broken), the "Number" type which is totally retarted, the terrible "prototype" system, the malice that is "this" and how any bare function expression had its own this context (arrow functions are a good workaround now), and god I could go on.
"Everything is an object" is only useful if you either actually need a hashmap (then use one!), or you have sloppy types.
JS, as a langauge, is not well designed. I'm not saying it had to be Haskell or Rust, but JS is far below average.
It works, and does it job decently due to the very hard work of JS engine implementors trying to make this crazy thing fast, but that's not the same as being good.
Wow, now we're complaining about the outdated versions of a language? Come on man. Nobody is going to write a modern application in ES5 and there are plenty of warts in old Java, C and Python applications as well. That's the nature of them being "old".
Why does that impact whether or not it's a reasonable choice to use the language today? Old libraries I could understand, but old independent projects? How do they affect the current state of the language?
Isn't it obvious? You apply for a job, company that isn't a startup has code that is likely written with old JavaScript whose replacement is not economical, so even if you do everything new in ES7, you still have to wade through old ugly code, likely everyday.
I read it that he meant "fixes for these things are missing and that makes me hate it", i.e. I read it as the answer to your question. He doesn't hate it because it lacks features, he hates it because the existing features are badly implemented/thought-out.
> 4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.
That's a solid argument for only programming in C and Assembly because they are often 4x faster than anything.
> Most language features, really.
AKA, your preferences are "language features".
> Everything is an object
So you don't like Python. Or Ruby.
> the "Number" type which is totally retarted
Very technical argument there.
> the terrible "prototype" system
So you prefer classical inheritance. Cool. Doesn't mean prototypal inheritance is a bad thing.
None of what you mentioned are missing features, they are personal preferences stemming for your own language preference that differs dramatically from Javascript. I'd start by disassociating your opinionated stances from actual weaknesses in the language, of which there are many, and none of them are what you mentioned.
If I threw billions of dollars of vested interest at Python/Ruby/COBOL/(insert language of your choice) we can probably make those run at JS speeds as well. Does that solve the fundamental drawbacks of the languages?
Nope. No it does not.
JavaScript is particularly egregious because of it's weird behaviour about types and coercion and you know, just silently failing, behaviour that I wouldn't want going on in any proper system that handles anything important. Other people have written at great length about JS's many failings.
JS is not the only language with nice async support, practically every mature language has async support and a good number of the compiled ones have proper parallel support as well.
every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.
sure wish i knew what you are talking about w/r/t "silently failing". JS has working exceptions just like 99% of widely used languages.
I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.
> every dynamically-typed language has "weird" behaviour around type coercion
Do they now?
$ irb
irb(main):001:0> "0" + 1
TypeError: no implicit conversion of Fixnum into String
from (irb):1:in `+'
from (irb):1
from /usr/bin/irb:11:in `<main>'
irb(main):002:0> ^D
$ python
>>> "0" + 1
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: cannot concatenate 'str' and 'int' objects
>>> ^D
$ node
> "0" + 1
'01'
> Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.
If you never worry about those things, then you're either not sharing any resources at all (in which case threads are also dead easy), or you're failing to deal with the shared resources properly.
I know you know this, but for the GP or anyone else: "Dynamically typed" doesn't mean "strongly typed". Python and Ruby are strongly typed, JS is weakly typed.
Thank you for illustrating my point. All of the dynamic languages made different decisions on how to handle type conflicts, there simply is no right or wrong answer.
Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.
> every dynamically-typed language has "weird" behaviour around type coercion, that's simply the nature of the beast.
No, that's not true at all. Dynamic languages don't necessarily have type coercion at all, much less weird behavior around it (and, conversely, statically typed languages they have coercion may have weird behavior around it; there's just no link between dynamic typing and weird coercion behavior.)
> Who's to say not doing type coercion isn't weird?
Well, if someone has to do it, I will: not doing type coercion isn't weird, and doing inplicit type coercion (not strict promotion[0]) is both weird and dangerous.
But, in any cases that's not really the point. The point is that in this...
> Every dynamic language treats things slightly differently.
“dynamic” is irrelevant. Languages have a wide variety of approaches, doing promotion, coercion, neither, or both (though where both are done, it's often just called coercion even when it is promotion), and dynamic vs. static is mostly irrelevant.
[0] that is, where the “from" type has a range that is a subset of the range of the “to” type.so that there is never a change in meaning resulting from the conversion.
> I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core
Yeah, and I can do the same thing in Python, and it will be equally as lame: both languages are fundamentally single-threaded.
You act as if JS has all problems solved: Erlang/Elixir/Golang have far superior async & parallel stories and will happily thrash JS/Node in performance and efficiency.
How’s it working out for me? Well I do a lot of stuff in Haskell and Rust now, so pretty great actually.
I think this is a really important point. Every browser vendor has spent huge amounts of dollars to increase the performance of Javascript. I don't know if there's another language that has enjoyed this level of investment... Maybe Java is closest, there are multiple companies working on their own VM implementations.
The reason so much has been spent on Javascript: it runs in the web browser. For sure, people have found other reasons to like Javascript but at the bottom of the pile, money was spent because it was in the browser and the browser vendors wanted the browser to do more.
1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al.
2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. And as a bonus, Maven Central isn't going to go down next Tuesday because Timmy in Alberta threw a temper tantrum or something.
3. A sense of stability. Javascript's framework churn is just exhausting.
2. After the npmjs.com registry became immutable and npm got lockfiles I feel npm is pretty much there as far as dependency management systems go. I'm not sure if npm shares the cache across projects (like the ~/.m2/repositories folder for maven/gradle/leiningen), but you can get that with the yarn client if saving disk space is important.
> until strong typing is mandatory in the language, I can't fathom using JS in any sizable project.
There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language.
> A sane dependency management framework. Maven solved this problem a decade ago.
A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not.
> A sense of stability. Javascript's framework churn is just exhausting.
> ...until strong typing is mandatory in the language, I can't fathom using JS in any sizable project.
There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects.
I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process).
Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.
What creates hostility is the sentiment of being forced to use a bad language. There are many alternatives to python or php but none really to javascript (transpilers hacks apart). Webassembly might change that.
The only other language that I have seen generating as much hostility is vb6, and also I believe because some developpers found themselves forced to use it.
Oh yeah, just wait until during a job interview somebody complains that you aren't "pythonic" enough, i.e. don't use some weird inconsistent syntactic wart somebody learned to love.
Have you ever used a language like Elixir? After using Elixir, my first thought was "why the f would anyone even use JS in 2018?" That's how poor the design choices of JavaScript are. Not to mention that the name itself is trademarked by the biggest troll (Oracle corporation).
After using something like Elixir, you'll even wish if Javascript could be permanently banned from the Software industry for ever.
I use Elixir + Ruby + Coffeescript and I still wish JS was never invented.
I used to think the same thing back when I used Clojure + ClojureScript. Hah, what idiot would choose Javascript over my god tier Clojure/Script setup?
Well, one day I actually tried to build a company and my cofounder just couldn't be fucked to learn Clojure. We decided on Node. I was forced to learn how to play nice with Javascript where I learned how to appreciate it.
Nowadays, I have a hard time justifying something like Clojure/Script over Javascript. Same with Elixir. And I am very wary of people who can't spot trade-offs since that was how I used to be, and I was wrong. I just didn't have enough experience.
There is no best. There are only trade-offs. Elixir/Clojure might be a good business decision for your project, but if you can't concede any positives to Javascript, I don't think you have a firm grip. And in the end it's always a business decision, not a technical one.
"There are only two kinds of file systems. Those that corrupt your data eventually and those nobody uses."
Luckily, filesystem designers worked hard at making their filesystems journaling, fault tolerant, and more. And we stopped complaining angrily about filesystems ruining weeks (or months) of work, because it stopped being a regular occurrence.
We still complain about the flaws of C++ because they are a constant source of pain.
Stroustrup is arguing that if something is popular criticisms against it must therefore be invalid. He's wrong.
I don't think he's saying the criticisms are invalid, but just that they are at the forefront of more people's minds because the respective language is more prevalent. Languages that are barely used also have their problems - they are just undiscovered or spoken about less.
If he wanted to make the really mundane point that people don't complain about things they don't use there would be absolutely no reason to bring C++ into it. He could just remark that nobody complains about the bad handling of the Model T anymore because nobody drives it. It's true but why is that relevant or at all interesting? Do we really believe this is the mundane observation Stroustrup is making?
No. Stroustrup uses his snarky retort to deflect criticism. When C++ is criticized by (academic) language designers, his comment reads as "and yet people use my language and not yours". And that's pretty immature.
Popular tools have to meet a high quality standard because every wart in the language affects millions of people.
Good languages are local maxima in the language design landscape. C is a good language. As is Python. And C#. There are many projects for which C or Python or C# are fine language choices.
Other languages have great ideas in them, but the languages themselves are a mixed bag. Perl, Java, C++. Perl inspired Ruby. Java inspired C#. But we haven't seen a good successor to C++ yet, probably because building a systems language is much more difficult than building an interpreted/scripting language.
COBOL was the state of the art when it was designed, but any evolution on top of that is, by necessity, limited by a 60-year-old core design. While it _has_ produced a lot of real world value in the almost 6 decades of its existence, starting a new project in COBOL would be ill-advised.
Existing projects were written in whatever language for whatever reasons, it's "Would I start a project in this language today?" that's the bar to beat in terms of language "quality" and, in that sense, COBOL is a fairly low bar for most domains.
"real world value" is a completely fair metric. You might be able to argue that different languages offer more value than JS, for different use cases. But mocking the idea of "real world value" seems to completely miss the underlying point of app development -- which is to deliver value.
Again, "delivering value" is a ridiculously low bar, when you measure "value delivered" by revenue. We ought to do better than that.
Some extra hoops to jump above "delivering value (measured in revenue)" are:
- Not creating extra problems for yourself down the line (maintenance costs, complexity, technical debt).
- Not creating extra problems for everyone else (promotion of technologies causing problems if adopted).
- Not dumping externalities on other people (inefficient solutions causing worse UX, more frustration and extra electricity usage).
- Delivering actual value, as measured on the user end (whether or not the software makes them more productive), instead of revenue end (i.e. did we manage to trick enough people to pay us?).
Let's not confuse popularity (as in lots of users) and popularity (as in lots of love). Death and taxes are popular too! People write javascript because they have no other choice to run in the browser. I don't see that as a testimony that it is a great language.
If your only concern is the ergonomics of the language then there are lots of compile-to-JS languages. Some of them also compile to WebAssembly, which allows them to bypass the GC. It’s still not native speed, but it’s close enough for many applications.
There are pros and cons, but within the next few years it could become common to write in your language of choice, compile to WebAssembly, and ship an app that’s within roughly 50% of native speed.
I imagine JS will still be hugely popular even in that scenario, but that’s a different topic.
JS empowers beginners and disempowers advanced developers. If you are learning programming, JS helps you, if you need sensible pro-level features, you are out of luck.
But, just #1 in that list - You need to use a utility library to work with data types in a normalized form? In 2018?? Let that sink in. I hadn't had to do this with any other language.
It's about prevalence. The more prevalent a language is, the more the complainers come out in force. PHP is another language that has created billions of dollars of value, yet it doesn't stop the computer science purists from bashing it every other day. Just ignore the negativity and keep writing code in what makes sense to you.
"Pretty sure we're up to billions of technical debt created by software written in Javascript."
There, I fixed that for you. I didn't miss the boat. I've had to maintain mountains of awful code written by careless programmers in a pathetic language with a morass of constantly changing libraries for run-times (web browsers) that can't even be counted on to interpret the code the same.
It's very much in the same state that VB was, or even "Excel programming" is today: it certainly works and it certainly produces a lot of business value. It's just that the downsides appear further down the road; maintainbility and scalability issues, or intrinsic conversion causing data loss. That kind of thing.
Every time someone waits for an Electron app to load, or watches it eat their ram? That gets added to the prejudice scale. Every overly-slow page load that eats mobile battery. The feeling that "it doesn't have to be this way" is very strong.
These aren't Electron apps. They are applications written in Javascript and compiled to native via ReactXP and react-native-windows.
Maintainability is a problem regardless of language, scaling is moot as these run native code, scalability is an odd word choice given we are talking about desktop apps, and intrinsic conversion can be solved via TypeScript, Flow or any other typing framework. C, Java and C# all have their own set of downsides as well, but we don't pretend those aren't "real" languages.
You are correct that "it doesn't have to be this way" which is why native compilation exists and is continuing to grow.
I don't think JavaScript itself is the problem here. Electron is slow to load and uses a lot of memory because it's loading an entire multiprocess Chromium runtime with all of the Web platform implemented, optimized for speed and security rather than memory usage.
Microsoft are using React Native here (aside from the Win32 build), which is going to be a lot more lightweight because it relies on the native platform for the heavy lifting.
Nobody is claiming you can't write real software in JS. What they're saying is that it is a waste to do so when so much better tools are available. When you're in the browser there are such huge benefits that it makes sense. Elsewhere I find it hard to understand JS mania.
I will abandon my skepticism of JavaScript as soon as JavaScript boosters abandon their infomercialesque “millions of people can’t be wrong!” attitude and make a compelling case for the language itself. JavaScript is all we have for web dev which is why it’s so popular. That doesn’t mean it isn’t a fundamentally flawed language, it just means that no one has been able to popularize better solutions because of network effects.
the millions are not saying it's perfect. that would be wrong. as you say what we have is js, so let's move on and make something useful with it instead of complaining about it being flawed. it is evolving, being standardized and getting new features. its not going to go away anytime soon, so instead educate yourself into avoid the pitfalls that exist in the language and have fun being productive.
this js-is-not-a-real-language stand is only to be expected from someone like a professor or a computer science student. universities and educational institutions in general will always be the last ones to adapt to changes, after the rest of society has moved forward, and they will try imposing those conservative opinions on everyone who are not in their camp. times are changing, computers are becoming more complex and we need more abstractions too. and the ignorant js-is-only-a-scripting-language statement is simply not true anymore.
Except computers have not gotten more complex. We are dealing with the same kind of filesystems, virtual memory, relational databases, encryption, compression, and network stacks as 20 years ago.
Objections against javascript are not Luddite objections against all types of higher level abstractions; the complaint is that javascript is not suitable for the creation of complex high quality software. If you beat your head against the javascript walls long enough can get something to work eventually, but that's not much of an endorsement.
The only thing javascript has going for it is the delivery mechanism, and that is what makes it so compelling for business use. But this is not because javascript is so good, it's that the other methods of packaging/delivering software are so painful.
The total absence of high quality software written in javascript is sufficient evidence to conclude that javascript is not a tool suitable for serious application development.
> The total absence of high quality software written in javascript is sufficient evidence to conclude that javascript is not a tool suitable for serious application development.
a little overstatement, but okay. js is very suitable for this in my opinion. i don't what counts as "serious" application development in your world, but i've seen quite many good, performant applications around written in js. and servers too!
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)
> how is that even possible? there are tons of legacy features in there, COM/OLE APIs, SDKs, plugin architecture, macro system, VBA interpreter, VBA IDE, graphing components etc. Almost 30 years of development. No way MS is going to rewrite all of that. (Maybe the "mobile" version)
I think this is a strong indication that all these technologies are going away.
This would be suicide for Office. I struggle to believe that Microsoft is replacing the full Windows desktop version of Office with a version rewritten in JS. It makes no sense. Many, many, many businesses absolutely rely on the features you're mentioning, and many others that would be a tremendous undertaking to re-implement. There has to be something that's not being communicated right here. Maybe they mean the "lite" versions of the programs.
Strongly agree. Backwards compatibility has always been a strong suit for MS. Changing that stance is a major strategic shift, and IMHO would be a huge error, similar in scale to IBM's open PC architecture.
I also think it’s extremely unlikely MS is announcing an new native code compiler for JavaScript, something I’m not sure anyone knows how to do with reasonable performance, with a Tweet this casual.
Has been said many many many times , it's not electron for Windows 10 , it's React Native .NET which bridges the built in Javascript VM with WPF. So it's not a web view for UWP, it's 100% native code.
Have you even read the comment you're replying to? Where the hell did you read that OP loves linus torvalds or linux. Microsoft is the one that claims to "love" linux [1], yet they don't release a linux version of office despite it being programmed to be platform independent. Why are you intentionally trying to misrepresent what OP said?
You and I know how to code. Most excel users do not. There is just simply not enough programmers in the world to do what all business users achieve and run on Excel.
I wonder, is it actually JS or they are using TypeScript? VSCode is written in TypeScript but it was mentioned there that it's JS, did somebody mixed things up?
Yeah, we can verify the validity of the statement since most of these project are open source. It's all Typescript, not JavaScript. according to the OP:
>> Those are one in the same thing (compiled) :-). But us TypeScript in majority at Microsoft in almost all the projects I've seen or been apart of.
Using the same logic, could we say that all windows is written in assembly ? When looking at JavaScript output of a Typescript program, it does really look like JavaScript is treated as assembly.
One almost never edits the JavaScript code when using Typescript, especially if the mapped ts files are available when debugging in F12.
Surprised they didn’t opt for Typescript. Then again, it’s a tweet - looking forward to a longer blog post with technical details when they’re willing to talk about it more.
C++ used to be a superset of C too before they diverged, but Objective C and C++ are/were viewed, correctly, as different languages from the same family.
I assume that they have. Typescript compiles down to Javascript so the tweet is technically correct (written in TS, executed in JS) and there are many out there who won't have a clue what TS is but have at least some grasp of what JS is so JS was probably stated instead of TS to avoid confusion amongst the unwashed masses.
Oh god please I hope they have. In my experience, dynamically typed scripting languages struggle to keep up with the rigorous structure enforced by statically typed languages once the project gets large enough.
Yes, in theory you _can_ write big projects well in dynamically typed languages, but in practice you get a mess of undocumented interfaces and unit tests that don't quite catch the plethora of errors not present when a static type system is in place.
I think Typescript is a great middle ground between the loose running JS hipsters and the Haskell loving Hindley-Milner type system CS researchers. You can enforce the type restraints that you want (I personally am strict about explicit "string | null" declarations) but you're still hip enough to draw the JS talent.
Too bad they didn't go with row types instead of structural sub-typing. Though that might not have matched with their goals of being able to type existing JavaScript. Not sure.
Exactly. Going structural was purely to match JavaScript interop. Heck, even Dart went with nominal sub typing, it isn’t a very common choice fo an non-functional language.
Why is this trend going on with using js in domains where it previously was not a component?
Office products need to be on the web these days. Having a common code base between desktops, mobile and web makes that much easier and in that world JavaScript is the lowest common denominator.
The positive side of breaking compatibility with all legacy technologies (COM, VBA, XLL, etc) that currently force large companies to stick to MS Office is that it has the potential to reintroduce competition in the office-like software space. And in my opinion Office is the main reason why large enterprises stick to Windows. Most internal apps are moving to the web. If office backward compatibility goes away, then it's not clear that Windows is an obvious choice anymore.
And it is kind of consistent with Microsoft's new strategy to de-emphasize Windows.
It says that the the JavaScript is compiled to native code. That's not something you get from React Native today is it? Have they implemented a new native code compiler for JavaScript? I wonder what compiler technology it uses.
I was wondering that after reading more of the tweets; React native doesn’t compile the JS to native, so not sure what they are using to do all of that? Bit worried about the far superior languages C# and F# if they are not even dogfooding anymore.
There has been a constant divide between the developer tools division (where C# comes from) of Microsoft and the OS/Office divisions. They both have worked very differently in the past and not at all in the same directions.
> Scripting languages as first programming language for CS bachelors are WRONG. You are not able to write an OS, a DBMS, or even an Office suite with an scripting language.
I honestly thought this was a satire tweet. I guess I just don't associate even a CS bachelor's degree with writing that kind of software. I mean, it can, but there are more theoretical tracks that don't involve writing a OS/DBMS.
Most of the CS tracks I've seen recently (and even back in my days) have an "introduction to C/Linux" module which requires writing common command line tools, starting easy and gradually ramping up to a basic shell, a web proxy, etc.
I very much agree that this is a broken line of argumentation.
However, I find the opinion to be correct: Scripting languages might not be a good first programming language for a CS bachelor, where priority is deep learning of programming. I'd also argue that JavaScript would be a bad candidate, as it is a very "unclean" language, being a poor way to teach language/compiler theory.
As a first practical programming language for a non-CS bachelor, scripting languages are fine. Without CS courses to support you, other approaches might be too difficult, while scripting languages often let you get (terrible) programs up and running (ish) while ignoring basically all CS aspects during the learning phase (only while you're not making anything big, though—the "high level" illusion breaks down fast as things grow).
(Also, yes, you can write a DBMS or an Office suite in a scripting language. I can't possibly comprehend why you'd want to do something like that, but it's very much possible. Bringing OS's into things is cheating, as most compiled languages can't be used there either, and those that work often only work with a subset of the full language.)
> for a CS bachelor, where priority is deep learning of programming
The priority is deep learning of computer science, not of programming.
I think JavaScript is a fine language for teaching a lot of CS basics. For example you could run a course based on SICP using JavaScript instead of Scheme, I believe.
You can't deeply learn programming in a language like assembly or even C. You don't have enough expressiveness to tackle large-scale problems (like office suites or DBs!) within the scope of what one person can work on in one semester; you'd be spending your time thinking about how to implement a hash table instead of how to use one.
One of the nice things about so-called scripting languages is the breadth of library support. If you want to put together a GUI that displays some word-wrapped text, you can do that within the first hour of using the language, if you have some homework instructions you're following. At that point you can think about the interesting parts of writing a word processor, and not just how to put a window on screen (which tends to be more about docs and APIs and not about actual computer science). Also, importantly, at that point you've successfully done something, which is pretty important for the learning process.
At least here in the UK, all high-quality CS courses emphasise a functional language in the first year. The rigour and purity is important for teaching abstract concepts.
I had to take a mandatory course where we wrote a simple flat-file db in x86 assembly, complete with a simple console-based interface. I’ve rarely needed to even look at assembly professionally, let alone write a real db, but I fully agree with the tweet.
This is good news for those of us who have to deal with VSTO, MSI packaging and all that cack. At last it might not feel like being buggered by a traffic cone repeatedly.
The ideal of an IT dept is to force all of their users to use only a locked down ipad. Of course they won't be able to achieve any work on them, and productivity will go down the drain, but that's not the problem of the IT department.
For instance, see the `Set` implementation here <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and note that it doesn't even has `union` and `intersection` in the standard library. You have to copy/paste some code and place somewhere to have a minimum usable `Set` implementation.
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.
It's a pointless example that's trivial to fix. There are actual problems with Javascript. The examples you and many other detractors mention expose the actual problem: You have no idea how to use the language because you don't use it. Instead you whine about some trivial things (At a method to the Set type... it would take minutes), or things you don't understand (prototypal inheritance).
It's not about adding a method or two, I showed one symptom of a much larger problem. Of course one can add a method, but then why bother with the default crippled implementation in the first place? I'd rather have nothing and go find a third party library than having a half-assed one that's almost useless.
> You have no idea how to use the language because you don't use it.
So I think “pile of trash” might be a bit too far, but JavaScript is a weird choice for one major reason: most languages have several objective technical and strategiec advantages. JavaScript has exactly two: it is the only language available in a browser, and it is on a large number of people’s resumes. There is no technical dimension of JavaScript that makes it the best choice for any task outside the browser, and the commonality advantage is shared by many other languages. If anyone has a good counter argument, I would love to hear it. I’m not saying that to be snarky, I genuinely want to hear perspectives in defense of JS other than “well it’s a good language because so many people use it and it’s better than it used to be”
How on earth am I the one who needs to "[s]how some initiative" when some guy literally just says "JS is a flaming pile of trash" and gives no justification?
It was an ad hominem and I asked him to expound on it.
Time to apply for a 20M dollar loan to buy a semi supercomputer in order to run skype, slack and office all together. Any remarks on cray supercomputers?
Exactly. Microsoft won't tell their enterprise customers that their crypto now runs in a browser and is no longer compliant with the standards of their industries. They would lose almost all of their sales revenue if they did that.
I'll wait until it's done, released, and I have the opportunity to actually use it. Skype is already much worse than the original, so I really hope they don't go this way. I'm definitely not going to buy a 32GB notebook just to be able to use the most recent version of MS Office. (32 GB is nice BTW but a huge battery drain.)
458 comments
[ 3.7 ms ] story [ 308 ms ] threadThe Skype for Business Windows client was barely reskinned from the Lync 2013 client. I think they are still only a couple dozen patch revisions apart on the version number.
It would just be nice to be able to join Skype/Lync meetings with Screen sharing.
edit, since there seems to be some confusion: I am explicitly talking about the WIN32 variant, which he confirmed to be based on Electron.
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.
I too find it hard to believe they would drop the native Windows and OSX versions of Outlook, Word, Excel, for apps written in React Native. But Microsoft has offered many surprises lately...
https://mobile.twitter.com/TheLarkInn/status/100677077815354...
> WIN32 (only one that uses electron)
which happens to be the version most people use.
What's that? Win32 a second class citizen? Never!
It was a very smart move of MS to kill newer chipsets :-(
If they hadn't done that, win10 would have completely tanked
So, what the hell was this guy tweeting about?
Whoever makes the first neural model capable of returning interesting insights after being installed in the telephone switchboard/backbone is going to have a most unique life.
Edit: Just realized ISPs have probably been trying to do this for years. I'm talking about the first individual. It'll probably happen routinely in 20 years or so.
Can somebody please design even worse language so that we can progress by reimplementing everything in it, keeping us occupied for the next 20 years?
For developers though, this is chargeable so I'm on the fence :)
What's wrong with JS, exactly, that isn't made up for by its advantages?
I see these 'kool-aid' / 'JS is cancer' comments all the time, but they don't come with any real details.
I feel like you've probably never really used JS, if I'm being honest.
I wrote bleeding-edge games and other crazy stuff in JS you might be using right now in your business, so my opinion is not unfounded.
On the web, and now suddenly on the desktop, velocity is not what we need. We need quality and consolidation. Down the line can you see any ES6 based API lasting as long as win32? Hell no. Why would I want to risk building a major capital product on such guarantees?
The language has some very ugly warts (although ES6+ fixes many things), I find that the quality/maturity/stability of third party libraries lags behind other languages, and the whole build/dev environment best practices is constantly in flux and breaking things all the time. Also Electron, for all it's advantages, is renowned for being a massive resource hog making what is otherwise a fairly fast and efficient language appear horribly slow at times.
That being said, developing in JS today is a lot better than 3-4 years ago, and I suspect that that pattern will continue.
JS's only unique, redeeming quality is its availability through the deployment of web browsers, and the benefits that come with such widespread use. JS wins marketshare because it has marketshare. Any language could have taken JS's place, and most would have been better. WebAssembly, when DOM integration and others become a thing, might allow us to throw JS off its throne.
JS doesn't have advantages on its own to make of for its disadvantages, and relies heavily on extremely advanced JITs to make it borderline acceptable. The language itself still has very clear signs of having been designed on the back of a used napkin (its number type, its "array of int16's" string, "this", "prototype", ...).
I would like to acknowledge that ES2016 brought some things that did remove some retarded areas of JS (like arrow functions, which do not have its own "this" context, unlike the old function expression, class definitions that can briefly make you forget the terrible underlying "prototype" madness, and ways to access proper unicode code points in strings), but we are very far away from having actual advantages here.
From a technical perspective, there are couple disadvantages in the long run that can make large codebases unmaintainable. In particular JS and PHP are resistant to static code analysis since they support functions like exec. So it becomes difficult to deprecate functions because the references are not necessarily explicit, thus can lead to tech debt buildup. ES6 does a better job but its backwards compatibility can leave the code vulnerable.
I think the prestige comment is a bit unfair, but today at work I had to educate a JS dev on what headers are in a HTTP request/request and some other pretty basic things (a dictionary/record type object and a JSON string are not the same thing for one). They were like "I know I've got to do these things, but I don't know why/how they work".
So yeah, I don't think disliking it because that's the average quality of JS dev I see is an unreasonable position. I'm sure there's some great ones out there doing impressive things, but I'm sure you could point them towards nearly any language and they'd produce something equally cool.
I'd say they'd produce something massively cooler ;-)
Pretty sure we're up to billions of real world value created by software written in Javascript. If you're still dismissive at this point, it's time to catch up. You've missed the boat.
And no, a JIT can't save you from this, it can only make things acceptable.
That it can create "real world value" is an extremely low bar, which is passed by any turing complete language. COBOL creates "real world value".
From everything I've seen, its performance sits just below Java (4x slower, perhaps) on some standard algorithms or tasks, and significantly faster than languages like Ruby, Python, etc.. I never see hate for those languages like for JS, so I'll disregard that.
>not terribly good
This one never has made sense. What is it missing that makes you hate it so? I think it has rather robust asynchronous handling, 'everything is an object' has lots of nice implications when paired with functionality like Object.keys / .assign, ... So what are the issues you see that make it 'bad'?
"4x" is a lot slower, and a lot of things are much worse than this. You have to have deep knowledge of the VM (such as knowing how "hidden classes" work in V8) to be able to get JS close to Java.
> so I'll disregard that.
You shouldn't. Claiming a JIT'ed language is fast due to being faster than Python, an entirely interpreted language, is like saying a moped is a fast vehicle because it's faster than biking. Apples and oranges.
Being faster than PyPy, the JIT'ed Python implementation, is a more interesting thing, but this is still very far off "fast" languages.
> What is it missing that makes you hate it so?
Most language features, really. "Everything is an object and objects are hashmaps, EVEN ARRAYS" (terrible for performance, type safety), "array of int16" strings with totally broken unicode codepoint handling (ES2016 brought new ways to deal with codepoints, but the standard way is still broken), the "Number" type which is totally retarted, the terrible "prototype" system, the malice that is "this" and how any bare function expression had its own this context (arrow functions are a good workaround now), and god I could go on.
"Everything is an object" is only useful if you either actually need a hashmap (then use one!), or you have sloppy types.
JS, as a langauge, is not well designed. I'm not saying it had to be Haskell or Rust, but JS is far below average.
It works, and does it job decently due to the very hard work of JS engine implementors trying to make this crazy thing fast, but that's not the same as being good.
But you still have to compute hashcode yourself :D
Name a few.
>terrible "prototype" system
>malice that is "this"
It sounds like you are talking about ES5, not ES6+
He did, literally exactly after that sentence.
That's a solid argument for only programming in C and Assembly because they are often 4x faster than anything.
> Most language features, really.
AKA, your preferences are "language features".
> Everything is an object
So you don't like Python. Or Ruby.
> the "Number" type which is totally retarted
Very technical argument there.
> the terrible "prototype" system
So you prefer classical inheritance. Cool. Doesn't mean prototypal inheritance is a bad thing.
None of what you mentioned are missing features, they are personal preferences stemming for your own language preference that differs dramatically from Javascript. I'd start by disassociating your opinionated stances from actual weaknesses in the language, of which there are many, and none of them are what you mentioned.
Nope. No it does not.
JavaScript is particularly egregious because of it's weird behaviour about types and coercion and you know, just silently failing, behaviour that I wouldn't want going on in any proper system that handles anything important. Other people have written at great length about JS's many failings.
JS is not the only language with nice async support, practically every mature language has async support and a good number of the compiled ones have proper parallel support as well.
sure wish i knew what you are talking about w/r/t "silently failing". JS has working exceptions just like 99% of widely used languages.
I'm very glad that you've been omniscient enough to determine what "proper" parallel support is, though. How's that working out for you? Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.
Do they now?
> Meanwhile, those of us using JavaScript simply run one process per core and never worry about contention, deadlocks, or race conditions.If you never worry about those things, then you're either not sharing any resources at all (in which case threads are also dead easy), or you're failing to deal with the shared resources properly.
Oh, and JavaScript is single-threaded. It's impossible to share resources in a single process.
DBs, files, etc etc. in-process memory isn't the only resource you're sharing.
No, that's not true at all. Dynamic languages don't necessarily have type coercion at all, much less weird behavior around it (and, conversely, statically typed languages they have coercion may have weird behavior around it; there's just no link between dynamic typing and weird coercion behavior.)
Well, if someone has to do it, I will: not doing type coercion isn't weird, and doing inplicit type coercion (not strict promotion[0]) is both weird and dangerous.
But, in any cases that's not really the point. The point is that in this...
> Every dynamic language treats things slightly differently.
“dynamic” is irrelevant. Languages have a wide variety of approaches, doing promotion, coercion, neither, or both (though where both are done, it's often just called coercion even when it is promotion), and dynamic vs. static is mostly irrelevant.
[0] that is, where the “from" type has a range that is a subset of the range of the “to” type.so that there is never a change in meaning resulting from the conversion.
Yeah, and I can do the same thing in Python, and it will be equally as lame: both languages are fundamentally single-threaded.
You act as if JS has all problems solved: Erlang/Elixir/Golang have far superior async & parallel stories and will happily thrash JS/Node in performance and efficiency.
How’s it working out for me? Well I do a lot of stuff in Haskell and Rust now, so pretty great actually.
The reason so much has been spent on Javascript: it runs in the web browser. For sure, people have found other reasons to like Javascript but at the bottom of the pile, money was spent because it was in the browser and the browser vendors wanted the browser to do more.
1. Type Safety. TypeScript helps, but until strong typing is mandatory in the language, I can't fathom using JS in any sizable project. This is also true of Python, et al.
2. A sane dependency management framework. Maven solved this problem a decade ago. Gradle is trying to fix Maven's XML mistake. But the fact is, if I need a dependency in Java, I know how to get it. And as a bonus, Maven Central isn't going to go down next Tuesday because Timmy in Alberta threw a temper tantrum or something.
3. A sense of stability. Javascript's framework churn is just exhausting.
There are massive JS projects in production today, but that's moot. It's never going to be mandatory because that ruins the point. Typing isn't a requirement of a language.
> A sane dependency management framework. Maven solved this problem a decade ago.
A Rube Goldberg machine that solved a problem? Maven's goals may have solved the problem, but its implementation did not.
> A sense of stability. Javascript's framework churn is just exhausting.
Feature, not a bug.
There are quite a large number of counter-examples to show type safety isn't especially important to the success of large projects.
I think the guarantees it provides are far too limited and weak to support large software systems. It relies on static code analysis, which doesn't mean much unless your app is a single build and runs as a single instance. That's more of a '90's style Microsoft Word type of app than what a typical large software project is today. Meanwhile the guarantees it does provide are only helpful to the extent developers can map their domain problems to the capabilities of the type system. Sometimes there is a nice natural fit, but usually the typesystem is both too weak (doesn't provide a convenient and natural way to impose the constraits of your problem domain) and too strong (imposes constraints your don't need or want, encumbering your development process).
Not to mention that when it comes to Javascript, you can opt-in to about as much static code analysis, including type-safety, as you want.
The only other language that I have seen generating as much hostility is vb6, and also I believe because some developpers found themselves forced to use it.
After using something like Elixir, you'll even wish if Javascript could be permanently banned from the Software industry for ever.
I use Elixir + Ruby + Coffeescript and I still wish JS was never invented.
https://twitter.com/bendhalpern/status/578925947245633536?la...
I used to think the same thing back when I used Clojure + ClojureScript. Hah, what idiot would choose Javascript over my god tier Clojure/Script setup?
Well, one day I actually tried to build a company and my cofounder just couldn't be fucked to learn Clojure. We decided on Node. I was forced to learn how to play nice with Javascript where I learned how to appreciate it.
Nowadays, I have a hard time justifying something like Clojure/Script over Javascript. Same with Elixir. And I am very wary of people who can't spot trade-offs since that was how I used to be, and I was wrong. I just didn't have enough experience.
There is no best. There are only trade-offs. Elixir/Clojure might be a good business decision for your project, but if you can't concede any positives to Javascript, I don't think you have a firm grip. And in the end it's always a business decision, not a technical one.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses."
- Bjarne Stroustrup
Luckily, filesystem designers worked hard at making their filesystems journaling, fault tolerant, and more. And we stopped complaining angrily about filesystems ruining weeks (or months) of work, because it stopped being a regular occurrence.
We still complain about the flaws of C++ because they are a constant source of pain.
Stroustrup is arguing that if something is popular criticisms against it must therefore be invalid. He's wrong.
No. Stroustrup uses his snarky retort to deflect criticism. When C++ is criticized by (academic) language designers, his comment reads as "and yet people use my language and not yours". And that's pretty immature.
Popular tools have to meet a high quality standard because every wart in the language affects millions of people.
Are you suggesting C or Haskell are without their problems? What is your definition of a "good" language?
Other languages have great ideas in them, but the languages themselves are a mixed bag. Perl, Java, C++. Perl inspired Ruby. Java inspired C#. But we haven't seen a good successor to C++ yet, probably because building a systems language is much more difficult than building an interpreted/scripting language.
Maybe D, but outside Facebook nobody really uses it.
The old Javascript were very bad, recent Javascripts were bad, today's Javascript are OK, future Javascript / TypeScript is actually pretty decent.
Of course I do hope something else has taken its place.
Existing projects were written in whatever language for whatever reasons, it's "Would I start a project in this language today?" that's the bar to beat in terms of language "quality" and, in that sense, COBOL is a fairly low bar for most domains.
Some extra hoops to jump above "delivering value (measured in revenue)" are:
- Not creating extra problems for yourself down the line (maintenance costs, complexity, technical debt).
- Not creating extra problems for everyone else (promotion of technologies causing problems if adopted).
- Not dumping externalities on other people (inefficient solutions causing worse UX, more frustration and extra electricity usage).
- Delivering actual value, as measured on the user end (whether or not the software makes them more productive), instead of revenue end (i.e. did we manage to trick enough people to pay us?).
There are pros and cons, but within the next few years it could become common to write in your language of choice, compile to WebAssembly, and ship an app that’s within roughly 50% of native speed.
I imagine JS will still be hugely popular even in that scenario, but that’s a different topic.
https://blog.bitsrc.io/11-javascript-utility-libraries-you-s...
It's too big for a TLDR;
But, just #1 in that list - You need to use a utility library to work with data types in a normalized form? In 2018?? Let that sink in. I hadn't had to do this with any other language.
There, I fixed that for you. I didn't miss the boat. I've had to maintain mountains of awful code written by careless programmers in a pathetic language with a morass of constantly changing libraries for run-times (web browsers) that can't even be counted on to interpret the code the same.
"There are only two kinds of languages: the ones people complain about and the ones nobody uses." - Bjarne Stroustrup
Every time someone waits for an Electron app to load, or watches it eat their ram? That gets added to the prejudice scale. Every overly-slow page load that eats mobile battery. The feeling that "it doesn't have to be this way" is very strong.
Maintainability is a problem regardless of language, scaling is moot as these run native code, scalability is an odd word choice given we are talking about desktop apps, and intrinsic conversion can be solved via TypeScript, Flow or any other typing framework. C, Java and C# all have their own set of downsides as well, but we don't pretend those aren't "real" languages.
You are correct that "it doesn't have to be this way" which is why native compilation exists and is continuing to grow.
Microsoft are using React Native here (aside from the Win32 build), which is going to be a lot more lightweight because it relies on the native platform for the heavy lifting.
Objections against javascript are not Luddite objections against all types of higher level abstractions; the complaint is that javascript is not suitable for the creation of complex high quality software. If you beat your head against the javascript walls long enough can get something to work eventually, but that's not much of an endorsement.
The only thing javascript has going for it is the delivery mechanism, and that is what makes it so compelling for business use. But this is not because javascript is so good, it's that the other methods of packaging/delivering software are so painful.
The total absence of high quality software written in javascript is sufficient evidence to conclude that javascript is not a tool suitable for serious application development.
a little overstatement, but okay. js is very suitable for this in my opinion. i don't what counts as "serious" application development in your world, but i've seen quite many good, performant applications around written in js. and servers too!
> how is that even possible? there are tons of legacy features in there, COM/OLE APIs, SDKs, plugin architecture, macro system, VBA interpreter, VBA IDE, graphing components etc. Almost 30 years of development. No way MS is going to rewrite all of that. (Maybe the "mobile" version)
I think this is a strong indication that all these technologies are going away.
He's said it's not compiling the JavaScript to native code - it's running it in a normal JavaScript JIT. It's not 100% native code.
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...
(I have no idea how other formats are structured)
>> Those are one in the same thing (compiled) :-). But us TypeScript in majority at Microsoft in almost all the projects I've seen or been apart of.
Using the same logic, could we say that all windows is written in assembly ? When looking at JavaScript output of a Typescript program, it does really look like JavaScript is treated as assembly.
One almost never edits the JavaScript code when using Typescript, especially if the mapped ts files are available when debugging in F12.
I assume that they have. Typescript compiles down to Javascript so the tweet is technically correct (written in TS, executed in JS) and there are many out there who won't have a clue what TS is but have at least some grasp of what JS is so JS was probably stated instead of TS to avoid confusion amongst the unwashed masses.
Yes, in theory you _can_ write big projects well in dynamically typed languages, but in practice you get a mess of undocumented interfaces and unit tests that don't quite catch the plethora of errors not present when a static type system is in place.
I think Typescript is a great middle ground between the loose running JS hipsters and the Haskell loving Hindley-Milner type system CS researchers. You can enforce the type restraints that you want (I personally am strict about explicit "string | null" declarations) but you're still hip enough to draw the JS talent.
Still not sure if it's just a 'cool hack' or an attempt at a serious product though.
Is it to ease shipping new features? To make it easier for contributors once they make the application open source? Good PR?
Office products need to be on the web these days. Having a common code base between desktops, mobile and web makes that much easier and in that world JavaScript is the lowest common denominator.
And it is kind of consistent with Microsoft's new strategy to de-emphasize Windows.
Which is the end result of Webification of our tools.
I think it's just people are used to the OS itself. I've seen people stick to Windows just because even in small companies.
https://mobile.twitter.com/jdgarciauc3m/status/1005768121230...
> Tip of the day.
> Scripting languages as first programming language for CS bachelors are WRONG. You are not able to write an OS, a DBMS, or even an Office suite with an scripting language.
I honestly thought this was a satire tweet. I guess I just don't associate even a CS bachelor's degree with writing that kind of software. I mean, it can, but there are more theoretical tracks that don't involve writing a OS/DBMS.
Not exactly OS/DBMS but still pretty low-level.
However, I find the opinion to be correct: Scripting languages might not be a good first programming language for a CS bachelor, where priority is deep learning of programming. I'd also argue that JavaScript would be a bad candidate, as it is a very "unclean" language, being a poor way to teach language/compiler theory.
As a first practical programming language for a non-CS bachelor, scripting languages are fine. Without CS courses to support you, other approaches might be too difficult, while scripting languages often let you get (terrible) programs up and running (ish) while ignoring basically all CS aspects during the learning phase (only while you're not making anything big, though—the "high level" illusion breaks down fast as things grow).
(Also, yes, you can write a DBMS or an Office suite in a scripting language. I can't possibly comprehend why you'd want to do something like that, but it's very much possible. Bringing OS's into things is cheating, as most compiled languages can't be used there either, and those that work often only work with a subset of the full language.)
The priority is deep learning of computer science, not of programming.
I think JavaScript is a fine language for teaching a lot of CS basics. For example you could run a course based on SICP using JavaScript instead of Scheme, I believe.
One of the nice things about so-called scripting languages is the breadth of library support. If you want to put together a GUI that displays some word-wrapped text, you can do that within the first hour of using the language, if you have some homework instructions you're following. At that point you can think about the interesting parts of writing a word processor, and not just how to put a window on screen (which tends to be more about docs and APIs and not about actual computer science). Also, importantly, at that point you've successfully done something, which is pretty important for the learning process.
For instance, see the `Set` implementation here <https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... and note that it doesn't even has `union` and `intersection` in the standard library. You have to copy/paste some code and place somewhere to have a minimum usable `Set` implementation.
Pretty much a "pile of trash" in my opinion.
> You have no idea how to use the language because you don't use it.
I do use it daily for more than 15 years.
You're basically praising it with such faint condemnation.
And by your own metric, I can't imagine how bad you think Golang is.
Seriously?
How about async-everything?
Any number of other mature languages have async (and parallel, unlike JS) tools available.
Can you give a simple analysis on what weaknesses JS has that other languages would avoid with no pitfalls of their own?
It was an ad hominem and I asked him to expound on it.
Half the battery goes to edge alone on a good day