I prefer ctrl+shift+z for redo. The advantage is you can spam both undo and redo without moving your finger from Ctrl and Z buttons. Very common in professional apps.
How can you even form an opinion on this if, as you stated in that thread, you literally have no idea what typescript is and are just a beginner in js? You got down voted for saying typescript is unnecessary without even knowing what it is or what the thing you’re working with’s limitations are, which is a pretty objectively braindead stance to take. You’re a beginner js developer, you have no idea what you’re talking about when it comes to preferences of ts vs js, just that all of the beginner level stuff you have tried to do works in js so therefore typescript or frameworks must be unnecessary
if you’re a beginner, and you post an opinion and lots of people say that many years of professional experience make them disagree with you, why would you not take that on board? I wish you well on your learning journey. at some point you’ll outgrow vanilla js and you’ll have learned enough to configure transpilation and webpack etc. it’ll be a good day.
The fact that you're doubling down on your ignorance is quite problematic. Typescript is not an enterprise system that forms arcane JS. It's literally JS with a slight adjustment that allows you to say "also this is this type". You write JS the entire time and can "disable" the typescript at any location you need to not be typed.
After this and saying that you’re a beginner to JS, I would instead suggest spending time to develop perspective from a place of knowledge and experience rather than… I guess, being proudly ignorant?
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).
I’m kind of a beginner… Can someone explain why you would make/use/have a dynamically and/or weak typed language? Is it just to not write some toInteger / as u64 / try_from()? I mean the drawbacks seem to outweigh the benefits…
If you are writing small and simple apps it will give you more velocity and much less boiler plate.
As apps grow it becomes harder to keep track of things and can quickly grow into a mess. You then start to need external tools to give you the features of a strong static type system.
Also from a web point of view you don’t want the website to crash and burn with every error. JS will power through things like invalid types. Imagine if any error caused the website to just stop.
There’s no real alternatives to JS “for websites” (meaning on the frontend, the part of your code that gets executed on your client’s browser). That’s what JS was invented for and what it does best.
I say “no real alternative” because technically we also have WebAssembly, which is a tool that allows you to run code written with any language on the web, but if you indeed are a beginner approaching to web development you should just forget about this for now and stick to JS as you learn.
Of course this doesn’t mean that you can’t use Python on your backend, your server.
Why should beginners approaching web development stay away from WASM? I’ve used it a few times to create online demos of software I made in Rust and it was a very simple and painless experience to get it working in a website. I consider myself a beginner and I have not run into any issues with it so far.
WASM is simply further down the rabbit hole for someone who is new to programming (but not someone who’s already a programmer and just doesn’t focus on web dev today). You are likely far less beginner than you think if you’re making decisions like “I’m going to compile my software written in Rust targeting WASM so I can demo it.”
The typical arguments for a dynamic typed language are that it takes less time to write something in it.
The benefits of static typed languages are that your development environment can be a lot smarter (ironically enough leading to faster development speed) and several classes of bugs being unable to happen. In a statically typed language, the IDE can detect if you’re trying to call a function that takes a number but you’re actually providing a string. In this case the IDE will let you know and you can immediately fix silly mistakes like that.
I prefer using JS because I can see the errors, while having to figure out which part generated the problematic JS code with errors when using something else.
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.
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.
Nearly all of these are illegal, but sadly there is little enforcement when it comes to this. (Tracking must be opt-in, not opt-out. Ignoring a banner must be interpreted as declining. Opting out must be a simple option, not navigating a complex and misleading menus. The users choice applies to any form of tracking, not just cookies…)
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.
I haven’t managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
following a basic tutorial somehow ended up spending multiple seconds just to transpile and run “Hello, World!”.
there are at least 3 different ways of specifying the files and settings you want to use, and some of them will cause others to be ignored entirely, even though it looks like they should be used.
embracing duck typing means many common type errors simply cannot be caught. Also that means dynamic type checks are impossible, even though JS itself supports them (admittedly with oddities, e.g. with string vs String).
there are at least 3 incompatible ways to define and use a “module”, and it’s not clear what’s actually useful or intended to be used, or what the outputs are supposed to be for different environments.
At this point I’m seriously considering writing my own sanelanguage-to-JS transpiler or using some other one (maybe Haxe? but I’m not sure its object model allows full performance tweaking), because I’ve written literally dozens of other languages without this kind of pain.
WASM has its own problems (we shouldn’t be quick to call asm.js obsolete … also, C’s object model is not what people think it is) but that’s another story.
At this point, I’d be happy with some basic code reuse. Have a “generalized fibonacci” module taking 3 inputs, and call it 3 ways: from a web browser on the client side, as a web browser request to server (which is running nodejs), or as a nodejs command-line program. Transpiling one of the callers should not force the others to be transpiled, but if multiple of the callers need to be transpiled at once, it should not typecheck the library internals multiple times. I should also be able to choose whether to produce a “dynamic” library (which can be recompiled later without recompiling the dependencies) or a “static” one (only output a single merged file), and whether to minify.
I’m not sure the TS ecosystem is competent enough to deal with this.
This last part sounds nice in theory, but it’s way outside the scope of what Typescript is intended to accomplish. I’ve been pursuing a similar goal on and off for 10+ years at this point, I even wrote an ORM for Backbone.js so I could use it on the server as well. Back then we called it Isomorphic Javascript, later on it got renamed to “universal javascript”, nowadays I’m not sure.
But yeah, the problem is similar with any code, really… What you’re often writing in software dev is just functions, but the infrastructure required to actually call said function is often not trivial. I agree it’d be nice to be able to have different “wrapper types” easily, but I’m afraid their usefulness would be limited beyond toy projects.
Yeah, I think it has to default to off but I believe the banner they show shouldn’t make it harder to continue with it being off rather than turning it on
I’ve heard stories about some of the big guys getting hit with sizable GDPR fines. I don’t really know the full extent of what they do but I do imagine there’s someone that makes it their job to prosecute GDPR violations.
this. and honestly I wish more websites followed the “serve under gdpr or don’t have a European marker”. A random blog once wasn’t available in the EU because of GDPR. And you know what? It’s better than them violating GDPR and the EU doing nothing.
programmer_humor
Active
This magazine is from a federated server and may be incomplete. Browse more on the original instance.