I've been using Windows for two decades and before that I loved the Amiga Workbench.
When I had the choice between a Dell Windows notebook and a macBook I went to the Apple store and some enthusiastic person showed me the new 2017 models with larger touchpad and gestures to move between workspaces. I thought "these apple people. who needs that".
Then we ordered the macBook and because of my keyboard layout choice it took a week to arrive. I got a used Dell notebook for week, worked and then switched to the macBook.
When I had to give the Dell back I wanted to transfer some files to the macBook, and I used the touchpad and made some macOS gestures and wondered why the touchpad is so small and why the gestures don't work. This was the moment I understood why the person told me about these things.
I'm using macOS for 7 years now. Also had to deal with some bugs and stupid UX here and there. But overall my OS of choice for sure. Oh and the touchbar on the top of the keyboard was not even a good idea, I think. My last Windows was Windows 7 and I liked it a lot. Windows 10 I never liked, even when I only used it in a VM.
This is what I meant by hardware; I consider touchpad gestures to be hardware even if their responses have to be handled in software.
I use my (my employer's) macbook 99% of the time docked, so I don't really care, but yes objectively gestures are top notch.
It's all the other parts of the OS to which you aren't immediately exposed which get me. Most displays need an external tool to force a sane resolution. The command line tools are almost-but-not-quite compatible with what you use on servers. Docker is horseshit. Need another external program to see how many times I have to cycle through app windows. Need an external tool to invert mouse wheel scroll direction but not the touchpad scroll direction. Need an external tool for a sane clipboard. Need an external tool to tile windows.
The hardware is very much 'pro' but the OS is at most 'deluxe'.
I would even say type checking is a must. We use Zod to define data schemas and have type completion and runtime checking. We even define request and response schemas in Zod for our APIs (inspired by protobuf/GRPC schemas, but without the code generation step).
I'd say you almost never need file-based routing, I'd even go that far to say you don't need routing DSLs for backend (just use if statements, performance will be fine without compiled regular expression to match all routes). The fetch API has request and response objects, and URL and URLSearchParams. But in frontend I find react-router-dom very practical. I think they introduced file-based routing in NextJS and co, because it's easier to generate frontend code bundles per route by listing files at build time. Other than that it's just a gimmick.
And as already mentioned ORMs (object-relational mappers) will give you headaches really soon, it's probably not worth it.
You can use Vite for the frontend part which is more lightweight than NextJS and co. I'd say if you have or your team has already build a web application with such full stack framework once you probably know what is needed and what is not needed in frontend with Vite.
Yeah, it's a bit implicit. Or you have to learn the rules by heart.
I also saw people struggle with two elements aligned to bottom with different line heights. Turned out they did not know that there is a default line height. And of course the "correct" line height to use is either "1" or "1.15" (not the browser default).
It looks like putting a list of utility CSS classes into one line is an intimidating thing of simplicity.
The written Tailwind code might not be beautiful (still it tends to be simpler than well-constructed CSS), but it does not stop the resulting website from being beautiful.
Well-constructed CSS does not stop one from building non-beautiful websites with beautiful code.
>For a static page it doesn't make sense to use React, obviously
JSX is a nice templating language. And when you use Deno or Bun you can use it directly on server-side. My server-side components have no hooks and use preact-render-to-string or `renderToString()` from `react-dom/server`.
Also there is Gatsby which is a popular content management system which also allow non-interactive statically rendered pages (as far as I remember).
JS is missing switch/match expressions, that's pretty much all IMO.
And I commend the maintainers of JSX for refusing to extend its syntax.
JSX can be learned in 15 minutes and it is a macro usually used to wrap React.createElement.
You could just as well swap your bundler plugin and use some other type of macro, e.g. sth like Mithril's m.
JSX is a very slim basic concept and I don't know a single gotcha except for the renamed attributes/props that are otherwise reserved keywords (htmlFor, className).
That you can use/see it as a templating language is just a part of its appeal.
I loathe having to use dedicated templating languages, having worked with Mustache and various PHP templating languages such as Blade and Twig.
Maybe "loathe" is a strong wors because most of the time it's easy and just works. But when it doesn't, debugging is a nightmare.
Escaping rules and questions like "what is code, what is a just an uninterpreted string" become unpredictable, and you have to learn useless baggage for each of them.
Same goes for all the JS DSLs using HTML attributes (Vue 2 "templates", which are actually not templates, etc). This is also what turns me off about htmx.
It'a great to throw together a specialized solution for one problem, but not great for libraries inventing unnecessary proprietary languages.
>don't know a single gotcha except for the renamed attributes/props that are otherwise reserved keywords (htmlFor, className).
This is related to `React.createElement`, I think. Preact does not have this problem. For client-heavy web applications I prefer React over Preact (not all libraries work well with Preact), but server-heavy web applications are fine with Preact.
ts-pattern has been a decent band-aid for the lack of native pattern matching, but obviously has downsides that could be avoided if it was built into the language.
That's true. It's missing "a ton of features" but the question is, if these missing features in the template language stop us from building correct and maintainable web applications. Having that said: We are fine with JSX.
Using Razor obviously did not stop Microsoft from building buggy web applications.
I had no idea what Razor was (I'm not a C# guy, I don't like to work on mediocre platforms... (see what I did here?)) so I read about it a lil' bit and could not find a single thing that it does that JSX cannot. Not one.
I suspect they want better condition handling. Because JavaScript lacks a useful conditional expression beyond ternary expressions, condition handling in JSX generally uses boolean operators or ternary expressions. Suppose the conditional logic is in any way complex. In that case, your choice is to use nested ternary expressions, which can be hard to read or to somehow break the condition out of the JSX using a helper function or separate component so you can use if statements in a regular function context. SolidJS added conditional helpers to its JSX flavour to address this issue[1]. The React team seems ideologically opposed to the idea as it presumably moves JSX away from using only JavaScript for handling logic.
>I suspect they want better condition handling. Because JavaScript lacks a useful conditional expression beyond ternary expressions, condition handling in JSX generally uses boolean operators or ternary expressions.
If a condition in JSX gets too complex I normally extract a component-level function and call it from the JSX part of the component.
knowing both i used to be frustrated by jsx's lack of support for plain if and for loops like razor has (eg map and the weird && syntax we general end up with)
of course this idea goes against jsx's implementation (as it's just nested functions) and paradigm of being html in plain javascript rather than an interpreted templating language.
some of the differences i really like (like being able to assign compoents to variables, pretty sure razor doesn't have anything like that).
Or Astro, and plugins for React/Tailwindcss/etc. Components are just nice to work with because of their modularity. Using the ergonomics "most web devs" are familiar with is just nice.
React rendering can get very very slow. A classical example are inputs that update very slowly when you type something. "Best practices" lead us many times to this when we round-trip the whole state from input change event, to global store object, immutable changes and back to the input. You can fight it with React.memo and by just mutating the state in-place.
Recently, I found valtio helpful as it allows to hook React components to rendering for parts of the global state.
Also all this useEffect(), useLayoutEffect(), and when it's not enough useEffectEvent() [1] and useEvent().
>FAST provides an innovative theming system called Adaptive UI, which builds design system properties that designers use every day directly into every component.
Then the next block is an example where you can change neutral color, accent color, saturation, border radius, stroke width and density of all components in a frame on the fly.
I really enjoy using GitHub, TypeScript, and VS Code. These are some my most favorite tools.
But Azure DevOps and Microsoft Teams make me think that the Microsoft engineers working on these products absolutely don't care and they probably don't need to care, and the companies using these products also don't care.
Popularity and dominance are criteria for success. Their success, but not necessarily your success. If the product is by Microsoft you have to look more than twice if it's a good product or if it's close to self-sabotage when you use it.
*Edit:* Ahh I see, capitalized not uppercased.