lostintangent

Correct! We designed LSIF to be a complement to LSP. LSIF is basically a way to persist language server state, so that LSP queries (e.g. what are the definitions for this symbol?) can be answered without needing an active LSP server running.

Among other things, LSIF enables rich IDE navigations on remote codebases, where’s its much more scalable to perform those queries using indexed data vs. spinning up language servers. Here’s the blog post where we first announced the work we were doing, that led to the creation of LSIF: https://code.visualstudio.com/blogs/2018/12/04/rich-navigati....

Hey! I definitely remember you :) It’s always satisfying to run into the same folks across different projects, over the course of multiple years.

I’m glad to hear the examples worked out of the box! We’ve been iterating on the docs and API quite a bit (based on feedback), so don’t hesitate to let us know if/how they can be improved: https://github.com/microsoft/playwright.

Low/no-code authoring is definitely something we’re interested to explore. Once we’ve solidified the core Playwright library, we plan to build (and collaborate with the community on) tools that can simplify automation tasks even further, on top of a modern, reliable and performant core.

Are you currently using Kantu? If so, I’d love to hear more about your specific use cases, and which capabilities you’d be interested to see. Thanks!

Playwright allows you to connect to existing browser instances, but it currently requires you to get the “debug URL” of the browser instance first: https://github.com/microsoft/playwright/blob/v0.11.1/docs/ap....

I’d love to hear a bit more about the scenario you have in mind, since that might help inform some improvements we can make. Thanks!

Out of curiosity: why does the fact that Playwright is a Microsoft-sponsored OSS project discourage your interest?

