One take away for me was: Language designers & compiler writers today need to consider editor support as one of their goals.
On the top page there's another thread about rust-analyzer vs RLS. What Aleksey said[0] about RLS that "[RLS's] current architecture is not a good foundation for a perfect IDE long-term," feels similar to my coworker's conclusion in her effort to provide better editor support for PHP[1].
Parsers for compiling code into machine-executables vs parsers to serve LSP responses have different tradeoffs. For example, Anders mentioned TS parser need to have good error-recovery, can respond with completions/errors when one file changes inside a thousand-files-project. I vaguely remember TS had a goal to provide completions in < 50ms and errors in <150ms. Such goals are hard to achieve as after-thought. If your core compiler doesn't do error recovery, such as PHP, you need someone to write a new compiler from scratch for a language server implementation. If tools such as RLS rely on compiler to dump all JSON metadata and figure out LSP responses[0], it's too slow for editors.
TS's good editor support doesn't come free. I think one of the most under-appreciated achievement of TS is how it took editor support seriously and designed its compiler infrastructure to do it well. That's why I don't believe in those hot-new-web-languages that try to take over TS by designing a better type system. TS brought the average developer's expectation of a language to having fast completion, fast error reporting, editor autofix, F2 to rename and renaming-a-file-in-editor-to-update-all-references. It's 2020 and people aren't going back to write code like in Notepad.
> Let's start with something simple, like syntax highlighting.
I built a syntax highlighter, Shiki, that allows you to use any theme from VS Code to color your code [0]. It works great with Node now as a static website generator plugin, but with some effort you can run it all in client side as well. TypeScript's new handbook is using Shiki [1].
I can't really believe how it's 2019 and Medium and Slack still can't syntax highlight code snippets.
> Obviously with log parsing you don’t get as much information as a JavaScript-heavy, Google Analytics-style system. There’s no screen sizes, no time-on-page metrics, etc. But that’s okay for me!
This also bypasses Ad blocker. In the case you have a large percentage of technical audience (who presumably would have Ad blocker installed) this log can be way more accurate than GA.
However this still requires setting up the image on a third-party server. I would really love it if GitHub pages or Netlify can provide some simple server-side tracking. It doesn't match GA but in some cases that's all I need.
> I would really love it if GitHub pages or Netlify can provide some simple server-side tracking. It doesn't match GA but in some cases that's all I need.
They already owned an analytics service for a while but it changed owners recently. Still looks almost the same though https://get.gaug.es/ - so I guess they decided it’s not part of their core business.
> I would really love it if GitHub pages or Netlify can provide some simple server-side tracking. It doesn't match GA but in some cases that's all I need.
Cloudflare does this for free, and you can run it on top of Netlify, Github/Gitlab pages, etc.
I don't think Cloudflare's info is very helpful, at least in the free/cheap plans. It can help to roughly identify where your visitors come from and how many visits are from bots but that's about it.
> However this still requires setting up the image on a third-party server.
While this is true, we found a solution to bypass ad blockers (which could be implemented by Google Analytics as well). My experience is that ad blockers only block scripts and pixels that are implemented on multiple websites [1]. With having a custom domain and a non analytics named script or URL, ad blockers are unlikely to block you. At Simple Analytics we created a feature for this where customers can point a CNAME to our server [2]. We setup SSL and proxy all requests to our server. This makes it almost impossible for ad blockers to block the stats of those customers.
Well, here are two things that have been brought up many times:
1. Required fields on new issues. Has been requested since 2016[0].
2. Better issue search.
Open Source projects face a lot of issues. It's good to talk about them, but some GitHub can solve some GitHub can't. I'd be much happier to see these problem addressed instead of learning about updating my profile status[1].
Currently when a project becomes popular the issues easily drown the author. As the communication portal between OSS authors and users, GitHub can and should give OSS authors more power.
If someone is filing an issue to an open source project -- whose maintainer will very often be working on said issue for free -- the least that person can do is submit the issue with the information that the maintainer requests.
I really like this idea if for no other reason that it would raise the bar for submitting an issue. So many open source maintainers on Github are overwhelmed with vague issues or support requests masquerading as issues.
Issue templates already exist. As I've seen recently the possibility for multiple issue templates (that also auto-apply some labels) even exists now. If an issue doesn't fall into any of those templates, they are still free to close the issue and ask for it to be resubmitted with the correct information.
There are some projects that are fine with having support requests on the Issue tracker, and some that have another system for that. At the very least, it may highlight missing documentation.
That is unlikely to improve matters IMO. If people are forced to populate a box they were otherwise going to ignore they'll populate it with repeated detail from elsewhere, a single character if no minimums are imposed, or keyboard mashing gibberish, not the sort of detail you are asking for.
Many people are just incapable of, or unwilling to spend the time to, produce useful bug reports and feature requests. They expect you to be clairvoyant, or be willing to go back and forth re-asking the same questions until you have the information you need.
In DayJob we have commercial clients who are supposed to perform their own first-line support and triage issues before sending them to us (their procurement people expect a per-user price reduction because they claim to do this), yet we still always have a collection of issues on-hold awaiting information because the report essentially said nothing more detailed than "a user says that they did something and there was an error message" with the required detail fields containing something along the lines of "see title". Bad reports end up costing them in various ways and they still can't be bothered to raise them correctly. (Heck, sometimes internal work items & bug reports raised by other devs/BAs/management can be just as bad but at least I'm allowed to be sarcastic in response to those!) I wouldn't expect the general public filing a reports/requests in a project on GitHub to average any better.
I like everything about Observable but the editing experience. In 2018 no one wants to write code like writing txt files.
Is there any plan to adopt Language Server Protocol so at least users could get auto completions? But with the custom syntaxes to JS I guess Observable can't just use plain TypeScript Language Server.
Hey there - have you tried hitting Tab while editing code? We've implemented dynamic code completion that works in a surprising number of cases where no other completion can work - for example, completing properties of API responses, based on the real values in the environment.
But, of course we have a long way to go, especially relative to the VSCode/TypeScript ecosystem.
I hope GitHub could add some features to help Open Source maintainers. Allow adding contributors with issue triaging privileges is an obvious one. Required fields (link to repro, software version) could be really helpful too.
Currently people have to work around these issues in awkward ways, like creating a whole organization just to grant issue triaging privileges or redirecting people off GitHub for filing issues with required fields [0]. Those workarounds run into limits quickly.
I have long had chats with Hubbers over the years about the privilege thing, and one of the hardest parts is the UI challenge. That is, you can do this, but can you do it in a way that's not maddeningly complex? It's unclear.
I'm not sure what's complex. Adding one more option "Triaging" here[0] doesn't seem complex.
I'm working at VS Code and now we are trying to make a bot that would add a label if someone (from a whitelist) types `/label bug` (same for marking duplicates). The fact that we have to go this far for letting community contributors assign labels to issues is more maddening to me.
Sure, if the perm is solely "traige issues", maybe that's fine, but what is the exact level of granularity for this kind of thing?
I don't mean it's impossible, just that it's not completely simple, and there's work to do to sort out the details. I also have never seen what dotcom looks like, so I have no idea how hard these things are to implement, either. Sometimes simple features can be rough to implement, especially in large, legacy Rails apps...
Now when I see any new product I look for a pledge to not get acquired like PostHaven[0]. Otherwise I simply refuse to use it. Sparrow, Mailbox, Inbox...Have been burnt too many times.
Have to do some clarification here on the point of "Unclear architectural patterns", as the article is way too misleading.
- The reason the API call is made at `created` lifecycle is that the video is a quick, 5 minute intro for beginners. Beginners, as in "people who are familiar building static websites using html/css/js". There is no need to bring in Vuex or vue-router yet. In fact the whole beginner example can be put into a single HTML file by including a Vue script tag. The approachability is what made Vue shine. Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.
> To answer to my initial question: API logic should not be written in Vuex nor in components. There is even a good example on how do that in some of the official code examples.
- The example[0] clearly has the API logic in the Actions. The `/api` folder is a mocked API for illustration purpose.
>Some other frameworks assume that you want a build tool, state management, client side routing etc and beginners spend hours configuring those tools and figuring out state management and client-side routing, instead of doing real work.
Okay, say I do the tutorial and build a simple page - how hard is it to retrofit routing or whatever to it? A lot of the time with new frameworks, if I get past the initial setup hurdle, I can't work out how to easily move away from toy apps to something I can use in production.
One thing I want to say is: Don't assume only developers make websites. Don't assume everyone wants to ship a heavy and complex SPA.
Example 1: A great typographer, Wenting Zhang, author of Type Detail[0], contributing to Source Han Serif, learning Vue to do some interactive widget for variable fonts[1].
Example 2: Brian Terlson on TC39. He's using Vue without Vuex or Vue-router to build an app to track TC39 discussions[2].
I hope we can admit that many people might not need store and router[3]. Store and Router are necessary for building complex SPA, but don't make them necessary, as many don't want complex SPA. They impose learning efforts in exchange of better architecture, but the imposed effort might not be worth it for many people who just want some data-rendering, some reactivity and some interactivity on their websites.
This will probably be downvoted but I have come to appreciate frameworks which are opinionated and target a specific use case than very general and trying to please everyone.
I'm not sure were the author looked for information about architectural patterns but there is a separate section on it in the documentation: https://vuex.vuejs.org/guide/structure.html
This clearly outlines a suggested structure for non-trivial apps, where API requests are separated from the state management. It also references the Shopping cart example as a guide.
Due to this glaring oversight I can't see any criticism the author has as valid in the section about "Unclear architectural patterns".
On the top page there's another thread about rust-analyzer vs RLS. What Aleksey said[0] about RLS that "[RLS's] current architecture is not a good foundation for a perfect IDE long-term," feels similar to my coworker's conclusion in her effort to provide better editor support for PHP[1].
Parsers for compiling code into machine-executables vs parsers to serve LSP responses have different tradeoffs. For example, Anders mentioned TS parser need to have good error-recovery, can respond with completions/errors when one file changes inside a thousand-files-project. I vaguely remember TS had a goal to provide completions in < 50ms and errors in <150ms. Such goals are hard to achieve as after-thought. If your core compiler doesn't do error recovery, such as PHP, you need someone to write a new compiler from scratch for a language server implementation. If tools such as RLS rely on compiler to dump all JSON metadata and figure out LSP responses[0], it's too slow for editors.
TS's good editor support doesn't come free. I think one of the most under-appreciated achievement of TS is how it took editor support seriously and designed its compiler infrastructure to do it well. That's why I don't believe in those hot-new-web-languages that try to take over TS by designing a better type system. TS brought the average developer's expectation of a language to having fast completion, fast error reporting, editor autofix, F2 to rename and renaming-a-file-in-editor-to-update-all-references. It's 2020 and people aren't going back to write code like in Notepad.
[0]: https://ferrous-systems.com/blog/rust-analyzer-2019/
[1]: https://github.com/microsoft/tolerant-php-parser
---
EDIT: grammar.