> he has more than 65% of the overall share vote

So when WeWork responded with

-"The board is aware of it and has approved it"

they probably meant

-"Neuman is aware of it and has approved it" right ?

Don't think so. Corporate boards still go with one person, one vote, not percentage weighted.

Who do you think selects the directors?

I recently did the exact same job as the author of this post.

Migrating 15K LoC from JS to TS.

The author of Vue.JS also migrated Vue completely to Typescript.

At first I had major apprehension because of how much Microsoft generally enforces things on developers.

It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )

But after I did the migration , I was blown away by how confident and how much flexibility I had when i was writing my code.

Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence.

Having used Javascript since before Node.JS , I think the whole idea of having to "transpile" my code to something or to respect some "rules" define by a company with a reputation that wasn't really "all in open source" .

But after using Typescript on multiples projects , you just can't go back , it's incredible how well it's scale without enforcing anything on the developers.

Hopefully , one day bootcamps will include Typescript in their trainings to demonstrate how typings can solve maintainability issues...

"Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence."

Same here.

Isn't this truly amazing?

Take a jangly language like JS, and add some typing for the compiler, which forces you to write cleaner code in addition to all the compiler advantages ... combined with some really cool features and bang a magical, pragmatic language.

Aside for some script things for which Python is still a blessing, I'd chose TS for everything else, at least to start.

It just has the right mix of flexibility and expressivity etc..

Though TS is an MS project, I suggest it really is quite different, it's 'open from the start' kind of thing, you can have a loot at TSC internals. The team seems to be fairly dynamic and responsive.

Typscript is my #1 favorite 'invention' of the last few years, I think it will be around for a while, and I hope to see many more JS API's 'properly documented' with the help of TS.

> Take a jangly language like JS, and add some typing for the compiler, which forces you to write cleaner code in addition to all the compiler advantages ... combined with some really cool features and bang a magical, pragmatic language.

Agreed. And when you compare how TS was designed to how other languages were designed, it makes a lot of sense why TS ended up being such a great language.

Unlike virtually every other language in existence, TS was not designed from the ground up. It was designed with a very specific goal in mind: to adhere to the standards that JS developers had already converged on. So when a JS developer said if (foo), TS was built to realize that was an implicit type check against null. When a JS developer said if (obj.type === “bar”), TS read that as a way to ensure obj was in fact a bar.

It’s unlikely that a language developer working from scratch would have come up with these odd idioms, let alone prioritized their inclusion into a new language. But in the case of TS, all these idioms came from millions of lines of working code.

I think that’s why TS feels so enjoyable and easy to work with nowadays, whereas even the best of other languages feel a little clunky at times. It was developed prioritizing making real actual code idioms people wanted to do work.

> when you compare how TS was designed to how other languages were designed

Is it safe to say that Microsoft has probably created/designed more programming languages than any other company? I can think of a dozen off the top of my head...

Anders Hejlsberg, the lead architect behind TypeScript has created C# and J++ at Microsoft, and Delphi and Turbo Pascal before. It's safe to say he has some experience in designing languages.

J++ is one of the primary reasons I am so wary about using a Microsoft-invented language. "Embrace and extend" a well-used language with extra features (then make them only work well on Windows later) has always been a classic Microsoft strategy. If they could get away with it with Typescript, I'm sure they would try again.

Thank you! This is the argument that made me give TypeScript a try. I work in Kotlin day to day which tries to fix its base language (and batteries included with it) while not fixing it too much. TS sounded like a language in that vein.

The exception I'd add is that JavaScript's standard library is still very weak. I find myself leaning on Lodash for functionality that would be built into any other language.

Part of me would love for TS to build one out and add shims as part of the transpilation process, but it would go miles out of the scope of what TS is trying to do. And I love that (compared to Babel) TS has no plugins and relatively few options.

To add onto this, using lodash + TS is not the most pleasant experience. A lot of that has to due with current limitations of the type system (mostly variadic types [0]), but I find myself having to provide lots of generics rather than relying on inference. The overloads are not great.

I say this all with recognition that lodash greatly predates TS, and the maintainers have done an absolutely wonderful job in keeping up with the overall ecosystem (ESM, typings files, etc). I can't even begin to comprehend the amount of work that has gone in to keeping lodash so modern.

That being said, I wish the interaction was slightly better, since a lot of people just immediately bring in Lodash to any JS project.

[0] https://github.com/Microsoft/TypeScript/issues/5453

I have the same experience; I wonder if anyone is working on a TS-friendly utility library, or if our best hope is the work on TS itself on [0]?

I wonder if ramda is any better in that regard?

I love Ramda and use it everywhere but sadly, it's somewhat lacking when it comes to type definitions. Everything in Ramda is curried and the types just don't reflect that very well so you get quite a few incorrect compiler errors.

Yeah, I remember liking the auto-currying, that makes sense it has a downside here.

Shouldn't tuples in rest parameters from TypeScript 3.0 [0] fix that?

[0] https://www.typescriptlang.org/docs/handbook/release-notes/t...

Not entirely.

For example, a function which takes a property path (in the form of an array of strings) and an object as parameters and returns the value at that path inside the object still needs overloads for every single tuple length.

  type Key = string | number | symbol;
  
  function get<T, K extends keyof T>(path: [K], obj: T): T[K];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1]>(path: [K1, K2], obj: T): T[K1][K2];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2]>(path: [K1, K2, K3], obj: T): T[K1][K2][K3];
  function get<T, K1 extends keyof T, K2 extends keyof T[K1], K3 extends keyof T[K1][K2], K4 extends keyof T[K1][K2][K3]>(path: [K1, K2, K3, K4], obj: T): T[K1][K2][K3][K4];
  function get(path: Key[], obj: any) {
      if (path.length === 0) {
          return obj;
      }
      const key = path[0] as Key;
      const rest = path.slice(1) as [Key];
      return get(rest, obj[key]);
  }
  
  
  interface Foo {
      foo: {
          bar: {
              baz: {
                  val: number;
              }
          }
      }
  }
  
  declare const foo: Foo;
  const num = get(["foo", "bar", "baz", "val"], foo);

In this case, num is implicitly typed as number, but if the path would be longer, you'd need to add more overloads.

I keep hearing that but I dunno. I’m building a fairly large side project in Express + React and I keep finding ways of doing things in ES6 - lodash is still not to be found in package.json. I think I might cave in eventually but as it stands my code feels clean and succinct and it’s all done in modern functional style.

One example is doing deep comparison on objects. ES6 still has no equivalent for that, and it's something you can do in one line in other languages.

Which languages? I'd think it's rare because I know no such standard function from the top of my head.

Swift immediately comes to mind - structs are value types. Also, Kotlin has data classes.

`util.deepStrictEqual` in Node at least

This is a very good point.