The team is working very hard to be open/transparent/available (https://github.com/microsoft/playwright), and we’re very excited to build a better automation stack with the help of the community. I only ask since I’d love to hear any feedback for how we could improve the way we run/position the project. Thanks!

As part of our goal to enable better developer ergonomics, we’re very keen to explore “better”/higher-level APIs and additional extensibility points. For example, we allow you to define custom “selector engines” (https://github.com/microsoft/playwright/blob/master/docs/sel...), which is just one example of the kinds of customizations we want to enable.

Out of curiosity: are there any specific extensions from puppeteer-extra that you’ve used and/or would be interested to see?

Great! Let us know if you end up having any questions/comments/feedback: https://github.com/microsoft/playwright.

Desktop support is definitely on our long-term roadmap! We’re simply starting web, since it’s an area we think we can make big improvements to, before moving on to the broader developer landscape.

As we build out Playwright, we hope to learn a lot about how to make automation more reliable, ergonomic, and enjoyable for developers. Ideally, we could then apply those principles/learnings to desktop, mobile, etc. automation too. Stay tuned!

Awesome! Please don’t hesitate to let us know how we can improve. We want to make web automation not only more reliable, but also more enjoyable. So we’re keen to hear how we can continue to push that goal forward :)

https://github.com/microsoft/playwright

Each of the page operations (e.g. click) automatically wait for the specified element to become visible before being performed. That way, your automation code is declarative about what you want to do, and to what element(s), and you can allow the Playwright framework to handle any “waits” on your behalf (without having to rely on time as a pseudo event).

To make the act of selecting elements more resilient to change, Playwright also supports a collection of “selector engines” that allow you to choose the best strategy for selecting elements (via CSS selector, xpath, text content). Additionally, you can author entirely custom selector engines, and compose them together with the built-in types. This is still somewhat experimental, but we think this can enable another level of robustness to test automation: https://github.com/microsoft/playwright/blob/master/docs/sel....

Finally, in addition to waiting for element visibility, Playwright allows you to wait for specific page events to occur (e.g. network request work made). This enables your code to leverage deterministic “signals”, not timeouts (which are the source of a lot of flakiness!). Overall, we want it to be possible to author automation that is entirely event-driven, and includes zero arbitrary timeouts.

Playwright is a new alternative to Selenium, and besides being cross-browser, is focused on performance, developer ergonomics and reliability (death to flakiness!). Might be worth checking out? https://github.com/microsoft/playwright.

Disclaimer: I work with the Playwright team at Microsoft.

Yep! You can run the “GistPad: New Secret Gist” command, or right-click the “Your Gists” node in the Gists Explorer and select “New Secret Gist”. Let me know how that works for you!

“Secret” is the term that GitHub uses (as compared to a private repo), which is why I call them that.

If you’re using VS Code, you can checkout GistPad, which allows managing code snippets, mini-docs, and interactive/CodePen-like playgrounds, all backed by GitHub Gists: https://aka.ms/GistPad.

Disclaimer: I built GistPad, and am just mentioning it since you mentioned GitHub-based snippets.

Thanks! Let me know if you get a chance to check it out, and have any feedback (https://github.com/vsls-contrib/gistpad). I’m iterating on it pretty quickly, and am looking for more input about other developer’s use cases

If you’re interested, I built a snippet manager for VS Code that uses GitHub Gists for persistence. That way, you get a productive, in-editor experience, while still being able to keep your own data/code, and can benefit from the existing ecosystem and primitives that have been built around gists (e.g. embedding gists into Dev.to/Medium blog posts, opening a Gist-based Jupyter notebook in NbViewer).

It’s called GistPad, and in addition to allowing you to create/manage code snippets, it supports easily moving files between your local machine and gists, pasting images, starring/forking gists, viewing and replying to comment threads, and creating “playgrounds” that are CodePen-like runnable samples: https://aka.ms/gistpad.

Additionally, since it’s a VS Code extension, you can easily edit/manage your snippets, while taking advantage of your existing editor setup/language support, using your favorite extensions, arranging files into arbitrary grid configurations, etc.

Yes to #1 and #2.

For #3, we’ll be adding a “Basic” SKU soon, that includes 2 cores and 4 GB RAM. Would that be sufficient for your use cases? You can track the progress of this enhancement here: https://github.com/MicrosoftDocs/vsonline/issues/54.

#4: Thanks for the feedback! I’ll look into improving that text this week.

#5: Yep! You can track the progress of this enhancement here: https://github.com/MicrosoftDocs/vsonline/issues/192.

Correct. Though we’d love to hear feedback on this experience.

Your extension should “just work”. And yes, we have a self-hosted environment solution that you can use to test out your extension in the web, and it’s entirely free: https://aka.ms/vso-docs/vscode/self-hosted.

While we released the public preview of the VS Code and web based clients, we also released a private preview of the VS client, which is actually fully optimized to support C#/C++ development. If you’re interested in giving it a try, sign up and we’ll get in touch with you soon!

https://visualstudio.microsoft.com/services/visual-studio-on...

Yep! Check out this doc and let us know if you have any questions/feedback: https://aka.ms/vso-docs/vscode/self-hosted.

Thanks for the feedback! We definitely want to make onboarding to a GitHub repo as simple as possible. This is something we’ll be looking to gather feedback on from the community, so stay tuned as we iterate rapidly in the coming months.

Thanks for the feedback! Docker Compose support is on our roadmap, and you can track progress of it here: https://github.com/MicrosoftDocs/vsonline/issues/35. If you could upvote that issue, that would be much appreciated!

Just emailed you!

That’s totally fair. Over time, our goal is to expand the platforms and application types we support (we’re currently focused on web/APIs), because we believe value props remain the same, regardless if you’re doing desktop, mobile, data science, etc.

That said, we can definitely make sure to be clearer about where we’re at in our journey towards enabling this promise more broadly. Apologies for the confusion!

In the meantime, we also allow registering your own machines with the service, since we’ll never be able to provide all of the customized environments that devs need. With this “self-hosted environment”, you can benefit from the remote tooling experience (including the web editor), with your own compute. I’d love to hear if this would be helpful for you and your specific workloads.

Agreed! The on-demand dev environments are the real star here. Whether you use the web editor is up to you, since we also support working from your existing VS Code desktop setup as well. That said, we’ve found that having the option of a full-fidelity web editor, that’s fully interopable with VS Code desktop, can provide valuable flexibility for many use cases (e.g. making a quick edit when out of the office, doing a “rich” PR review in the browser).

This is absolutely a problem we hope to solve :) We’ll be adding “official” support for Safari on iPad soon, so stay tuned, and please don’t hesitate to reach out to let us know any feedback/questions you may have.

https://github.com/MicrosoftDocs/vsonline/issues/33

Safari on iPad is a critical scenario for us, however, it isn’t currently “officially” supported. Yet! Stay tuned to this GitHub issue, where we’ll provide updates on this very soon: https://github.com/MicrosoftDocs/vsonline/issues/33.

Regarding requirements, you could absolutely run the web editor from a Chromebook! Being able to utilize low-powered devices, while using real-world dev tools, is something we’re excited to enable with this service.

Yep! This is high-pri on our roadmap. You can track progress on this GitHub issue, while we try to iterate rapidly during the public preview: https://github.com/MicrosoftDocs/vsonline/issues/34.

Yep! This is a high-priority, and you can keep track of progress on this GitHub issue: https://github.com/MicrosoftDocs/vsonline/issues/34.

Interestingly enough, many people thought the original VSO was an online web IDE. And so in this case, we decided that it made sense to re-purpose the brand for a product that met many people’s expectations. Visual Studio Online: This time, it’s for real!