I’ve always felt it doesn’t solve the problem people think it’s solving.
deleted by creator
You can minimize the attack surface with certain fingerprinting resistance settings at least.
I personally don’t see why easy interactivity would be inherently a bad thing, plenty of apps that you would have to install directly on your system can instead stay isolated in your browser and never have access to anything else outside of it, particularly useful for proprietary web apps that we’re forced to use, those same apps that go as far as to beg you to install their native counterpart on your PC, which is clearly an attempt at data harvesting and increasing user retention. Also useful for simple stuff you need once in a while and it would never make much sense to have installed
I dunno, Typescript can be nice at times but it always feels like I’m bolting on something that doesn’t belong on top.
I’ll still use it for now. Not sure JSDoc is as adequate for an enterprise app for me. I know Svelte and stuff do, but I’ll wait and see.
Just use Kotlin to write your JS/TS
the fuck? TIL
You can also do this with dart. I swear there was another “new” language which could also be compiled to JS as well.
There are a lot of programming languages that compile down to JavaScript. I used to be big into Dart, but lost interest when they became solely focused on Flutter.
I personally like using Haxe as it compiles to actual readable JavaScript (and, for fun, a bunch of other languages).
Best place to learn it?
Kotlin Koans is a good hands on intro, especially if you’re already familiar with Java.
Fuck typescript.
(30,27): error TS7006: Parameter 'fuck' implicitly has an 'any' type.Error: Cannot read properties of undefined (reading 'fuck')
All the stuff I write is personal tools anyways so I do the same. They’re small anyways.
Typescript is great for catching long standing bugs in old legacy JS.
Me, who’s not in web dev:
Web development needs a whole lot of change and these kinds of fights are meaningless indeed.
I’m not on Twitter, what’s happening?
Here is an alternative Piped link(s): https://piped.video/5ChkQKUzDCs
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source, check me out at GitHub.
I’m with the guy sitting at the table
I am just a little “programmer” (if I can even call myself like that), and I’m using Typescript. Sure, it has it’s own shortcomings, as everything, but it looks better than plain JS (at least in vscode)
Is it even going to matter in the next 3-5 years? AI is going to make its own, kore efficient language and all the ones we use will be for hobby, fun and those who did not adapt.
Not the case. Ai can write binary. Languages are for humans to be able to use.
I agree with you, but writing human readable code will become a cottage craft and hobby as while it is good to know, AI will just be so much faster and better that coding anything yourself will make little business sense. I am already writing way less code, especially with the 100k token windows over on Poe.com which seems to handle most of my script sizes.
This might handle scripts as you described, but just wait until it needs the context of random bits of a tens-of-millions-of-lines monorepo plus knowledge of custom infrastructure that isn’t documented anywhere and–oh wait, we can’t actually let this LLM-as-a-service read our code because X and Y compliance/security/legal/etc, even if we ran it on-prem.
The robots aren’t coming for you so soon, don’t worry.
I think you are right if the progress on AI is linear, but if it continues to be exponential, nothing you said, even undocumented is going to be a barrier. That assumes AGI is coming and is as smart as the smartest people. We will see, but my money is on the progress surprising everyone. I am surprised by how much AI has improved over the last 6 months alone.
Certainly not in the next 3-5 years will this be a thing.
I learned typescript because so many authors are using it.
I think it’s like jQuery. Learn it because you’ll have to debug someone’s code one day.
I’m choosing the third side: WebAssembly
Blazingly fast 🦀🦀🦀
Incredibly powerful type system λλλ
And the best part, those two interop better than in native code.
those two interop better than in native code
Really? Why is that?
The wasm ABI allows for a bit more flexibility than the C one.
I’m not sure how much impact it has on practice (probably very little, otherwise somebody would have fixed it), but in native code there’s a lot of potential for mismatching behaviors from the two different runtimes.
Oh I had no idea, thanks for explaining!
You can even compile Fortran code to wasm and run it on a web browser. Who need Javascript’s puny 64bit floating point precision when you can have Fortran’s superior 128bit floating point precision?
Have they finally dumped the required js stub loader?
No, but GUI frameworks can generate it for you. Same goes for DOM access, for which there’s normally only a JavaScript API.
So, you’ll likely want to read JS, when researching what events or properties you can read/write for certain HTML nodes in the DOM, but with a mature GUI framework, you should not need to write any JS.
When I write JS:
- It’s because it has to run in a browser. (Why would I want to write JS that runs outside a browser? Rhetorical question. Don’t answer that.)
- I use no JS dependencies. Zero. None. No jQuery. No React. No VUE. No Typescript. Nothing like that. (Unless you count as “JS dependencies” a) a minifier (but not one written in JS) or b) browser builtins.)
- I don’t use any ECMA6 stuff. (Who asked for classes anyway?) Though to be fair, that’s definitely at least partially because I have yet to even really look into what’s available.
- I love callbacks and closures.
- I keep my global scope tidy, though I do store some things in the global scope. (Typically one or fewer global variables defined per JS file.)
- I don’t use prototypes. Just because I’ve never found good uses for them.
I do believe there’s a beautiful language living inside JS. It is quite pleasant to work with. But not the kind of thing I’d want to write “real software” in when there are alternatives like Go or even Python.
We used to use jQuery because there basically wasn’t a decent way to do a lot of things back then. Like selectors for instance.
Many of its best features have been absorbed in JS to the point vanilla is a much more approachable choice now.
The reason react and Vue are so popular is that any decently sized js app quickly becomes very hard to maintain. Or at least becomes time consuming to maintain. This is generally down to its dynamic nature.
Yeah, I agree that jQuery used to be pretty necessary for some pretty basic features in JS but is kindof obsolete now-a-days.
I don’t agree that any codebase that doesn’t use framewok X or Y will inevitably devolve into unmaintainability. If it does, it’s probably more because one isn’t following best practices. (Like the Unix Philosophy or SOLID (which functionally are kindof the same thing), DRY, ZOI, etc.) And no amount of frameworks can save you from that fate if you indeed aren’t taking steps to ensure the longer-term maintainability of your codebase.
You do you, but no ECMA6 stuff? I don’t use a lot of ECMA6 either because JS is at ECMA14 and continues to change. I can’t imagine reinplementing stuff on every project you work on, though perhaps your work is very different to mine. That said, treeshaking has really brought down the cost of imports and there are few occasions where using a custom solution over a reliable third party library is a good option. Curious to hear your thoughts.
Treeshaking imports (which, admittedly, I just learned about from some googling) assume that the JS you’re importing comes from another file (that the browser would have to fetch separately), yes? I believe that’s not a restriction of RequireJS (which I have experience with through my work but wouldn’t use on any personal projects.)
I’m just thinking performance-wise you’d get better performance by putting all of your JS in one (or a very few) files to be fetched from the server via one (or very few) requests. I am perhaps more of a stickler for shaving a millisecond here and there. (Which is part of why I wouldn’t use large JS lubraries. I wouldn’t want to make the browser have to load them.)
It’s very typical to import code from other files, but it’s also typical to have a minification step that essentially performs what you’re saying, compressing the files down into something more optimal. In fact more advanced solutions essentially stream the minium amount to users as needed, and compute as much as possible in the server side.
To be honest, I’d bet a lot than by not utilising larger libraries and their standardised functions, your code has a good chance of running slower. Besides, for the typical computer and network capabilities today, there’s a lot of wiggling room.
That said, for absolute tip top of performance (where experience is a trade off) you can find fun things like this, where groups do have to push for the upmost performance.
