TheCee

joined 2 years ago
[–] [email protected] 2 points 2 years ago (1 children)

Maybe there is, though.

[–] [email protected] 2 points 2 years ago

What about square screens?

inb4 chaotic neckpain

[–] [email protected] 25 points 2 years ago (1 children)

Unfortunately nobody in charge has seen consequences for their decision to save a few theoretical nickels, so far. But then again, a lot of software/IT related stuff would look completely different, if anybody did.

[–] [email protected] 14 points 2 years ago (3 children)

Indeed. Makes it more work to filter the handful of good or even great articles from the 99.99% that use this platform for its apparent ease of money grubbing.

[–] [email protected] 5 points 2 years ago

It'll probably take Valhalla for me, personally.

[–] [email protected] 5 points 2 years ago

Or a signal that you'd rather not support the worst way to introduce type systems to frontend dev. While I'm not sure that applies to DHH, I am sure there are other devs that understand compromising all your goals to codepend on Node or even JS itself isn't that much of a win and rather see support for better options.

[–] [email protected] 1 points 2 years ago

but I could see it being a good step forward for more meaningful features to be added in the future.

I think you are right. And that is unfortunate.

[–] [email protected] 0 points 2 years ago* (last edited 2 years ago)

My bad, I'm not deep enough into our frontend stack to realize Hjeilsberg already did what he does best - ruining enums. (I guess he is not to blame for global imports in c#, so i can not add 'questionable import module/namespace ideas'.)

And it seems like this proposal contains type declarations (in order to compensate for their enums), among other typescript specific things. So, guess it is option B, then.

[–] [email protected] 4 points 2 years ago (5 children)

That's not a positive, though.

Depending on how it pans out, it's either not useful enough. Who the hell doesn't use namespaces or enums. Or - as

These constructs are not in the scope of this proposal, but could be added by separate TC39 proposals.

implies - a door opener to outsource TypeScripts problem unto other peoples and not to investing into improving WebAssembly. That's just MS being lazy and making their problems other peoples problems.

I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.

It's just annotations. No proposed semantics of a type system which your browser could check on its own.

[–] [email protected] 9 points 2 years ago

The lamp rotates along its post. Booom, solved.

[–] [email protected] 3 points 2 years ago

I sure hope so, but I'm not overly optimistic tbh. The market is basically considered medical, therapeutic devices. It is as you imagine, probably worse. It isn't easy to find prices directly, but the only way this range of vendors continues to exist in this niche market is to sell devices with the complexity of a keyboard for four to five digits. There is no competition worth talking about happening.

So unless very specific regulation takes place, I don't see standardized access to braille displays happening.

[–] [email protected] 1 points 2 years ago* (last edited 2 years ago)

Right, that is another item I wished more editors would have picked up. Besides - say - nested language modes.

 

Hi, does anyone know how to accomplish this? So far my workaround has been wrapping them in pre tags.

Thanks in advance!

 

cross-posted from: https://programming.dev/post/1941671

Details in the link of the headline.

 

Details in the link of the headline.

 

cross-posted from: https://programming.dev/post/1890996

(That's the title of this page.)

 

(That's the title of this page.)

view more: ‹ prev next ›