While I agree with the sentiment, and the example is quite bad, their argument is undermined by blaming Twitter for a third party apps issues.
Wow, lots of features that will really make a difference in day-to-day use. Not having “Go to Source Definition” has been one of the biggest annoyances in TypeScript / VS Code, this will really improve quality of life.
Also quite excited about the “Organize Imports” improvements, we have several files where we need to import in a particular order (mainly polyfills, dotenv
, etc.), and the only solution at the moment is to use “Save without formatting” in VS Code.
I’m massively dreading the switch to ESM though, having to import “foo.js” filenames in TypeScript is just such a confusing decision, and the benefits are… what exactly?
Some NPM modules have decided to go “ESM-only” (eg. quick-lru
), so I’m hoping that we’ll be out of this weird limbo phase soon.
Can you clarify what you mean? ESM is already one of the “competing standards.” How does switching to ESM change that?
If anything, I’d think that folks switching to ESM is the only path forward to reducing fragmentation, because unlike the other approaches, ESM is actually the language standard.
CommonJS was a de facto standard before ESM was invented, and the increasing adoption of ESM increases fragmentation of the ecosystem for no reason. If it was desirable to have modules in the language standard, and to keep fragmentation low, making CommonJS the language standard would have made the most sense. Clearly that wasn’t a concern.
What baffles me about LSP is that it actually does not deal with the most fundamental aspect of language support: syntax highlighting. There is some work to extend the protocol but last time I checked there were no IDEs that supported this extension. So while your auto-completion may be handled by fancy LSP, your syntax highlighting is likely handled by brain-dead, regex-based Textmate syntax “grammar”.
Several editors that are more serious about it are using Tree-sitter, both for syntax highlighting and for structural editing/navigation.
Neovim is doing a lot in this direction, with more still to come. Although a lot of this is still marked as experimental, I switched over to only tree-sitter-based highlighting about a month ago.
I found the early presentations about the development of tree-sitter to be exellent.
VS Code supports semantic highlighting via language servers. See here: https://code.visualstudio.com/api/language-extensions/semantic-highlight-guide
No idea if any other IDEs have taken this approach yet, though.
They added syntax highlighting in the latest version:
https://microsoft.github.io/language-server-protocol/specification#textDocument_semanticTokens
But yeah, it’s surprising that it took so long – it’s a rather fundamental operation, and it stresses server’s architecture.
I think that’s because syntax highlighting is often done synchronously in the UI thread, while all the other features are done in the background? It’s generally supposed to be cheap (and approximate).
The tldr is that it doesn’t support the full TS syntax (so no skipping compilation) and it mandates that engines not enforcing the types (thus burning the syntax for any actual type safety in future)
The organizing principle of web APIs is, “Don’t break the web.” The runtime type safety ship sailed for JavaScript the moment ECMA-262 was adopted. The only way to maintain backward compatibility for existing codebases is to define some other language browsers are expected to support:
<script lang="someotherlangauge">...</script>
Given the large surface area of the DOM and the likely complexity and performance overhead of running two scripting language engines in parallel, that seems unlikely.
Adding type syntax to JS would not break the web, but if the syntax does not require enforcement (or in tis case mandates non-enforcement), then engines would not be able to enforce type safety in future because that would break content that previously worked.
There are pretty easy ways around this if TC39 wanted to allow enforcing types in the future. The most obvious would be to create a "use types";
pragma similar to the existing "use strict";
Google even experimented with something similar in strong mode a few years ago.
Use strict had a phenomenal cost to the spec complexity, and required a significant amount of complexity in the implementation of basic semantics of JS.
The only reason I accepted strict mode in JS is because of the removal of |this| parameter coercion, nothing else in strict mode warranted the semantic overhead of the mode switch.
Adding another mode is not a think that is ever going to happen in JS.
The solution to opting in to types in JS, is to add an optional syntax that allows type constraints and enforce it.
This proposal adds the some of the syntax, doesn’t really specifies details, and also prohibits the engines from enforcing those constraints, which will burn the syntax.
So you get a large increase in complexity, but no actual benefit.
I need to be very clear here: the solution to optional/progressive typing in JS is to actually specify the constraint syntax and semantics, and require the engines enforce those constraints. I would be 100% on board with that. What this proposal does is half-assed.
In a HN comment one of the authors said a motivating factor was pasting typescript annotated types into the console, and said minifiers would strip out the annotation. The first could be trivially solved by console level rules, the latter completely defeats the argument for adding this proposal to the language.
Right, it’s neither one nor the other. And it’s not fully accurate either:
Things like visibility modifiers (e.g. public, private, and protected) might be in scope as well; however, enums, namespaces, and parameter properties would be out of scope for this proposal since they have observable runtime behavior.
Is this correct? JavaScript would just ignore private keyword, but not all of TS compilers do, or?
Didn’t JavaScript come up with it’s # notation for private fields after typescript had its private keyword? Private appears a little superfluous now perhaps.
Visibility modifiers (public
, private
, and protected
) are not valid in JavaScript. When TypeScript is compiled to JS, those modifiers are removed. If it didn’t remove them, it would cause JS engines to throw syntax errors.
JavaScript has also added a different way of having private fields (#privateProperty
), but that is a separate thing.
No, i know about the #
, but I am asking what happens if you both remove these modifiers and enforce them. E.g. tsc removes the private modifier on compilation, so I have a method visible (but the source said private) on an object. In the new proposal, the annotations are optional, but enforced. So the same source but different results. Or am I getting something wrong?
The proposal is that certain slots in JavaScript syntax will be reserved for type information, and that type information can be used by external tools, but that the JavaScript runtime will ignore those slots at runtime. This allows TypeScript, Flow, etc. to use those slots to express their type systems, and to continue to improve without locking JavaScript itself into any of those competing approaches.
So to answer your question, if this proposal is adopted, and it includes visibility modifiers like private
, then TypeScript would no longer have to strip out private
, because the JavaScript runtime would just ignore the modifier.
It is worth noting that the original post says that the proposal may include visibility modifiers, but it may not.
I think it’s important to acknowledge that Typescript also doesn’t enforce types, so a whole set of question of semantics and what to do in those cases would appear.
“enforcing types” is also a whole weird thing, where it’s like… for dictionaries that would involve comparing a bunch of keys, and you get into a lot of questions about what X or Y is… remember, Typescript is not nominal typing but structural typing! So “enforcement” involves a lot more work than just checking a type tag
Typescript does compile time enforcement, so while regular JS presumably can use incorrect types TS language projects presumably don’t
In terms of checking type constraints, that is not a thing that is hard for modern JS engines - they can also do it more efficiently than JS based checks as they can coalesce property checks to get single pointer comparison to verify in the common cases
Well, no one has any experience using runtime type checking across the whole codebase. Typescript’s type system is extremely expressive and complex - it allows arbitrary recursive type-level computations and type transformation. For example, here’s a type-level SQL library: https://github.com/codemix/ts-sql
In many of my projects I use these capabilities to express a well-typed interface, but resort to any
casting underneath the covers because I can’t prove my internal code follows the interface constraints. Most TS code today has issues like this to some extent. If we turn on runtime type check, how much inconsistency would there be? I expect quite a lot.
If we add syntax now, but then don’t enforce the type checks then the results is exactly what you’re claiming: people will write code that fails the typechecks, so in future the spec will not be able to specify typechecking rules because of breaks to existing content.
As far as TS goes: I’m not convinced that their type system is decidable, and any standard for optional/progressive typing in JS will require an exact deterministic specification.
For performance: it is possible that you could make type constraints that are hilariously complicated, but I suspect that the slow check case is uncommon.
I also think you could start with a less complete specification that has the benefit of not burning syntax. For example, you can start off with only having the ability to to specify property existence rather than existence + type, etc in such a case the type annotation would be purely additive so unconstrained properties would not prevent the future addition of constraints
I’ve said it elsewhere: the problem with this “specification”, is not the addition of syntax, it’s the addition of syntax that the runtimes are expected to ignore. If they ship ignoring the syntax then the syntax is burned: it can’t be reused for actual constraints in future without breaking content.
I can only speculate that the purpose of this proposal is to make further TypeScript-ish inroads into existing JavaScript codebases for the benefit of tools like VS Code.
one of the authors commenting in HN made it sound like the ability to past ts into console was at least a motivating factor, which is really not very compelling
Perhaps not for you, but it is very compelling for someone like me who works in TypeScript codebases (and enjoys it!) and would also like to be able to use the JavaScript console as a REPL for interactive development.
That seems like a reason for the TS folk to make a repl, not for JS engines to take the burden of parsing type annotations without providing any of the benefits (and worse burning the syntax so that they could never enforce types with that syntax in future)
There is already the deno REPL but I think they would also like to use the browser console, which sounds useful to me.
There is also ts-node, so no need to leap to Deno - though Deno’s CLI is a little faster, as AFAIK it doesn’t do type checking
SPAs are overrated for sure but there’s been a nice side-effect: virtual DOM and state management. Getting to declaratively, statelessly express the view according to the current state model is a much better system in a lot of cases than imperatively setting and parsing DOM nodes and attributes versus the jQuery or two-way-bound Knockout ages of yore. When you stack up a few of these components on a page it feels like maybe your whole page should just be a nesting of these models. I think that makes sense. I think the problem comes from not knowing when jQuery-like DOM manipulation works, or when a couple of React-like component on a mostly static page is enough.
Feeling it this week, I had to wrap my head around why a “static” landing page can’t have easy CSP because the of a CSS-in-JS trend needing unsafe-inline
or complecting the build with nonces instead of just writing CSS in … CSS. Or not having content Bing can actually index because “This app requires JavaScript”. Or why does a component asking for donations, inject CDN-hosted scripts at runtime instead of teaching how to add dependencies and not seeing that not only is this a security issue but didn’t even bother with with subresource integrity? The other problem may be these tools like create-react-app
making it too “easy” to create an overly complicated setup (with questionable defaults)–there should be some “hard”-ness to setting up something complicated and careful consideration for your stack/tools that just goes missing allowing some other “guru” to choose for you. Obviously this example almost certainly shouldn’t have been a SPA.
I can’t blame new programmers for not knowing what complexity budget their biting into–especially with ugh developer influencers saying these are the best and easiest way to build something. SPAs aren’t a mistake, but SPAs are overused. Static site generators have certainly been making their fair share of a comeback though.
Frameworks like NextJS, Remix Run, SvelteKit, etc are solving many of the UX challenges and engineering hurdles, and very much blurring the line between SPA and static site generator.
These frameworks all use browser history perfectly, omit JS code not needed at runtime, and let engineers choose on a route by route basis if a page should be statically generated, periodically statically generated, server rendered, or client rendered (which they discourage). The compiler/static site generator does the heavy lifting to split up code into loadable chunks, but there’s no configuration needed to get excellent performance. Things behave correctly by default (unlike create-react-app, which didn’t supply routing, history, or any semblance of server awareness last I used it).
They’re not perfect - someone can still end up shipping 1mb of multi language syntax highlighting to every dynamic page by accident - but they do a lot to give the benefits of SPA without most of the weaknesses. There’s a huge productivity win to having all your logic expressed in a single language.
I disagree conceptually with “blurring the lines” here. The level of complexity those projects bring is not really comparable to the simplicity of most traditional static site generators. Adding more complex tooling isn’t helping the situation. Suggesting we need more code generated and tools is not my idea of having cake and eating it too; it seems like good way to get a project that rots and is hard to migrate away from.
SPAs are overrated for sure
It might just be the places that I hang out, but I basically never see pro-SPA hype, and do see constant anti-SPA complaints. Where are folks seeing SPA’s being overrated?
You probably won’t see people extolling the virtues of SPAs per se, but rather particular frameworks for building SPAs, like React. There are probably a lot of front-end developers who don’t know that there is anything other than SPAs.
You probably won’t see people extolling the virtues of SPAs per se, but rather particular frameworks for building SPAs, like React.
Sure, I see folks talking about how React and Svelte are cool in comparison to Angular, but that doesn’t actually have anything to do with SPAs being overrated as concept. And in the front-end world the hype that I do see is generally about server-side rendering/hybrid rendering approaches that bring things closer to web 1.0.
There are probably a lot of front-end developers who don’t know that there is anything other than SPAs.
As someone who has interviewed a lot of front-end developers, I don’t believe this at all. Even the most clueless have been at least aware of other ways of doing things.
Some of my favorite books on writing:
It’s been a few years since I initially posted this. And while it’s not yet complete, it does have quite a bit more content than it did at the time. :)
The biggest recent change is that it has a new website which makes things much nicer to read online than browsing markdown files on GitHub.
Second paragraph and I’m already mad.
Rule 8: Flags represent nations, not languages – so don’t use flags.
Some obviously controversial flags: United Kingdom, Spain, France, Portugal. These examples have more speakers outside the origin country than within and is a very Euro-centric, colonial viewpoint of language to use any flag whatsoever. Not to mention, many countries have more than one language which further propagates stereotypes or belittlement of minority groups inside those countries.
Luckily the Steady site doesn’t break this rule, just the blog entry.
The reason flags are used is that if a website is in a language you do not understand you may not otherwise know where to click to change the language, or recognise the name of your language. The word for “English” in Russian is “английский”. Are you going to know to click on that unless there is a American or British flag next to it?
Everyone knows that people get het up about flags. Flags are used despite this for usability reasons.
That’s why the dropdown for language selection should list the name of each language in that language. Deutsch, English, Espanol, etc.
My favorite “bug” I saw lately around this was a county drop-down that was translated to German but the sort order was still in English. So Germany (“Deutschland”) was not under “D”, but under “G” right after Gabun, where it is in the English sorting. Very confusing.
This can also be fun for country names. Sending something to someone in France, I had to find the UK in a French-language drop-down. At school, I learned a few variations on how the country name is translated into French, this web site introduced me to a new one.
Le Royaume Uni I suppose?
The UK is a hard nut in these forms. I often try a number of options, but I can’t complain when even the Olympic team uses the wrong name (“Team GB” - the UK is not just Great Britain).
A bit tangential, but UK government forms really threw me for a loop the first time I used one, as it’s the only place I’ve seen the adjective form of nationality used for the Citizenship/Nationality field. When listing my citizenship for visa/etc. purposes, on most countries’ forms it’s just a drop-down of country names. So usually you can find the USA under U somewhere (United States, USA, U.S.A., etc.). But for gov.uk
it was under A for American instead (UK was likewise under B, for British). I’m not too knowledgeable about the details, but I assume this has something to do with the complexities of British nationality.
Sure, you just need to find the “язык” dropdown. Should be easy as the currently selected value will be русскийрусский which is obviously wrong.
Yes! Languages get closer to nationalities than most other pictograms. I couldn’t know to pick a picture of Spain’s boarders to change language, nor would I know to click on the alphabet (which doesn’t work for languages without alphabets). And flags help. Then, you say what the language actually is in the drop down so you can select it…
Other rejected pictograms: Official bird View from the capitol Airport code Biggest company based there Slowly moving language names
As sibling noted, obviously they should be in the native language spelling (or maybe put both). With Spanish being the US’s #2 most spoken language (no official language), should those Spanish speakers not count and find it odd they speak Spanish daily and click the US flag where they live and get English? Should they look for a flag of Spain? Or Mexico? Or their birth country (which is likely missing)? “español” + es
is very clear (even if all dialects aren’t yet translated) and doesn’t have the same degree of political baggage as flags and countries do. When people migrate – and they do a lot in the 21st century – their languages come with them because languages belong to the people and flags belong to the nation.
But do you really think people really know their flags? I don’t think this assertion is true. Which of these is Poland: 🇲🇨 🇵🇱 🇮🇩? Romania 🇦🇩 🇲🇩 🇷🇴? Ireland 🇨🇮 🇮🇪? Bolivia 🇧🇴 🇬🇭? Mali 🇸🇳 🇲🇱?
But imagine if a user could send their preferred language through the user-agent and the server or browser could choose a ‘good’ default for them … Accept-Language
sounds like a good name for this, maybe even navigator.languages
. That would be better than what Google does: ignoring my request and mislabeling me based on IP instead.
If you did user research on American Spanish speakers I wonder how many be confused by the American flag being used to denote English. Have you ever tested this?
I think using Accept-Language by default would be a big improvement though it’s not a panacea. To some extent it just punts the issue to the browser. Changing your language in most browsers requires you download a language pack which you won’t have permission to do in internet cafes. Maybe that is no longer a problem now people have smart phones?
Changing your language in most browsers requires you download a language pack
changing the Accept-Language
header does not require any downloads. It is just a string that gets send. The browser UI stay as is.
Chrome and Firefox have easy to use setting to change the language header that you send to websites. There is nothing you have to install. You do not need admin rights for that. This has worked like this for the last 2 decades at least. That is what I am referring to.
If websites ignore the header, that is not a problem of the browser, but our industry.
I live in India. We have at least 13 languages that have 10+ million speakers, and hundreds of minor languages in active use by smaller communities. Indian currency notes have text in 15 languages. From what I understand, there are several other countries with this kind of linguistic diversity (Nigeria, Pakistan, Indonesia, to name a few).
Using flags to represent languages is a Western European notion. I personally find it both disrespectful and confusing.
Using flags to represent languages is a Western European notion. I personally find it both disrespectful and confusing.
It’s worse than that. It’s not just that it’s a Western European notion, the equivalence of language and country is one that has been specifically pushed by majority groups to marginalise minorities. Ask folks whose native language is Gaelic, Welsh, Breton, or Catalan, for example what they think of the equivalence and you’ll get a very different view.
I think that is because they developed it for the European market, as their title suggests, and to illustrate their text with emoji/icons.
nah actually i hated to see it 🙃 but instead of whining here i asked the author to reconsider… and it got fixed
The screenshot uses a flag for German/“Deutsch” which I’ve never seen before, and German is my first language :)
To quote the article:
First and foremost, and this is why this example has been used in this particular post, Revolve has bizarrely ended up with the flag of the United Arab Emirates for German
What’s controversial about the Union Jack representing English, a language born of and primary to that soverign country?
The Union Flag is the flag of several distinct political entities that have different sets of official languages:
So the flag points to at least three distinct language families and several overlapping ones. Only Wales (which is covered by the flag, but whose flag is not represented, in spite of being the part of the UK with the best flag) has a notion of an official language that carries any significant legal weight and it places English and Welsh on the same level.
You could probably use the George Cross to represent en_GB, although both Cornish (Celtic-family) and Scots (mostly the same ancestry as modern English, i.e. a creole of every language spoken by folks who invaded England over a period of a thousand years or so) originated in the area represented by that flag. Either way, you’re marginalising speakers of minority languages.
I didn’t say anything about official languages or political entities, which is almost exactly my point. Primarily, British English is spoken throughout the United Kingdom, the soverign country in which it developed to the standard of English which was then spread throughout the world. The flag points to multiple regions with different languages, none of them as immediately relevant as the English language - you don’t see the Union Jack and think of Cornish. If the language was Scots, use the Scottish flag. If the language is Gaelic, use the Irish flag (or Ulster Banner, lol). To feign shock and horror at the Union Flag representing the history and origin of the English Language is inane.
If I clicked the Scottish flag, I could be wanting either Scots or Gaelic, as mentioned by david_chisnall. Likewise, if I scanned for the word Gaelic, I’d personally be expecting Gàidhlig, not Irish. When it comes to English, there’s like half a dozen different flags that may have been chosen that I have to scan for (I have seen UK, USA, Canada, England, and Australia, frequently, and probably others less often), and that’s ignoring any personal feelings I have towards any of those. Country flags and $current_language names for other languages just aren’t the best way to display these things for translation pickers, for multiple reasons.
Two issues:
How do we avoid this issue? Just say “English” or en
.
It doesn’t reflect all the other kinds of english spoken by the far majority of the world. We even call it “British English” to distinguish it from other flavours of English like American, where there’s a number of spelling and pronounciation differences (these distinctions even get taught in school in non-english speaking countries).
Oh, absolutely. British English is pretty well-known for that since there is a wide variety of English spoken between Scotland and South England.
Similarly Danish has different amount of grammatical genders between the islands. It is all the same Denmark with the same flag.
And for American English, a U.S. flag is oft used. Perhaps one should’ve been used in the article, but having not used Steady, I wouldn’t know.
What language would you expect behind a Belgian flag? French or Flemish? Similar goes for Swiss flag. Or Indian flag.
What language would you expect behind a Belgian flag? French or Flemish?
German of course! https://en.wikipedia.org/wiki/German_language#German_Sprachraum ;-)
BTW, Flemish is a dialect, the official language is Dutch.
It is a 55% vs 39% percent split, which part do you want to alienate by implying their language isn’t Belgian?
That’s not the implication at all, it’s not making a comment on the validity of the non-majority language.
We’ll be on Windows 14 before they move the last option from the control panel to settings. I couldn’t care less about a new notepad app. Is it another bloated electron app?
Getting all the UI engineers on my team to switch from our old custom Webpack build to the new (less custom) Next.JS build for local development. It’s a much better dev experience.
Working on upgrading a 130,000 line React and TypeScript codebase from an ejected create-react-app build (from a few years ago) to Next.js. Wish me luck!
I agree with the points raised in the article. One thing to add is that many tools built in academia are there to support the paper, not to take a life of their own. Given the short life of a thesis, there is not much one could do to make these tools gain much traction (all examples in the article show this).
There is another weird thing in our industry — I’ve seen many companies embracing the latest shiny tools and frameworks (k8s, react, containers, …), yet when it comes to thinking and implementing ways to speed up developer work by improving build times or reorganize dependencies, that is always a task for the intern, the least suitable person to handle such a thing.
yet when it comes to thinking and implementing ways to speed up developer work by improving build times or reorganize dependencies, that is always a task for the intern, the least suitable person to handle such a thing.
That has not been my experience. I’ve been tasked with that sort of work many times, and given permission to pursue it many more. Currently a senior UI engineer at Microsoft, but previously worked at a 500 person EdTech company for several years, and had a brief, but enjoyable stint at Todoist. All three were very happy to give that work to an experienced developer.
Have I had managers who were averse to that? Yes. But it has been the exception.
Agreed with this. My experience at both large and small tech firms has been that when a senior person wanted to work on developer productivity, it was almost always welcomed. Maybe it’s different at companies whose product is something other than what the developers are building, though.
The problem in academia is that it is controlled by where the professor can get money from. There is a lot more grant money for making shiny new tools than for maintaining and adapting old tools, and your academic life depends really strongly on how much grant money you can bring in (determines how many students you can support, how many conferences you can send your students to, and what equipment you can give your students). (New papers are also indirectly about grant money. You need new papers to bring in grant money, and you can’t write new papers simply by maintaining or updating existing tools).
I agree, and it’s also about promotion criteria; it would be hard to get tenure if all you ever worked on was maintaining old tools. I think the solution is to create a new tenure-track academic role which is evaluated, promoted, and funded based on the maintenance and creation of useful open-source artifacts (rather than the traditional goal of the discovery of novel knowledge).
Yes. At my previous job I set up Dependabot PRs to be automatically merged for minor/patch updates if they passed CI. Major updates still required manual approval, which mostly meant reading the changelog.
The prerequisite, of course, was having good test coverage. Our unit test coverage was at 95+%, and we also had a solid set of browser level tests written in Cypress. We also had a QA engineer who was manually testing new features and bug fixes daily, so we’d quickly see if anything went wrong.
Before I left, we had also begun following this pattern for some huge projects whose coverage was not as good, but did have a lot of eyes on it daily. It seemed to be working well, but I didn’t get to see enough to have a firm conclusion about its usefulness/danger in that circumstance.
I’m looking into Roam Research — and either choosing an open-source alternative (please recommend me one) or taking the plunge with Roam. Networked thought is very interesting and I’d love to get some public notes up.
Otherwise, I’m reviewing blog posts and giving technical writing feedback on things that people sent me from here. Thanks for all the interesting stuff y’all!
I don’t exactly know Roam Research but after a cursory glance it looks like a type of personal wiki, right? In that case I recommend checking out CherryTree or Zim, both are open source note taking apps and provide linking to other notes similarly to Roam.
If you use VS Code, Foam may be of interest.
Thanks! I do use VS Code so this looks pretty close to what I’m after. I’d love a web editor but I’ll have to compromise on features whatever I pick, it seems.
So far, the major plus of Foam for me is how integrated it is with git and the ease of publishing the notes online.
There’s a free and open-source alternative called Athens Research, currently in the works. They have a pretty active dev discord channel and are open to new contributors.
I use Org Roam. I like exploring the graph using Org Roam Server, but it was a bit fiddly to get set up. The back-links view isn’t working very well for me: It frequently doesn’t show any links, even though I know there are some; and occasionally hangs Emacs, so I don’t tend to use it. The graph browsing and ease of linking still makes Org Roam worthwhile for me.
More job applications and interviews.
It has surprised me that (comparatively) small but desirable companies have been much faster to respond than the megacorps with their armies of HR. This is despite the fact that I meet or exceed every qualification listed in the jobs I’ve applied for.
Senior positions in front end web development. I can also do backend, but I’ve got pretty deep expertise in UI specifically.
You can see my resume at https://joshuaclanton.dev
And thanks!
Post the excellent web apps that you know.
I’ll start with https://www.photopea.com/
https://www.soundslice.com/ (music learning/practice/editing via interactive sheet music)
Note taking app: https://reflect.app/
In the same spirit: https://mecabricks.com/