I wish lodashy functions, and a few other things (Time?), were just integrated into JS, in a thoughtful way ... as part of the standard lib. So they could all be done in native code in the engine.

I’m sympathetic to this point of view, but I find lodash to be too huge of an API. Most of the collection methods can be done as a small _.reduce, and I find the many method names and subtle distinctions to add more trivia than they remove.

The good news is that you can use lodash as an ES6 module, with any tree-shake capable bundler stripping out all the crap. Absolutely agree it's not optimal though.

This is a pain point that the community wishes to address: https://github.com/tc39/proposal-javascript-standard-library

I don’t see this going very far for historical reasons. This idea has been suggested for over a decade, but back then the focus of inspiration was jQuery. The false argument was that everybody was requesting it into pages anyways so it should be part of the language. Not only was this idea proposed on top of a faulty assumption but there were also performance penalties and hidden conformance defects.

These suggestions fall apart over time because they aren’t environment agnostic and lack objectivity. The subjectivity in question, “I want feature X”, usually doesn’t take alternate positions into consideration.

The proposal explicitly states that everything in the standard library would not be tied to specific target environments:

Such a library would only cover features which would be useful in JavaScript in general, not things which are tied to the web platform. (A good heuristic: if something would make sense on a web browser but not in node or on embedded devices or robots, it probably isn't in scope.)

Truth be said, jQuery can be seen obsolete because most of the functionality has been moved inside the DOM or the ajax "standard library" ...

This certainly wasn't a popular opinion 10 years ago. The history lesson here is that popular is a subjective quality that does not provide objective benefits, which is clear in a future time.

Well, as I said you could think that is jQuery "has been added" to the javascript expected api. Some functions calls has been renamed, others have been superseded, but the "vanillajs" of 201x is pretty different from the 199x - and more similar to the jQuery usage.

jQuery rise (but also underscore and others "low level libs) was interwined with the need of common functionalities, such as the DOM manipolation and the ajax calls. I still remember when all you could use was the .innerHTML property and the "new" DOM level 1 api [ https://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/ ]. jQuery selectors were so game-changing that the "new" DOM api were basically copied.

I understand how incredibly difficult is to find a good balance between an "anemic" stdlib (like the barely sufficient c stdlib) to the giant ones (like java has had), moreso that a bad/poorly secured function should still be mantained "forever" for backward compatibility.

Still I think that this movement should go forward to finally have some form of "batteries included"

I guess I disagree as I much prefer Ramdas style over Lodash.. Is your concern about performance? Because I don't think it would be a massive improvement over JS code.

Curious what you're still often using lodash for?

One thing that comes to mind is comparison - array equality, deep object comparison, that sort of thing.

> Aside for some script things for which Python is still a blessing, I'd chose TS for everything else, at least to start.

I really wish Python had a decent type system; hopefully the Mypy project takes a leaf from TypeScript's book.

Also, I've found that Go does for Python much of what TypeScript does for JavaScript. Of course, Go's APIs are different than Python's and its type system is less expressive than TypeScript so it's not a perfect analog, but Go also brings speed, parallelism, sane concurrency (Python's async is a hot mess by comparison), sane deployment, and great editor integrations, which are things I sorely miss when writing Python.

Mypy is already quite powerful and understands a lot of the language. With latest versions of the language, what is handled by "transpiling" to JS, can be done "natively", ie. there is no need for an intermediate step to strip out the additional syntax for declaring types as it's now built in.

Mypy and TC and Flow and many other similar projects seem to stem from the academic work on gradual typing from nearly 20 years ago. What we're seeing now is "practical application" of that research, and while different projects have different budgets, it won't be surprising if they all converge in terms of features at some point. I'm not an expert, by any means, but we've already seen this happening many times with languages and software platforms. At least this time the point of convergence is based on comp-sci research and not on the marketing one.

My grievance is mostly that Mypy is much less polished than TS and Flow (you can argue that it's a lack of investment and that's probably true, but it doesn't do me any good as a Python developer). Notably, Mypy's syntax is very much shoehorned in. How do I define a TypeVar for a particular method in a class? If I define a TypeVar (<T>) in the class scope, does every reference to T take on the same type? I can't honestly tell by looking if it's safe to use <T> for each generic method in a class or if the type system will try to unify them to the same type. Also, does Mypy support recursive types yet? Can I meaningfully define a JSON type without hacks (e.g., `Dict[str, Any]`)? Also, can I stub out generated types yet? IIRC, the official position for SQLAlchemy was something like "eh, it's out of scope for the project". Pretty sure there was a lot of problems with defining different kinds of callables (maybe those with args and kwargs?) not to mention a bunch of ergonomic problems because they don't want to extend the parser much (it appears they take the view that it's better to have terrible syntax that is "valid Python" without much modification to the Python parser--to be clear, this isn't referring to angle brackets vs square brackets, but things like using variable declaration syntax in an outer scope to declare a type variable for a generic context).

Python's type annotation syntax is mostly similar to TypeScript.

Each method is independent unless the class is a Generic[T].

You can define a recursive type by quoting the nested reference.

You can define a JSON type with recursive types.

You can create stubs. Some are in typeshed.[1]

Mypy recently added protocols to simplify defining callable types.

Python has always been slow to add new syntax. I think that's a good thing overall.

[1] https://github.com/python/typeshed/

> You can define a recursive type by quoting the nested reference.

No, that’s not sufficient, or at least it wasn’t. The problem wasn’t symbol resolution, but Mypy actually gave you a recursion error. At one time they were intending to fix it by implementing protocols which hadn’t landed last I checked.

> You can create stubs. Some are in typeshed.

You can, but not for magical libraries like SQLAlchemy.

> Python has always been slow to add new syntax. I think that's a good thing overall.

Probably, but it’s hindering their typing story. Typescript solves the problem by building a syntax that compiled to JS, but Python has some syntax support but lots of things are shoehorned in.

I think the biggest win of Go over Python is around the single binary distribution, which I guess you included with deployments. But it truly deserves a mention on its own and it’s a major point over other (most?) languages. It really makes up for a lot of the shortcomings of Go as a language IMO. But I enjoy Go best for building system tools, the single binary doesn’t shine as much once you involve containers at which point the friction between say a Python/Node container and a Go container is pretty much the same

That’s definitely up there. As for containers, I think Go’s static compilation story actually has some important ramifications for containers, namely I don’t need a set of base images for doing development since I can just toss a binary into the container and run it there (running in the container is useful because our local dev setup uses Docker Compose to orchestrate the microservices). If we could do this with Python it would simplify our CI and our development process by a good bit. And of course Go images are about a factor of magnitude smaller than Python images to boot!

Turns out creating a static binary distribution can be done in Python without containers [0].

[0] http://www.pyinstaller.org/

The tiny size of an Alpine + Go container is still nice compared to a typical Node or Python container, though.

Try the Go/scratch combo (2.5MB): https://weberc2.bitbucket.io/posts/golang-docker-scratch-app...

> Take a jangly language like JS, and add some typing for the compiler

It so turns out that there is a great sweet spot in between the straight jacket typing of classic Java/C# and the loose "do way ever you like" approach in Python/JS.

I don't want use another language that doesn't have optional typing and structural typing. It combines the best of both ends of the spectrum.

My thinking exactly.

Wow, almost...almost reminds me of a little known language called ActionScript 3. ;)

As someone who hated ActionScript 3, I vehemently disagree. AS3 felt like some Java guys trying to force a Java mindset on a language that didn't really suit it.

And I say that as a Java guy myself. TS is much more dynamic and less abrasive, IMO.

Funny, I feel the same way about TS :) To be fair tho, you’re right. Flex was a very Java centric endeavor, from its compiler to the first big frameworks (Caignorm?) all the way to its target audience, which were enterprise companies that wanted to do their “thing” on the web. There was a massive developer migration from the Java/enterprise world to the AS3 ecosystem that had a visible impact. Also to be fair, if you look at Angular now with TS it feels even more Java’ish than ever. TS is great, is specially good for people coming from different languages in that it gives them a more familiar environment but the downside is that they have to make a lower effort to break away from old patterns and truly understand the new platform they’re working on.

AS3 was a huge improvement over AS2. However Typescript type system is incredibly dynamic and malleable yet quite strict.

Typescript gets its huge strength from being able to bring a slider of type safety from pure js - Wild West crazy to strong null checked safety.

Having that pragmatic option of a slider is great for productivity.

> if you look at Angular now with TS it feels even more Java’ish than ever.

This is true, but I think it's an Angular thing rather than a TS thing.

I think it is hurting Angular in the marketplace, too.

Whenever I feel in the mood to troll people, I tell them that TS is just a worse AS3. AS3 has types, classes... it even had XML literals! Eat that, JSX.

To be more precise, TS is a worse ES4. AS was a partially conforming implementation of ES4 drafts that most are aware of. But Microsoft had its own thing along these lines - JScript.NET (in fact, it still ships as part of the .NET Framework, even though it's deprecated).

I've heard it said that Javascript and C are both good languages to compile to -- the language itself is very "fast" in basic operations (V8 is hyper-optimized, C is relatively close to the metal), but an ugly language with lots of gotchas and warts that make it hard for a human to use effectively, but which don't pose a problem for a well-designed compiler.

No lol. Javascript is not a good language to compile to. People compile to JavaScript only because it's the only language to run in browsers.

Most compilers, after type checking and semantic analyses, basically generate a control flow graph with basic blocks. Javascript doesn't have goto so it doesn't allow you to express those low-level things natively, which is why emscripten has to include a relooper component to turn them back into loops and conditionals.

If you want a good language to compile to, look at LLVM. It's a language designed to be compiled to, and it's mind-blowingly easy to compile to than either C or JavaScript.

It's maybe worth noting here that compiling to C and transpiling to JS are two entirely different paradigms of linking and building a software release.

> Aside for some script things for which Python is still a blessing, …

Have you tried using type hints (https://www.python.org/dev/peps/pep-0484/) with mypy?

> Though TS is an MS project, I suggest it really is quite different

I'd be willing to say it's actually the "heart" of the new MS. Eliminating the incentive to selling OS licenses is doing marvels for them.

I'm starting to think Microsoft's strategy with things like VS Code, Monaco editor, and Typescript is "blow the developer away with how amazingly productive they are so that they will want to use more of our products". Because it's just so high quality yet also gratis/libre (MIT license), that I can't see what else they could be trying to do.

Honestly I also think its a recruiting tool for Microsoft. Developers watch the meaningful and useful open source contributions made by Microsoft, and some of the highbrow disinterest in Microsoft due to choices made in the past will fade.

Never forget "Embrace, extend, extinguish". Microsoft has a history of adopting open standards, adding value to them to gain market share, then leveraging that to destroy their competition.

Microsoft might seem to be an "open source champion" now, but remember that it is a publicly traded corporation with a fiduciary responsibility to maximize profits for its shareholders and a history of anti-competitive, anti-consumer practices.

Right now they are being warm and fuzzy to regain the developer mind-share they have lost over the past couple decades to open-source software. If they get a large percentage of developers using their tools and services (looking at you GitHub) I would not trust that they will continue to be so warm and fuzzy.

I know how "Embrace, extend, extinguish" works when the product people are "locked" into is closed source and propriety. But explain to me how this works when the product is open source and can be forked by anyone?

They may not be able to do "Embrace, extend, extinguish" in the exact same way with their open-source efforts, but that doesn't mean they would not be able to apply leverage given sufficient market share.

Imagine if VSCode becomes the defacto code editor. Then they add seamless integration with GitHub, including value-added features which are not available from other providers like gitlab. Developers accept it because everyone uses GitHub anyway. Then they add features to GitHub to integrate seamlessly with Azure, and bug tickets related to GitHub plugins for interop with AWS start to take longer and longer to be resolved. Then maybe one day they change the terms of service, and it's no longer allowed to develop GitHub plugins which compete with Azure. Then they release an update to VSCode which uses deep learning for code completion. On Windows it uses a new DX12-powered subsystem which makes it fast and responsive, while on Mac and Linux it falls back to a single-threaded solution which makes the whole application feel laggy.

In a scenario like that, it would be in principal possible to fork VSCode and make a more platorm-agnostic version, but how realistic is it that an individual, or even a small team will be able to keep up with a large corporation which seeks to make such an effort less successful.

Open source software is great, but if Microsoft owns the governance of those projects, and the up-streams and down-streams, they still have a lot of power over them.

Tooling is commodity now. If they don't make tools that run well on other platforms then other vendors step in to fill the demand, or they just wont have the demand in the first place and they lose mindshare anyway.

This is what happened with Java, Go and Javascript growing rapidly while .NET took a long time to get out of legacy/desktop phase, partly because the tooling was fantastic but isolated to their own Windows platform. They've learned their lesson and have realized there are better businesses by providing the compute and making it easy to use with free and plentiful tools.

Your scenario sounds not only plausible but highly likely. Especially the point about individuals or other principle-driven organizations being relatively unable to reproduce the closed-source advantages that they could tie into open source projects to make them significantly more useful on MS-blessed platforms and systems. This is all a very real possibility.

One assumes Amazon & Google both see that possibility and are developing some in-house expertise on those projects.

But maybe that history is also a strength. The typescript developers never extend the capabilites of the language, just add types. The only exception being decorators, that was a deal with angular so they don't have to invent their own language for angular2 and can build dependency injection on it by typescript exposing the types to the runtime. But decorators are stil buried behind an experimental flag.

You've explained some of the strengths of TypeScript, but I fail to see the argument for how this is evidence that it's somehow a good thing that Microsoft has a history of being quite a bad actor in the software industry.

TypeScript has other features such as Enums that don't exist in JavaScript but aren't pure type annotations either. It transforms into very clever bidirectional map tables.

Yes, and I will start looking into azure because of this same amazing feeling I'm having with VS code and typescript.

Definitely look into it, but it isn't nearly as robust as AWS. Automation/DevOps and data streaming/processing are some lacking areas.

Fine if you just need PaaS app + RDB though.

The interface is astonishingly Windows'ish with millions of knobs to turn and not as stable as you want. (Resource usage metrics returned errors for a while on me.)

You will need time to get used to it. I even use AWS for a Windows instance.

If it's as cheap and powerful as AWS then I'm on board too. But I doubt it is, Amazon's got it down to an intricate science that seems like it can't be beat.

Depending on specifics (obviously), Azure is quite competitive with Amazon on pricing, and extremely competitive on "power". Your mileage will of course vary, but the interesting thing about Azure versus AWS is (surprising to some) Azure tends to use more "open standards" versus AWS' proprietary solutions. (Two examples off the top of my head: Azure supports Docker and Kubernetes directly rather than the Elastic TLAs' own in house container models and container orchestrators. Azure's most used in-memory cache is Redis.)

This is not new -- Steve Ballmer understood this viscerally (ahem) over 10 years ago:

https://www.youtube.com/watch?v=Vhh_GeBPOhs

Granted, they weren't releasing much open source then, but it was all free to use, and the quality was far above open source alternatives (e.g. think the Visual Studio debugger vs. GDB wrappers).

I think they just naturally figured out that there's zero advantage to keeping developer tools closed source.

MS has long been about "Developers! Developers! Developers!" But these days they're about more than just Windows developers shipping native closed source applications.

Yet Visual Studio (not the Code) is still a payware with multiple editions.

You can build anything with the free community edition and they keep down-shifting previously enterprise features with every major version.

It's probably multi-faceted. Part of me thinks it's just something they use internally extensively and that branching out to the public means they can easily hire talent to work on their own projects. It's also probably an effort to stay relevant and make amends with web developers, who have long held them in low regard.

And yeah, Azure is a booming business for them. VSCode has a bunch of first-party extensions that reduce friction for working on their platform.

Microsoft's tooling is fantastic

Trying to work with other databases after using SQL Studio is incredibly frustrating

It appears the tide is changing and what was once hated upon by many in the JS and front-end community, has now become cool and a tonne of projects are migrating. Another project migrating to TypeScript is the Aurelia Javascript Framework for its next version coming out later in 2019.

It's funny because I remember when Angular 2 was announced and that it would be written completely in TypeScript, they copped a lot of backlash for it, but it appears to have been a good move.

I exclusively have been writing in TypeScript for about 3 years now and it's crazy how good it actually is, especially for distributed teams in different time zones. The code is self-documenting and the number of silly mistakes being committed into our codebase has dramatically been reduced, combined with solid unit tests, we haven't really had a code level bug in what feels like months, browser bugs on the other hand...

My favourite thing about TS besides the types and interfaces is the compiler. I no longer have to use transpilers like Babel anymore because TypeScript handles compiling to many different module formats and targets. Back when I used Babel, it felt like pulling teeth because of the different plugins and packages you had to install and configure to use.

I find it really hard to use anything other than TypeScript now, it is simply too good.

I'd argue that porting from JS to TS is a very different beast than porting from Flow to TS.

I've ported code from JS to Flow and could say the benefits are similar to those of porting from JS to TS.

The most relevant part in this article IMHO is the conclusion:

> things like a strong community and availability of type definitions are more important because weak type inference can be solved by "handholding" the type checker a bit more.

I think it's important to highlight that this may be true of his project but not necessarily yours or mine.

Flow's type inference provides a much deeper level of confidence than TS with far less effort, for example, typing only the public interface of a module is often enough to surface type mismatch errors several functions deep within the module. In TS, you'd have to type every function signature to get the same level of confidence.

What worries me about flow is reflected in the comment from the facebook engineer linked from the article: it seems the flow team is focusing heavily on facebook-scale performance at the expense of most every other aspect of the project. A while back, the existential operator was quietly deprecated in the name of perf, and lately some updates have been of questionable soundness, e.g.

https://flow.org/try/#0GYVwdgxgLglg9mABAdxFAFAQwFyIPIBGAVgKb... (compared to http://www.typescriptlang.org/play/#src=function%20wut(a%3A%... )

> In TS, you'd have to type every function signature to get the same level of confidence.

I don't disagree, but isn't this the point? That by typing every function you can reliably have confidence in parameter types and return value types, and if your program is able to throw a type error on build, then it should and alert the developer that they're not logically correct in their implementation.

My point is mostly that you can get away with explicitly typing less things in flow and still get similar levels of coverage. For example, consider this example:

    export function formatTime(time: Date) {
      return digitize(time.getHours()) + ':' + digitize(time.getMinutes());
    }
    function digitize(n) {
      return ('0' + n.toStirng()).substring(-2);
    }

Just a single type declaration is enough to let Flow catch the typo here. In TS, you'd also have to write the argument types for `digitize`. Importantly, if you wanted to explicitly add arg types for `digitize` w/ Flow, your editor can tell you what they are supposed to be.

FLow seem to be better at inferring types. example:

    function foo(n) {
          return n*2;
    }
    
    foo("bar");

Object seem to be any object (any type) in both Flow and TypeScript, if you change it to string, both Flow and TypeScript will give an error.

> Even if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence.

TypeScript is, by far, my favorite type system. I love structural typing. I love conditional types (ReturnType<T>). I love things like `keyof T`. I love how good it's inference system is. I love how I can still use it in a JS file and still get type checking with JSDoc.

I tried out Dart over the holidays and it felt like a major step backwards. Seriously, hats off to the developers.

> if I have been writing code with Java / C# for nearly a decade , nothing has come close to Typescript in terms of productivity,flexibility and confidence

I can completely relate. To me the greatest thing is the tooling around it. Using tide[0] on even plain js codebase is just amazing.

I really wish ruby had a TypeRuby compiler (to regular ruby). I know about crystal, but I still want regular Ruby, just with a type checker at compile time, not runtime.

[0]: https://github.com/ananthakumaran/tide

> It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )

That’s only because of Microsoft fanboys nowadays, .NET core is a pleasure to use on Linux and AWS with a variety of databases etc

Yup, it's ridiculous cargo cultism from mediocre C# programmers. There's nothing about C# that forces you into MS's ecosystem.

In 2014, well before Microsoft's dotnetcore oss adventure, I ran the dev team at a startup. Our entire backend was C#. Our devs used the OS of their preference, and so we had Mac, Windows and Linux. Xamarin Studio is (was?) a remarkably decent IDE for something so niche.

We hosted it in Docker (bad call, it was way too new then) on Mono (great call, it Just Worked), on Linux. Data in Postgres. All of this was as easy as doing the same with eg JS or Java (and arguably easier than eg Ruby because C# has a proper cross platform dependency story).

There's nothing about C# that forces you to use SQL Server or Azure. Absolutely nothing.

If you did js->ts, that's not "exact same job", is it? He describes flow->ts and highlights differences between the two.

> It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )

This is very not true. For the past 2 years or so of using C# I never used MSSQL, Azure or even Windows.

> It's well know that if you start using C# , your entire stack will generally be MS based...(SQL Server, Azure etc... )

It may be "well know" but it's entirely untrue.

That's awesome! Did you convert from Flow or just plain JS? I think the experience is much different when converting from Flow vs converting from JS. When coming from pure JavaScript, you do indeed become much more confident and flexible around the code. When you come from Flow, the differences are much more subtle as I described in the article.

Yup. I will never start a new project in plain JS ever again.

To be fair, pure js with types as jsdoc comments that typescript handles just fine is a great way to write code.

No transpiration needed for node modules. No source maps, it’s same old plain JS that’s nicely checked by typescript.

I went from jQuery (inc libs) and < ES5, to VueJS (components) and ES6.

It was such a big jump, after 8 months of it now. I am so much more productive than I was before. It's just not funny.

If I did the same as you. Going from JS to TS, what kind of experience (from there on in) should I be looking at?

IMHO the largest difference is the amount of time you save hunting down stupid issues. e.g. no more spending 3 hours fixing a typo.

Also, code is much more manageable, and refactoring is tons easier.

With enough Babel plugins, you can get ESNext functionality that does whatever you want (some of those early stage proposals are really cool! They might go away tomorrow, but hey, so cool!), so Typescript's old advantage of offering more language features is kinda nullified.

In the end, I started writing the later part of my current project in Typescript, and I much more enjoy working on that part of the code than the earlier parts.

TS takes one day to get going, which is one of the best things about it.

Stick to the 'basics' of TS, which are super general programming syntax structures and idioms - there's really nothing new you'll come across (maybe unions?) - so it's easy.

Then you can try some of the trickier things but frankly we don't use them that much.

You'll be up and running pretty quickly because you can mix your 'new' TS modules with old-school JS code no problem.

And then go from there.

I like TS because it's not some big new fancy paradigm shift: it's just typing, some other pragmatic things, and it works pretty well, very quickly.

It's the only tech I will actively evangelize as being 'the thing you need if you use JS' type thing.

From my point of view, they have just great integration together, but but nothing really forces you to use them. Original post sounded like you are being forced into it.

The state of the industry sometimes deeply sadden me.

Creating a stack that complex just to render Static Content... Seriously ?

I'm fairly confident that only the author of this project can do something with the codebase.

It must be an absolute mess between Zeplin , Storybook , Apollo , GraphQL , Next, Yeoman etc...

Just why ?

Can't Airbnb invest in one good CMS and tooling solution ? Don't they have a CTO that define the company tech governance and tech stack ?

Isn't building landing page for "Luxury Destination" one of their core businesses ?

Do each Airbnb engineer create their own stack for a tiny part of the website ?

It just buggers me to see something like this and remind me of their 'React Native Fiasco' where they decided to use React Native but their mobile engineers didn't like JS , so the engineers of each platform just wrote the app using binding to use Java or Objective-C.

Sometimes I really tell myself that working for a FAANGS must be awesome, but then this type of content pops up and it just remind me I should either stay at my current job or create my own business to avoid all this.

I used to work at Airbnb.

Airbnb does not, in fact, have a CTO who dictates the company tech governance and/or stack. They prefer to run things in a federated manner, with individual teams making the decisions that they feel are best for them. While they're encouraged/required to draw up design docs and have them reviewed by an architecture review group, the group's recommendations are non-binding.

This model has advantages and disadvantages. On the upside, it creates an environment where people can take risks and do things that haven't been done inside of the company before. On the other hand, it means people sometimes go out on a limb and push the company into supporting something that turns out not to be sustainable in the long term.

As a matter of personal preference, I like to have a set toolchain that a company is built around. But it would be unwise to suggest that Airbnb's strategy hasn't worked out pretty well for them overall.

FWIW, I regularly use Airbnb for my travelling lodging needs. I usually find what I'm looking for (an apartment with washer, WiFi and many good reviews in the lower price-bracket).

But I always open the site with some apprehension, since I know I'm in for a bad user experience. It's sluggish, and I can't bring myself to appreciate how the layout and even menus differ (or even disappear) depending on which area on the site I visit. It makes navigation cumbersome, and hard to remember how to navigate between visits.

I would switch to a similar service in a jiffy if it had solved these problems.

I always suspected a lack of a top-down coordination to be the reason for these issues, thanks for confirming. I've come to believe that this kind of loose federation strategy mostly suits junior devs (on which a startup might be deeply dependent by all means), hardly a serious long haul business. I expect they will change policy in due course, or perish.

I've had the exact same problems using AirBnb. I can never rely on things to be in the same place one visit to the next, if they continue to exist at all.

I don't think AirBnb is alone in this. There are many sites and apps that change UI's radically with disturbing regularity. I've begun to wonder if there is a glut of UX/UI people in tech right now, and that this endless cycle of zero-value-added change is just an attempt to justify their continued employment.

I actually think the problem isn't a glut of designers or UXers, it's an obsession with A/B testing and multi-armed bandit scenarios. I'm sure that at any one time there are dozens of A/B tests running on the site, and the inconsistency we all see is a direct result. Netflix is a similar offender in this area, I never have any idea where "continue watching" is going to be when I open up the app.

I think AirBnb's strategy has worked out well for them for reasons completely unrelated to any of their technology choices. We're living in a time of cheap airfare, insanely inflated real estate in popular markets, and overburdened local governments unable to enforce regulations. That adds up to great success for Airbnb, regardless of what software runs their website.

I think this is an underappreciated point. It's tempting to believe that every tech company succeeded because of the tech, but what if Airbnb succeeded because of aggressive advertising and incentives, financed by hundreds of millions of dollars in VC funding?

I don't even think most of these supposed "tech" companies are actually tech companies: Uber is a cab company, Airbnb is a holiday lettings company, WeWork is a commercial real estate company. None of them makes their money by building and/or selling software.

They're serving inventory that can almost entirely be described in static content caching layers with a booking system layer.

How many risks and how much necessity to do things no one has done before can there really be?

I disagree. I think you're thinking primarily of AirBnB's main listing pages.

What about recommendations? What about map or multi-constraint search? What about fraud detection/prevention, activation/reactivation email triggers, an analysis system to help hosts be more financially successful on the platform, building an ecosystem of services where people can make money while helping hosts make money, SEM optimization, the ratings/reviews system, the communications between guests and hosts or guests and support, or 20 other things that are likely going on under the covers? Their mostly static content is likely just the visible tip of the iceberg.

I saw a javascript course the other day that claimed it would teach how to "build a full AirBnB clone in this course". I chuckled.

This is the correct answer. When you search for listings in Airbnb what comes back is heavily personalized.

Of course, that only accounts for one of the various pages you'll see in the checkout flow, and I agree that not everything is as snappy as it could be. But keeping things snappy turns out to be a very hard problem when you're growing as quickly as Airbnb has.

I have the same feeling, it seems overly complicated and I pity the developers that join the project at a later stage.

I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

Zeplin works quite well for our team and creates a nice connection to our designers. Storybook on the other hand not so much. At first we developers used it, then we had to update some things for Apollo but Storybook was not ready for that. Now everything runs again but nobody uses Storybook actively anymore...

I have the feeling that the software industry is often driven by personal preference instead of sane decisions. I see projects that use micro services without any reason, using React for static content, dockerizing everything to a ridiculous amount, K8s because why not. All of that because it's interesting for the developer not because it's good for the user.

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website?

Exactly. Forced to use GraphQL at work for an internal-only API and what a nightmare - what would be a nice, one-line REST API query can take hundreds of lines (not exaggerating).

If you're serving a public-facing API at massive scale, yes, GraphQL will save you bandwidth. If not, what a pain in the *. For most engineers it's a solution in search of a problem.

> I don't understand the run for GraphQL everywhere, does everybody query sparse and deep nested data on their website? From my experience, Apollo works well except when it doesn't and then you have a lot of magic going on.

I work primarily as a FE software engineer who spends a lot of time researching, using the JS ecosystem. I have gone through graphQL/apollo docs multiple times in order to really understand the value add. Fetching/bandwidth/caching/persistence appear to be the biggest value adds for the tech. To me, these are the easiest things to do in a react/redux SPA. Fetching data isn't difficult, it's all the derived state data that is the hard part. Most of the "business" logic for me is formatting the data in a way that makes sense for whatever UI component I'm building, combining multiple streams of data for the UI, when to refresh data, optimistic UI, and offline support. To me the "declarative fetching" is not really that much a sell to me, because that piece of many projects of even intermediate size is relatively small.

I realize that apollo is trying to solve some of the optimistic UI, offline support, but it does not seem to fit super well atm. The other really big issue I have with apollo is like you stated: it's easy until you want to do something that it can't do. This is the worst position to be in because for 80% of the use-cases it works, but that other 20% where it doesn't fit at all can make a team's life a living hell.

Not to mention most of the time, for any large enough SPA, you will still need redux. If I still need redux then apollo solves nothing for me.

Most of the stuff that you need Redux for you should be able to handle with @client [1], and the local "resolvers" approach isn't too different from Redux reducers, to the point that wrapping Redux-style reducers as Apollo resolvers seems like it should be boring/trivial to implement. It would probably be cool to have something of a "standard library" for that which let you easily convert Redux-style reducers directly (ie, a sort of combineReducers that spits out local resolvers). I don't think it should be hard to do, just doesn't look like anyone has done it yet.

Of course the bigger issue, though, is the Redux Dev Tools/Thunks/Sagas/Observables ecosystem where you want a richer experience and/or already have existing code investments. Apollo has some equivalents to those (Apollo Dev Tools; resolvers can return promises, taking care of a lot of basic thunks/sagas), but it probably needs richer options for others. I know redux-observable is currently a big need for several of my applications and I don't currently know any way to approach that in Apollo other than maybe trying my luck with a custom "Link" and that API looks more intimidating than it probably is, enough so that I haven't had the investment need to approach it. (Then again, most of my applications need to be offline-first so GraphQL in general isn't a great fit for them, though Apollo looks like options might be possible eventually, if someone built a little more infrastructure [Links] for them.)

[1] https://www.apollographql.com/docs/tutorial/local-state.html

I can empathize with an organization interested in motivating its employees over the long term. SPAs, GraphQL, and these other non-essentials are intrinsically rewarding. They give the creators a sense of agency. This motivates people to give their work their best effort. From AirBnB perspective, as long as the value created by these projects doesn't exceed their costs (a quasi-NPV), why not continue them?

The next chapter of intrinsically rewarding work will involve simplifying the complex. Trimming the fat. Reinventing the Zen of Python. Most importantly, it will be glorious.

>Do each Airbnb engineer create their own stack for a tiny part of the website ?

I don't work at Airbnb but I am the CEO of another startup. Our main website (https://rainway.com/) used three different technologies to build it. Why? Because it streamlined development. One team could focus on the code powering the blog, while another could write static pages that query an API. The build process brings it all together.

Tool such as Figma (we moved from Zeplin) do an amazing job for designing entire user interfaces and interactions and providing developers with all the needed materials to implement them. If you're building a homepage for a mom and pop shop, download WordPress. If you need to build something across multiple teams, you need tools to make it easier.

> used three different technologies to build it

Would love to know more about that because looking at your website it's just plain HTML with JQuery.

Which ,in my opinion , is how you should be building landing pages.

I agree with this notion. However, it is concerning that jQuery hasn't had a release in 12 months:

https://github.com/jquery/jquery/releases

You failed to notice that they committed less than a month ago to their master branch and approved several PRs.

Their last dotX release was also 9 months after.

You should also always have a look at roadmap (https://github.com/jquery/jquery/wiki/Roadmap) if you are trying to get a read on any project's longevity.

It is in a way a good thing that a mature library like jQuery isn't released too frequently because all the websites that use it works just a little bit snappier because jQuery is usually already available in cache in the browser from some other source and if not, then the nearest CDN probably has it.

On the jQuery website, the latest download version is 3.3.1.

http://jquery.com/

On GitHub, it says that 3.3.1 was released January 20th, 2018:

https://github.com/jquery/jquery/releases

Releases matter, as that is what gets the changes to end-users, and infrequent releases typically indicate a stagnant project.

I am not trying to disparage jQuery, rather the opposite, since it is mature and reliable software. Open-source projects, like houseplants, need stewardship, and jQuery (along with other JS Foundation projects) may be overshadowed by JavaScript ecosystem hype-cycles that are competing for mind-share.

At this point, jQuery is more or less considered 'conpleted' software. It's very mature, and works well.

Why??? jQuery is so old, I expect it to be “done”

As stated above, open-source projects need stewardship. Otherwise they languish. I genuinely hope for jQuery to continue as a project and community endeavor.

So Conway's Law then?

Exactly my thoughts after the design in Zeplin got presented. If your goal is to create this landing page, do you need much more than HTML & CSS and some sort of static site generator / CMS?

As an Airbnb host, I find managing my property with their website to be a nightmare. It takes three times as long to load as it should and three times as long to do find anything or make changes as it should. The sections are not logically arranged for usability and the whole thing would be vastly improved by consulting with the Nielsen Norman group [whom I have no connection with].

> Creating a stack that complex just to render Static Conten

What exactly is Static Content and are you implying AirBnB has it?

Does its mobile app also have Static Content.

> It is highly opinionated unlike React

Agree on that point , I like Angular because it's opinionated compared to React.

> and backed by a giant unlike Vue

Strongly disagree , Vue is backed by many large corporations and unlike AngularJS was designed to guarantee backward compatibility.

AngularJS not being compatible with Angular is what has killed for good the frameworks and left thousands of entreprises in dust when they believed angular would become a standard because "it's backed by a giant".

Workings for banking sector , I've many customers build CRM or KYC applications on top of Nuxt. Developers love the Vue ecosystem.

> Seems like a safer enterprise choice.

Strongly disagree here as well.

Angular is a great framework but it has absolutely unacceptable build size,

A "Hello World" using Angular 7 with Ivy Rendering is 500KB+ ( tested this morning ). This is not acceptable for modern frameworks to be that big.

Vue and React stay largely under 100KB in terms of build size.

They are lots of scenarios where picking Angular over Vue & React would made things more complex for a project.

Angular is notorious for breaking compatibility. They're constantly redesigning and breaking the API of random components.

The best parts about Angular are; the dependency injection system and the opinionated component templates.

I strongly disagree with the hypothesis raised in the article.

First , most open source companies these days are Ventured Back ( Elastic , CockroachDB, MongoDB etc..) meaning the core of the issue isn't "AWS" not paying license fees or people creating tech on top of Open Source , it's VCs who want their money back times ten.

Companies like MongoDB/Elastic have raised hundred of millions and yet are still not profitable.

Who's fault is it ? Did the MongoDB community ever asked the company to go that way ? Did MongoDB presented a roadmap to the community saying that they would have to be "profitable by Month X" or they would change their licence to make more money ?

Nobody has forced those founders/companies hands to make their products open source nor to raise that much capital.

If the industry is turning that way it is essentially because those businesses have used Open Source as a mean to reach the widest possible audience in order to increase growth and show great metrics to VCs and investors to raise absolutely obscene amount of cash.

Vue.js and Laravel are two very well maintain and extremely profitable open source project.

Those projects did not asked for 150M$ in fundraising and then realized : "Ooops we won't meet our 100% YoY Growth to satisfy VCs promises".

If some companies are switching their licensing , it's mostly because they overestimated their technology value and can't show to investors the numbers they promised.

This isn't due the "AWS Problem" or because of a "wrong business model" with FOSS.

VCs don't care about profits anymore. Their bet is on getting hockey stick growth using tricks good enough not to spook the uneducated retail investor (that often involves selling dollars for cents) and then dumping the hot potato into the public market.

It isn't long-term sustainable and it will result in a major correction one day, but that's the game currently.

That most of the VCs care is making attractive the company between their investment and their exit, it is completely true.

That is also why quite often they bring in (and sometimes replace founders with) "professional" executives before the IPO. Some of these people are not usually the best people to maximize the long term trajectory of the company but they bring more confidence to IPO investors.

If you want to have a successful relationship with them, you had better know their motives and timelines and make sure your company is one in the fund that looks is going to return enough for their game.

I find it funny how the ethical side of those games is always conveniently ignored...

Ethics reduce profit, thus they are ignored when there is no regulator or law enforcing them.

Capitalism does lend itself well to technical innovation, which is beautiful but not ethical. And with that beauty comes technical debt in it’s cultural form: decadence.

The societal accomplishments of capitalism are effectively distraction and insulation from the side effects of complexity.

Is it really unspoken? I mean VCs aren't going to advertise it, but I thought this was common knowledge.

Fun anecdote I heard from a very seasoned VC. He mentioned a trick VC funds use is to raise capital, then spend that fund before any of the companies can make a return (this varies from fund to fund, but imagine anywhere from 2-10 years, usually centering around 5-7). They then go back to their LPs saying "look how good our portfolio is doing, we just need more money to help them out!" without any truly meaningful metrics such as profitability, and essentially keep the house of cards afloat like this by cyclically raising capital before funds can show an ROI.

Also most VCs lose money, but nobody (by which I mean LPs) ever seem to care about that because they're excited about the potential without understanding the risk of the market.

It's worth noting that between 2012-2017 'open source' and 'enterprise software' were synonymous. I saw many examples where VCs refused to entertain any enterprise investments that weren't fully SaaS and/or on-prem apache licensed.

Explains why there was so much marketing hype behind open source; hundreds of millions of dollars of VC investment was being pushed into it.

" it's VCs who want their money back times ten"

Keep in mind that this is the market speaking, not a 'specific need of some group'.

If it costs money to productize and support something, and it's risky, it's going to be VC and there will be terms that take that risk into account.

Another way of saying it is that '10x' requirement is a function of the risk of the business model of those taking the money. (Which by the way, as you point out, might involved 'over estimating the worth of something)

Most VC's are not successful and even the 'obscene' amounts of money made by some actually don't make up for losses elsewhere. [1]

Also, it's a very risky proposition for most folks to do a 'true' open source project and as you say make it 'profitable' via sponsorships or whatever.

" it's VCs who want their money back times ten"

Keep in mind that this is the market speaking, not a 'specific need of some group'.

If it costs money to productize and support something, and it's risky, it's going to be VC and there will be terms that take that risk into account.

Another way of saying it is that '10x' requirement is a function of the business model of those taking the money. (Which by the way, as you point out, might involved 'over estimating the worth of something)

Most VC's are not successful and even the 'obscene' amounts of money made by some actually don't make up for losses elsewhere. [1]

Also, it's a very risky proposition for most folks to do a 'true' open source project and as you say make it 'profitable' via sponsorships or whatever.

[1] https://techcrunch.com/2017/06/01/the-meeting-that-showed-me...

> Keep in mind that this is the market speaking, not a 'specific need of some group'.

I wonder sometimes, though, which market is being served.

I think in some ways, it is actually the VC market itself that is being served, not the customers of the company the VCs are investing in.

There is so much VC money floating around, and they are 'in the market' for investments to make with that money. The problem is sometimes there just isn't a downstream market that needs to be served by a company funded with all that money, so the VC needs to try to find one. And they often times reach pretty far to find that investment opportunity, and try to force a downstream market where there is none.

There might not BE any market for the 'productized and supported' version of the open source project that a VC wants to fund, but since they have so much money they decide to try to force it to fit that model. They put a ton of money in, grow the company, and then are forced to monetize to support that big of a company.

Maybe the community was being served just fine without that much investment, but now that the investment has happened, the company is forced to act in ways that AREN'T serving that community.

For every open sourced that is used, there definitely is at least some need for a slightly better version of it. The question is, at what price?

So if VC wants to over-fund products and basically give away development and services, it's not all that bad.

I'd rather see more Engineers employed and learning than less.

Open source is not for VCs. VCs aren't good when it comes to creating value. The VC's job is to capitalize on hype. Hype doesn't go well with open source projects; it leads to dissillusioned customers later.

Wow , is .NET that popular in startups ?

I always assumed it was used heavily in enterprise but never that much it's would somehow , it's also a popular stack in the Silicon Valley and NY. That said London and UK are well know to be MS Stack users.

Can some Engineers from SF or NY or voice their opinions on this ?

When you look at the job postings in your browser, and do a simple string search for ".net" (so not a regex search), it doesn't show up all that often. E.g. if I look at this month's posts (4 pages), I see it 31 times. By contrast, Python shows up 251 times. I suspect the posts were searched with a regex like /.net/i without escaping the ".".

The answer is less deep than that. Hacker News is now regularly used as a recruiting tool. It may be that bigger companies are now also posting every month. .NET has come a long way though and I have a friend who is using it at his place, but from anecdotal evidence I see a lot more Python and JavaScript than anything.

> Document Layer has a familiar API, and is compatible with the MongoDB® protocol

Was wondering how I would replace MongoDB due to the shift in Licensing become more and more agressive.

Well , I think I found it.

Farewell MongoDB.

It's like hard slap straight in the face. They changed license because they perceived that multibilion giant(s) feasts and earn money upon their work and gives back not that much. In return giant just slaps

I’ll never understand why we collectively wag our fingers at individuals or companies that try to keep the likes of Amazon from building a profitable service off of their hard work then contribute back little-to-nothing. Would redis, mongodb and dgraph have even considered alternate licensing if companies like Amazon had thrown them a minuscule amount of funding and patches? We can’t know because they didn’t. And then we sneer at them for having the audacity to try to stay open but stop these giants from using them and throwing them away.

3.0 is a huge milestone for vue.

Currently the architecture forces you to import the Vue object entirely , has Vue under the hood isn't really modular...

With 3.0 Vue has taken the typescript way and is using packages , similar to angular , it looks absolutely awesome to work with now.

I really hope class based components will be supported natively without compiling or transpiling.

Working "out of the box" has always been part of Vue philosophy , I really hope this continue.

This is really a big release , but it's still sad to see the 3.0-alpha branch is not visible on GitHub , i really would have loved to have a look at it.

Vue 3.0 is reported to support class-baed components natively: https://medium.com/the-vue-point/plans-for-the-next-iteratio...

Google is really pushing Hard on PWA.

My biggest concern is the support outside of chrome.

While other browsers tend to come on pair with chrome in terms of features , chrome right now is the only one which supports PWA as "native" app..

Windows announced support for PWA natively a while ago [0] but there has been no news since then.

On Apple side it's silence radio...iOS have some support but for Mac it seems unlikely to happen...

[0]https://blogs.windows.com/msedgedev/2018/02/06/welcoming-pro...

The funny/sad thing about PWA and how broken it's on iOS right now, is that the first iPhone was supposed to work with PWA. I'm not sure if it was Jobs' vision or they didn't have something good to offer for native devs. Safari has been a joke for long time now.

That was before they started printing money from the App Store.

> Windows announced support for PWA natively a while ago [0] but there has been no news since then.

There have been news since February.

UWP hosted apps got replaced with PWAs, including access to UWP APIs if signed, documentation and tooling support is now available.

https://developer.microsoft.com/en-us/windows/pwa

https://docs.microsoft.com/en-us/microsoft-edge/progressive-...

This is what made me have another look at PWAs, start experimenting with them and starting to see, that for plain CRUD applications PWAs are probably the way to go.

FWIW, the official Twitter desktop app for Windows 10 is a PWA and it works great (well, as well as any official Twitter app has worked in my assessment; not as well as third-party apps from their hey-day, but that's a different story).

I also use the Starbucks PWA (app.starbucks.com) and it mostly works well. Again, it seems to work as well as their native apps.

PWA is "Progressive Web Applications".

https://en.wikipedia.org/wiki/Progressive_web_applications

> chrome right now is the only one which supports PWA as "native" app..

What do you mean with "'native' app" exactly? When I use my PWA with a Firefox on Android I can't see that it is a PWA. It just looks like any other Andoird app.

Granted that is only one more browser and on the desktop side Firefox still has a lot to do, but at least there is one more player in the race ;-)

A couple months ago I started studying PWA.

I realized PWA's potential was on Desktop and not really on mobile.

I came to realize that PWA missed really two things to change Desktop for good :

- Sandboxed FileSystem API

- Standard Operating System Support

Most apps like Slack, Discord or Twitch can barely justify their usage of Electron... beside the possibility to have those apps in a separate OS Window they don't make an extensive usage of Node.JS like VSCode which spawn "child_process".

They just seat there , in a separate OS Window and they can launch at OS startup too..but in order to have those two features you must completely give up on security and give access to almost everything on your computer...

PWA really bring a new dimension to Desktop App, if Windows and MacOS brought native support to PWA ( using Edge and Safari without the need for Chrome ) this would change the industry for ever.

Problem with PWA: Native access, Browser versioning and seperation of processes.

1. If when you ran a .net application all .net applications shared the same parent process that'd be a significant problem.

2. Many electron clients control their versions because there are bugs, quirks, removal of features, or other changes in chromium versions. Discord last time I checked is still on 56.

3. PWA's do not have native access. Discord requires that to spawn IPC communications with game overalys, which are another native process.

PWA's are meant more for mobile, but even there you are of course, limited.

Firefox and Safari would change the world if they actually cared about doing that. They're about market share, not about the technology anymore. Firefox was in a position of making it possible to simply ship the firefox binary, and you could add your js and css changes, effectively having the full firefox browser as your 'app'. Which means it could be triggered to auto-update like normal firefox, but still have your UI and act as a browser.

Firefox abandoned that route and instead is focusing upon whatever Chrome impliments, like Custom Components. Safari also doesn't care about anything but linux and mac.

Safari... cares about Linux?

Maybe they meant WebKit?

Agree that PWAs have a lot of potential on Desktop. But they're also really good on mobile. Both Facebook and Tinder have PWAs that I prefer to their native apps...