Scooty (u/Scooty) - Readit News

Scooty commented on TypeScript at Google (2018) neugierig.org/software/bl... · Posted by u/brlewis

dnndev · 5 years ago

Is typescript really that great? Every implementation I have seen has

1 - Work-arounds for interoperability with non typescript / legacy third party dependencies. (issue: ugly, non consistent code)

2 - Turn off strict type checking due to third party component compatibility. (issue: isn't the purpose of typescript type checking?)

3 - Is type checking really needed for most applications? (assuming some flavor of CRUD with the occasional special sauce). (issue: seems a bit academic unless your working on a webapp for the mars rover)

This is coming from someone who programmed in java, .net, strongly typed languages for years and then feels like javascript is being held back with typescript. I love programming in vanilla javascript using frameworks (in this order) vuejs, reactjs, and charge extra to work on angular.

Scooty · 5 years ago

I use TS every day on multiple projects.

1 is almost a non issue. Most libraries have decent types and TS has features for adding types yourself in your project.

2 - I've never had to disable strict mode to get a library working. Worst case you can use things like `any` as an escape hatch out of TS but it is usually tucked away in a black box that is nicely typed. Do you have examples?

3 - Correctness is important for most professional software not just billion dollar NASA projects. Runtime errors cause crashes which wrecks UX.

Scooty commented on TypeScript at Google (2018) neugierig.org/software/bl... · Posted by u/brlewis

dnndev · 5 years ago

“If you are writing code that some other person is going to read and/or you are interested in having it behave reliably in the long run, I think a static type system is a must.”

Can’t this be accomplished with JavaScript? Assuming your interested in clean code and best practices.

“Coupled with good unit tests”

Can’t you also write unit tests in JavaScript?

“if the type checker does not complain, you can be very confident the code you wrote is working and will work for a vast majority of the cases.”

This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

Thanks for your perspective!

Scooty · 5 years ago

> This is a false sense of security. “Compiling” without errors just tells me I did not do something dumb like assign a string to an int. Is this really the main issue devs have? From what I have seen no… Devs usually need to chase down and understand the code regardless of type checking.

I disagree. Working towards a successful "compile" isn't much different than TDD. The number of runtime errors I run into is significantly lower with TS than it ever was without which gives a very real sense of security.

You do need to understand the code but without types it can be very difficult to track down all the places that need to be fixed when you need to change your data model. Types are more important for refactoring than writing IMO

Scooty commented on Why I don't like Tailwind CSS aleksandrhovhannisyan.com... · Posted by u/jacobedawson

shadowfaxRodeo · 5 years ago

The author didn't touch one of the biggest issues of Tailwind. It ignores the Cascade part of CSS.

Even after optimizing Tailwind. You still end up with way more css than you should have. Add all the classes in the HTML and you're sending users a massive amount of data.

Instead of writing:

    main > * + * {
      margin-top:1rem
    }

you write `mt-100` a thousand times.

Scooty · 5 years ago

What do you do with that snippet when you realize some elements arbitrarily need more or less spacing than others because the designer decided it looks better?

Repeating yourself isn't the end of the world, and on occasion DRY is worse (look up incidental duplication).

Scooty commented on Why I don't like Tailwind CSS aleksandrhovhannisyan.com... · Posted by u/jacobedawson

ricardobeat · 5 years ago

I think there's more than personal preference at play here. The hidden benefit that the author missed is that Tailwind's (or any other atomic CSS approach) classes are immutable and all changes localized. This pays off hugely for large [enterprise] projects.

In a million-line codebase, you can add and remove classes from a specific element with 100% confidence that you are not breaking anything else. With class-based styles, even when using theme variables, there is always the chance you end up breaking something at a distance by adding a property to an existing class, changing a shared value, renaming a selector or changing it's precedence.

If you find yourself in this environment where dozens of people are making changes concurrently, and these issues are a daily occurrence, naturally you'll wonder how you ever worked with CSS any other way.

styled-jsx and other approaches can get you similar benefits but extra care is necessary. I mostly avoid Tailwind due to the lock-in, complex setup and slow build, otherwise might have used it for quick prototypes more often.

Scooty · 5 years ago

I'm pretty skeptical about lock in. If I couldn't use tailwind tomorrow, I think I could rewrite the few dozen minimal utility classes I need in a matter of hours. IMO the implementation is a convenience.

Scooty commented on Show HN: QuikPub – Write, Publish and Share rich text via short URLs quikpub.co/... · Posted by u/DarrenDev

Scooty · 5 years ago

I usually use github gists for this. Though I'm probably in the minority preferring markdown over wysiwyg.

Scooty commented on Problems with TypeScript blog.logrocket.com/is-typ... · Posted by u/BarelyLit

krowokoliz · 6 years ago

Why would you want runtime checks over static checks? The one thing I can think of is type asserting input from other js code, but surely you just want that on the entry function to your code, not in the internal bits.

Scooty · 6 years ago

Runtime type checking is necessary to ensure data received from untrustworthy sources matches compiletime types.

Scooty commented on Ask HN: How many of you are rolling your own auth? · Posted by u/xhrpost

Kkoala · 6 years ago

What about things like, password reset and email verification?

Scooty · 6 years ago

Not op, but I've written several apps with a similar setup to what was described. Both email verification and password resets are pretty simple to implement yourself.

For password reset, you just create a record with a unique token and send an email that links back to the app with the unique token in the url.

Email verification is basically the same: send an email with a link that identifies the user and hit the server with the unique token when that page loads.

Scooty commented on Moxie: Incremental Declarative UI in Rust blog.anp.lol/rust/moxie-i... · Posted by u/anp

nirvdrum · 6 years ago

What's the relationship between React and Vue? I've tried searching for it, but all I could get was code samples comparing the two.

Scooty · 6 years ago

They're both libraries for building user interfaces. They're related because they both solve the same problems. They also share a lot of core ideas (one way data flow, reusable components, declarative UIs, etc). I'm pretty sure React came first and heavily influenced Vue. They aren't commonly used together because most projects only need a single UI library.

Scooty commented on V8 adds support for top-level await chromium.googlesource.com... · Posted by u/hayd

pitaj · 6 years ago

JS async is implemented as generators as well AFAIK

Scooty · 6 years ago

I'm not sure how they're handled internally, but async functions are no longer generators. For a while after generators and before async/await, generators were used as a polyfill.

Scooty commented on V8 adds support for top-level await chromium.googlesource.com... · Posted by u/hayd

mstade · 6 years ago

I think async/await probably makes more sense in a typed language, where a compiler can tell you when you're missing an await, or at least warn you about not dealing with potential side effects and error handling. For something like JavaScript, it'd make more sense to me to have the runtime always and implicitly await the result of async functions, and instead make developers explicitly say when they wish for the result to be async. For example, instead of:

    const data = await fetch()
    push(someData) // async, runs in the background

You would do:

    const data = fetch() // Runtime detects promise and awaits result
    async push(data) // the async keyword would return a promise and execute the push function asynchronously, allowing the next line to execute

In this fantasy world the "await" keyword would work anywhere and as you'd expect – awaiting the result of any promise:

    const data = fetch() // implicitly await
    await async push(data) // this would also be "synchronous" in that it suspends execution of subsequent code until `push` fulfills or rejects the promise, and so it'd have the same effect as implicit await

Point is you'd probably await that promise elsewhere, so you'd actually store away the return value of the `async` call and later on you'd `await`, or another example would be to await a block.

Promise rejections in implicit awaits would halt execution, just like a sync function throwing an error, so you wouldn't "miss" an error somewhere because runtimes swallow promise rejections. (Well, at least Node wised up eventually.)

This means there'd be no difference in function declaration between sync and async functions, it'd be determined by whether they return a promise or not which I think should be possible to statically determine by a JIT compiler in most cases, so not adding too much (if any) overhead.

Kind of a half baked thought, but point is I always felt the async/await thing was kind of backwards in JavaScript.

Scooty · 6 years ago

Making await implicit would make it difficult to manage parallel promises. You would either have to make an exception for Promise.all or add new syntax. It's also not unheard of to have hanging promises (fire and forget).

Types make it easier to catch mistakes early in general. Typescript has a compiler rule 'no-hanging-promises' to help avoid forgetting to await.