I’m guessing what they mean is that the valuation is so inflated at this point that the high dollar amount more reflects the likelihood of acquisition or IPO in the near term rather than some sort of substantive demonstration of confidence in the company and its founders.
That's luck on your side. I too own a butterfly keyboard, trouble free. But there were 50 other macs in the office I worked in that regularly had issues. They were unreliable as hell, and beyond the reliability issue, many people did not like the shorter travel distance (I didn't mind this at all myself).
> why limit yourself to TypeScript which is a "Compile-to-JS" language? You control the stack, make another choice.
Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js. We want an ROI, we just don't want node/npm.
> Because some of us _like_ typescript, or at a minimum, have invested a significant portion of our careers learning ts/js.
Right, makes sense. It also makes sense that most of those learnings are transferable, it's not like TypeScript is the only language with types. So your design/architecture skills can be used elsewhere too. Locking yourself into the ecosystem of one language, then asking other runtimes to adhere to your preference sounds like a sure way of getting disappointed, instead of being pragmatic and flexible to chose the right tool for the problem.
I haven't seen any true competition with TypeScript, at least for me. Go is unsound (Go slices...), Python is too high-level (even with mypyc), Rust is too low-level (in comparison to TS), and so on. It's not just "a language with types".
Also, when I was writing a frontend and backend both in TS, I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
> I could literally share the exact same type definitions between them. Then I could use a compiler plugin (`typescript-is`) to validate on the server that payloads match the appropriate type. It was amazing and worked quite well, and I can't really see that being nearly as easy and seamless with anything else.
But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right? And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too?
It's not like TypeScript gives you some inherit benefit that makes it easier to convert to JavaScript, besides the fact that it's literally a "Compile-to-JS" language.
> But isn't that benefit just because TypeScript does compile to JavaScript and is compatible with JavaScript? Remove that compatibility, and you wouldn't get that benefit anymore, right?
JavaScript does make it easier to target both the web browser and Node.js, sure. But TypeScript also has a fairly mature type system and ecosystem (flaws in `tsc` itself notwithstanding). Not to say that no novel approaches are worth exploring, though; I just haven't seen one that rivals my TS experience yet.
> And if you still can get that benefit, why wouldn't you be able to get that benefit with other languages too?
That depends. In many other programming languages (such as ones that compile to WASM) it's also possible to have common code shared between server and client, but it's usually pretty inconvenient to actually get the code running in both environments. It's also possible to have a common interface definition and generate types for server and client from that definition, but that's still more complicated.
Anyway I don't fault anyone for being disappointed that Deno fell into the Node.js compatibility trap. Pure TypeScript without that particular cruft is also something I was excited about. I also was excited to see what looked like some fair innovation (like their import mechanism and their sandboxing) but I don't know how that'll continue if Node.js compatibility ends up being too much of a time sink.
I don't have very strong opinions because I've never really used Deno and I probably won't even bother at this point, but I definitely would not agree that this is just a problem of needing to use another programming language instead.
What are you referring to here? Go's current slice implementation could only possibly introduce unsoundness via data races. Even there, I think you might actually need to muck around with an interface value rather than a slice to demonstrate unsoundness of the type system (rather than just memory corruption or unsafe memory access).
Typescript's type system is just deliberately unsound by design (for defensible reasons). It's a whole nother level of unsoundness in comparison to Go.
I don’t understand the need to share types between frontend and backend. It’s like a strong incentive to take the wrong decisions down the lines instead of using the right data model for the domain.
Typescript's type system is uniquely good for preventing types in "bog standard enterprise code". No other language comes close to it. Two words: untagged unions. And of course all the other utilities it provides.
It's extremely good! Shame about it being coupled to Javascript.
Oh yeah. One of my pet peeves is that every comms product from Google (say Google Meet) works poorly on a slow internet connection, and slow could be something not bad at all, say 20 Mbps. Zoom, the former Skype, Slack Huddles, Go2Meeting, absolutely every other product has good audio quality and tolerable video quality. With Google products there are dropouts every few seconds so you can't understand what the other people are saying.
I have used Google meet exclusively for a number of years, multiple times a day on the cheapest Internet connection I can buy in my area. It is consistently a better experience then Zoom or Teams.
The only caveat is that the experience is not good on Firefox. Google meet is the only thing I use Chrome/Brave for.
> How did these clowns manage to make my mouse cursor laggy?
FWIW, the link is to basically a glorified demo page _of the design_ of material 3, not a real world implementation of that design. So, that page's performance is not at all reflective of what you'd see when using a relatively recent android app that uses flutter's material components (https://docs.flutter.dev/ui/widgets/material) or one of the many web component libraries that implement MD.
The lag you're noticing is also likely entirely due to their weird cursor behavior. If they simply removed that, I suspect the page's performance wouldn't be at all noticeable.
If the people who came up with this design can not make the demo site performant, site which will be the first impression of your new design language for most, I don't think there is much hope for the rest of us.
But since this has name of Google attached to it, many people will mindless ape it to the detriment of experience of their users.
I think the people who implement google's html/js/css for random articles aren't particularly connected to engineers working on android/flutter widget performance, and the MUI developers aren't even google employees (mui/flutter being the main implementations of MD AIUI). I'm not at all concerned.
Every Material UI library I've seen in existence is a bloated wreck full of bugs. The Angular MUI "flagship" has the worst performance I've ever seen of basic things browsers have supported for decades and CSS does very well for like buttons. Some MUI teams find ways to bring all of Angular's bloat to everywhere else, the React library is awful. I've had to use MudBlazor, the attempt to do MUI things in Blazor, and it is truly awful. Maybe Flutter is an exception, congratulations to Flutter I guess.
This wouldn't be so much of a problem if so many corporations also hadn't somehow decided that MUI was the next Bootstrap and have been treating it as an underlayer in their Design Systems, most of which aren't actually supposed to look like Material and don't really benefit from being huge additional libraries of CSS and components on top of MUI. I blame Figma for this. I don't know that it is any one specific thing Figma is intentionally doing, but the more design teams use Figma the more they seem to think they "need" a safety blanket of Material UI somewhere in the design stack that they won't actually use correctly or well.
As an engineer often tasked with performance work, I hate how much of Material UI's braindead approach to performance reflects on me in ways I can't do anything about "because that is the design system you wanted" (not the design system you needed). I wish Material UI would either get significantly better or just die already.
I tend to agree with your criticisms. FWIW, I do think mui has peaked, at least for greenfield projects. A new wave of tailwind-based libraries are rising fast, the most prominent of which are Mantine and Shadcn. IME, both perform MUCH MUCH better than mui.
You like the Tailwind-based approaches? That's not the direction I would go either. I've never seen anything Tailwind-based not feel bloated. It's such interesting malicious compliance with "no inline-styles" lint rules by just moving the inline styles into the class field. I see the same problems, including variations on the same performance problems, I remember from the bad old jQuery days of everyone just smashing inline styles everywhere all the time that lead to the "no inline-styles" lint rules in the first place.
But I'm a fan of the cascade done right and with CSS Grid and CSS Variables and @layer vanilla CSS cascade is at an all time jam right now. I'd be surprised we aren't seeing more "Design Systems" in that space, but I've got a feeling given how much you can cut from a Bootstrap or Bulma today for CSS Grid/CSS Variables that maybe we aren't seeing a lot happening there simply because not a lot needs to happen there. People happy with the cascade are getting closer and closer to also being happier with "no frameworks" again. Vanilla CSS feels good to work in again.
There's two ways of answering this, but both amount to a yes
1) I certainly think much more highly of the recent plethora of tailwind based component libraries than the previous generation, which mostly don't require me to actually use tailwind directly (mantine, daisy). Component library developers seem to like it _a lot_, and the outcome is great. If they're happy to use tailwind and I'm happy with the library that is built on top of tailwind, then I'm happy with tailwind.
2) The other way of answering this is if I'm using tailwind directly. To this point, yes, I'm still happy. The metaphor I've used is that tailwind is to css is as ASM is to machine code. It's still low level, but far, far more ergonomic. And in the end, you often end up using a higher level of abstraction anyway (again, see Daisy, mantine).
>Vanilla CSS feels good to work in again.
FWIW, I really do agree with this. But I think tailwind + postcss is even better still.
Checking out the recommendations, out of curiosity, my first things that I notice:
- Mantine doesn't use Tailwind. It's overly React specific for many of its components that don't really need to be React components but could be Vanilla or Web Components, but it doesn't seem to be anything like the Tailwind approach.
- Daisy seems really funny to me because it seems the long way around to be a Vanilla CSS framework while still being too much Tailwind.
- (ShadCN is definitely the worst of both above things, utterly React-specific and taking the long way around from Tailwind back to things that resemble Vanilla CSS, only with extra React for React's sake)
Before I got an iOS phone I thought "why do people care about apps?" I mean, there is an app to get me into my gym but with my Android device it would take about 45 seconds to open so I might as well just give them my phone number. It was always faster to go to a web site or go to the public library or do anything other than wait for an app to open.
This page is a promo page of the ux design language people as created by UXD/UXE role people.
It's basically like looking at a Figma export and complaining about the performance of it; any actual implementation would be done for any user-facing products realistically will be entirely unrelated both technologically and organizationally.
> Look at how snubbing developers has worked out for the Apple Vision Pro
I really don't think Apple's dev policies has had anything to do with this. The issue is the price - it's simply inaccessible to the vast majority of consumers, even many moderately high income consumers due to its value being somewhat unproven.
It's not in the demo video, but it's in the demo gallery. That's also the thing that's linked as "demo" on the landing page, so I thought you were talking about that.
Could you explain this? Is this commentary on voting power dilution or their class a/b share rules?