Web development needs a whole lot of change and these kinds of fights are meaningless indeed.
What Typescript drama is there? It's fantastic. It's been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.
DHH (guy who founded Ruby on Rails) ripped typescript out of a supporting library and swapped it for JavaScript. He did it in his typical fashion of not allowing discussion and being a dick (PR only open for a couple hours and then merged disregarding all the negative feedback about the change) . So people are mad at him again.
He does stupid shit like this all the time because he’s a fucking knob.
RoR will always have a special place in my heart, but yeah... DHH sure does have opinions. What possible justification is there for removing it when it's already there? Guess someone could just shift the types out to DT.
Edit:
So I read his blog post about it. He's dropping it because he just doesn't like it and he's allowed to not like it. Okay then 🤷
His blog to me sounds like he did it because it was too difficult for him to understand a few errors. Says it all.
I wasn't going to say it, but yes, 100% 😂
You only have to read the PR comments with people asking how you know if something is optional when there is absolutely zero jsdoc to know it was idiotic.
From his blog post:
While you may compile dialects into it, you still have to accept the fact that running code in the browser means running JavaScript. So being able to write that, free of any tooling, and free of any strong typing, is a blessing under the circumstances.
By his logic, JS linters are bad because they're tooling that restricts your access to all of Javascript. But linters mean you don't have to read PRs with a fine tooth comb to make sure there's no footguns like using == instead of ===.
Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.
The question is really whether tooling pays its way in terms of lower bug rates, code that's easier for coworkers to read, and code that's easier to reason about.
As a general rule, if DHH says something, the opposite probably has some true merits.
or people used to work alone never having to go back to their code (e. g. bad consultancy jobs)
Even alone I find it indespensible. I find it's mainly useful for writing code correctly the first time around.
Some people think better with typing information explicitly written out. Some people don't. In my opinion it is a creativity thing. Some people like to make art that is photo realistic, some people like to make abstract art.
I understand both viewpoints. In my free time I vastly prefer late bound, dynamically types languages with robust reflection engineers built into their interpreters. For work, I heavily prefer late bound, strictly typed with reflection optional or minimal.
Different people think differently.
I think that's fine if that's how you like to work on your own, but I'd challenge anyone to do that and write better documentation while also getting a team or whole business to do the same. A huge strength of TS is that it gives people no choice but to document their work.
I didn't say JavaScript... and I certainly wouldn't choose TS for a personal project because I personally feel that its organization is terrible but I would choose TS over vanilla js for work projects because it does produce better group work and is easier to maintain long term because of the structure imposed on it.
Haha well that's fair enough then!
TS is amazingly powerful when it comes to refactoring. I swear it practically writes itself. Half the time by the time I fix all the compiler errors the refactoring is done. I barely need to think about it which means I can spend more time thinking about the best architecture. When people say they don't see how TS makes you more productive it just makes me think they never refactor their code.
Svelte decided to ditch it because it became impractical due to the compilation step slowing down development and making debugging their compiler harder. I think for libraries it makes sense to go the jsdoc way as long as consumers can choose typescript.
Am I the only one scratching my head trying to understand why Svelte supported it at the first place?
The TS type system is not a good match for the project.
I feel like there's no typescript drama, just JavaScript drama. Things are pretty happy in the TS community. I've been writing js code since it literally first came out. I'm definitely no js hater. In the early days js code bases quickly turned to spaghetti code, but I genuinely think the js community has done miracles turning what was essentially a super simplistic toy language into a seriously good production quality language. I've seen first hand how much work has gone into it, and while most of the js community has been great with embracing change for the better, there's always been the niche of detractors against any change that adds complexity even when it makes coding safer and more productive.
I've always had a love hate relationship with JavaScript, but with typescript it's really been just straight up love. Pretty much all the trouble I have with typescript has been due to external libraries that use types lazily or incorrectly, and even then there are solutions to add safety to your own codebase. Sometimes I run into some trouble with the type system itself, but it's pretty much always because I'm doing something really complicated that would be hard in any type system. I've been working with typescript for years now and my code bases are some of the most solid ones in my company. Typescript is really safe as long as you're actually using it and not telling the compiler to ignore types through using any or making unsafe assertions.
It makes no difference to me if other people prefer JavaScript. Any important js library will get ts support anyways through definitely typed, and if a library is so sloppy it can't be typed well then it's not a good library to use anyways. Having people proudly announce they only want to use JavaScript is also great for hiring. It easily tips me off on who not to hire.
I refuse to use it because it is backed by Microsoft.
I can understand that. Does it's open source status not change anything for you?
They have a vert high chance of pulling slack.
If it's dumped under an open-source license, but still developed exclusively by one corporation, they can swap out that license pretty easily.
For what? If they took it away, the source code would still be there if someone wanted to fork it. Not to mention removing TypeScript from an application is relatively trivial.
They're not that dumb, to just pull it completely. That would obviously result in a successful fork.
Companies usually start with e.g. the BUSL, so source-available but proprietary restrictions.
For TypeScript/Microsoft, I could imagine some variation of their EEE playbook.
But really, the whole point of avoiding Microsoft et al, is that I don't want to think about, how they could fuck this whole thing up. They've proven quite creative in this regard for as long as they've existed.
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.
vanilla javascript? what are you, fucking Amish?
I'd rather stay out of the frontend all together but I'd rather chop my balls off than go back to JS.
Plot twist: You are transgender and love working with JS
TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
Honestly, as a mainly backend dev wanting to do more full stack, webdev is frustratingly intimidating. I keep trying to look up best practices but there's so little in the way of consensus. "Use JQuery, no use Vue! React is better, but also React is clunky and bad. Write pure js, no don't that's a waste of time, at least use typescript." It's all such a mess and I spend so long trying to figure out what to use. I'm trying to just pick something and stick with it, but I keep worrying that I'm not doing things the best way.
I'd agree with you if you were saying this about 8 years ago, but IMO the post-jQuery-front-end dust has settled and the "best" (in terms of what most organisations end up choosing) hasn't really changed in a while.
Typescript unless you've got a really good reason not to.
React if you have anything remotely complex.
Webpack (or one of the wrappers) to bundle it up.
Sure, someone may like a React alternative, and that's completely fine. But at the end of the day, most companies are using React because it's basically industry standard at this point, and it's got too much momentum behind it for that to change any time soon.
I'd say the back end is where all the choice is these days
We must be in different organization circles because almost every frontend I've seen at my jobs or those of my friends at other organizations uses Angular
I'll be honest, I think it's been years since I last saw anyone even mention Angular anywhere.
Maybe I'm just too used to it, but with next.js static site generation I find react to also work really well for simple sites too. If you're not dealing with state, react is basically just functions that return templated html. IMO it's pretty sleek for static websites since tsx let's you do basic templating with functions.
As a previously front-end gone full-stack gone and settled in backend/infra... don't bother. But if you have to bother, or really, really want to 🙂, pick a relatively popular thing (e.g. Vue), and learn that, ignore the rest. By the time you come up for air the new hotness will have changed anyways, and the wheel will have been reinvented twice. It's a moving target, just learn the fundamentals with something and you'll be good to go.
Wait until you meet "Platform Engineering"/DevOps. The sheer amount of CNCF projects and new tools out on a daily basis are on par with the JavaScript world.
If you just want to try frontend, not trying to get a job there are these frameworks you should try:
Solidjs (love it so far) for a web application so SPA with separate backends
htmx to have a decently interactive website, it can be integrated with any webserver
astro for generating static sites
And i think everyone should use either Typescript or JSDoc for any bigger application.
Svelte is a happy middle ground between vue/react and SolidJS which is maybe too bleeding edge still
Agreed on the svelte part.
But I think solidjs has a real chance of taking over
React, because its similar, meaning JSX and hooks, but without the footguns. After using React, its so much cleaner and easier to work with, i cannot recommend it enough.
Thanks for recommending it, it does look really nice. I'll definitely check it out when a fitting project comes along.
For sure don't use jquery.
React is industry standard, but not my favorite. That being said, even my personal projects I do in react. I'm happy with my current role, but if I wanna switch down the line there's less openings for a dev with mostly Svelte (my favorite framework) experience.
Right now I'm working on a personal project with Vue because it happened to be the one I was hearing most about when I started. I've got one project that I'm definitely gonna finish at some point started in react, so maybe I'll try out svelte on my next project.
jQuery is obsolete and insufficient if you're looking for an easy monolithic framework. Angular, React and Vue are all good (disclosure, I haven't used react), just pick one and learn it well and you'll have a good foot in the door. If you already know JavaScript and don't want to learn typescript, Vue can be used with plain JavaScript.
Where'd you get your time machine, that you obviously would've needed to set to 2008 to find anyone actual recommending jQuery?
It's still the best API for imperative access to DOM.
Do you need to support 15 year old browsers? Practically all the jQuery features I used (which was a lot) are now available in standard js
Even if you do, you can still use most modern js features with transpilation.
Yes, the features are there. Just the API is still horrible.
As an example, make a hidden element visible (extremely common imperative operation).
I hope you'd agree that the native JS is certainly not an example of good API.
That's actually a great example of the shortcomings of jQuery. There are multiple ways to hide an element yet they standardized on one that often wouldn't work.
Also you're using an ancient method getElementById... I think visuals should still be controlled with css. So what is the right way to do that in modern js? document.querySelector('.some-name').classList.add('hidden') with that class defined in the css, with whatever makes sense, including maybe a css transition.
There are multiple ways to hide an element yet they standardized on one that often wouldn’t work.
It's the most common one. And it's not like you can't hide the element with some other mechanism with jQuery.
Also you’re using an ancient method getElementById…
And? What's the difference from document.querySelector() when querying for ID?
So what is the right way to do that in modern js?
What is the right way is context dependent. I don't see how having extra .hidden { display: none; } boilerplate is somehow modern or superior.
What's the difference
Your code reads like it's from 1992 mainly, which makes sense I guess, given that you still find jQuery better than modern vanilla js. jQuery was created as a way to account for browser support challenges but is now obsolete. Anyhow, if I read "getElementById" in recent js code I would assume something was weird about that code. It's old hat and there is rarely a reason to use it.
What is the right way is context dependent
Precisely my point. Which is why I think it's opinionated in a bad way to arbitrarily pick one of them as the defacto. I often had trouble with jQuery's .hide() method because while it felt natural to use it, it often conflicted with what actually needed to happen for good UX.
What you're missing is that the hidden class can contain anything you want. Animations or whatever else. In other words, the idea that there is a "right" or "most common" way to hide an element is flawed at its core.
Your code reads like it’s from 1992 mainly
Lol. You write a lot of text to mask the fact there's no good reason why getElementById should be bad. It's the same groupthink as with the jQuery, you're told it's bad, so you just follow the crowd.
jQuery was created as a way to account for browser support challenges
That was one of the reasons. The other was that DOM API was and still is crap. There were many such libraries to abstract away browser differences back in late 00s (Dojo, script.aculo.us, Prototype.js, MooTools), and the main reason jQuery "won" was that it provided the nicest API.
Which is why I think it’s opinionated in a bad way to arbitrarily pick one of them as the defacto.
You're missing the fact that jQuery does not prevent you from hiding the element in other ways. It's just optimizing for the most common case, which is one of the principles of good API.
What you’re missing is that the hidden class can contain anything you want. Animations or whatever else.
Sure, and when I just want to ... hide it, without any animations? Then this hidden class is boilerplate only.
I mean you're coming across like more of an old man than I am and that's saying a lot more than you know. For the first 2 years people shit talked jQuery I didn't agree with them. And then I got the opportunity to work without it and it seriously took like 3 days to completely change my mind. And all my pages were I believe about 100KB lighter.
jQuery is trash. And that doesn't mean it wasn't a great tool for its time. It's truly obsolete now though. If you hate the native JavaScript stuff so much.. I dunno maybe go work with Java or something?
Just fluff, no real arguments, ok.
I sure am glad I don't work with a moron like you who would ship a fuckton of JavaScript to users because they're too much of a pussy/old fuck to use modern practices
Why would you not want to be using a rendering library? Your code is basically storing your application state in the dom which will turn into a horrible mess as soon as you reach any actual level of complexity. I know first hand. I'm traumatized from having to maintain large jquery code bases in the 00s. No serious professional writes code like this anymore.
Also, your vanilla code isn't modern. It should look more like this:
I could see not wanting to use a rendering library if you're building a simple site on top of basic static HTML, but that's not a serious discussion for industry professionals, and even still, jQuery is such a heavy dependency for saving some characters. If you find yourself using it so much you need the extra convenience then your site is already complicated enough that you should be using a rendering library with state management instead.
Why would you not want to be using a rendering library?
Because it's just not very useful in some contexts. I've seen web extensions which mostly query the current page, and it doesn't render much or even anything.
Not all pages are SPAs either. Many apps are the old request-response with some dynamic behavior sprinkled on top. jQuery covers that well.
This model is also quite compatible with the rising HTMX where the state/rendering is driven from backend and you just insert few dynamic pieces with JS.
There's no difference between document.querySelector("#element") and document.getElementById("element"), they're both same level clunky.
Also, what you wrote is not functionally identical. $el.show() is idempotent, the el.toggle("hidden") is not (as the name suggests, it toggles a class). It also needs an extra boilerplate class.
I could see not wanting to use a rendering library if you’re building a simple site on top of basic static HTML, but that’s not a serious discussion for industry professionals
There are plenty of non-professionals doing web stuff and I think it's great!
jQuery is such a heavy dependency for saving some characters
jQuery is 24 KiBs (minified, gzipped), that's a good price for the egonomics it provides. If you're constrained, there are API-compatible alternatives like cash which go down to 6KiBs.
The main issue is that frontend is complicated and it can do a lot of very different things. Frameworks exist to solve some issues that may or may not exist in your project.
Best practices are pretty straight forward in the typescript community. Frankly I think all the serious professionals from the JavaScript community just went to TS so the people left over that didn't migrate are well...
React and typescript. If anyone tells you otherwise, ask them where they work.
Typescript is great for catching long standing bugs in old legacy JS.
Me: 2024 is finally going to be the year of WASM, boys!
And then there's me, missing flash :(
Flash and AS3 was so much fun to work in. I completely understand why the industry moved away from it but even today we have yet to fully catch up to all the media animation and programmatic features it provided all in one. RIP.
I still have a hobby website with an AS flash animation on it that I don’t have the heart to get rid of. It was so cool.
Have you tried porting it to Haxe? It's what I found whose selling point was "programming for those that know AS3"
Thanks, I will look into that
You could use something like Ruffle. Newgrounds also uses it to allow people to play flash games.
Thanks, will check it out
That's awesome.
But I'm picturing you keeping a retro computer to load it on and enjoy it.
Starfield has a bunch of AS3 and Flash files. I've been hacking it all week.
And, uh, I use vanilla JavaScript with Typescript checking via JSDocs.
I just wish WASM could replace JS rather than merely augment it for non-DOM work.
You can have frameworks which fully generate the JS DOM code for you, allowing you to write complete single-page applications without writing a single line of JS.
I'm using the leptos framework (Rust) and really like it so far. Not a single line of JS, not even npm as a dependency in that project.
Yep, that's the framework, I'm using, too. But most frameworks in the Rust ecosystem can do DOM interop, as the heavy lifting for that is provided by the wasm-bindgen library.
Unpopular opinion: I hope it's going to be a flop (apart from the few use cases where it does make sense). The limitation of having just JavaScript ensures level of interoperability which is IMHO one of the big advantages of web as an application platform. If WASM becomes successful, it will fragment the web.
I definitely feel you. Not sure WASM is the answer, but it’s still neat.
I think there's a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.
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.
Who the hell doesn’t use namespaces or enums
Uhhh, typescript devs?
Enums were useful once, but typescript evolved everything else around it and these days using direct values is actually far better.
And I don't think anyone uses Namespaces other than for defining external modules.
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.
Yeah it’s interesting because JS is interpreted, not compiled. The proposal allows for type annotations in the syntax but no actual interpreter consequences. On the one hand that makes sense because otherwise you’re in the territory of runtime type-checking which would be a huge performance hit and would sort of defeat the purpose of static types anyway. But that means you still have to rely on your IDE or a linter for this to be useful.
I don't see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, but I could see it being a good step forward for more meaningful features to be added in the future.
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.
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.
Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it's settled in your project and used well... Damn is it fucking good.
And I'm saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.
But if you're trying to use it like a traditional typed language, you'll only see the bad side of it and you'll certainly hate it.
Tell me you're a dinosaur without telling my you're a dinosaur
Telling me you have nothing to contribute without telling you have nothing to contribute.
typescript is a bandaid on a severed leg
More like a tourniquet and a prosthetic. It doesn't solve the underlying problem, but it's the best solution we've come up with.
I view it more like a powered exoskeleton around a blob fish. IMO static typing is way more valuable than strong typing and I'd take static typing only over strong typing any day if I can only choose one.
Mypy is just okay. Haven't used TS to know the dark corners there, but any type system that's bolted on to the language is going to have dark corners in the best case.
It's better than no type system, however. I remember when typed languages were "bad" because it "slowed you down" and "wasn't necessary if you know what you're doing"... how naive I was when I repeated those words so many years ago :)
My issue with typescript... and, correct me if I'm wrong... is it doesn't exist without Javascript. Typescript needs to be compiled down into Javascript to be run. It has no stand alone interpreter (that I'm aware of) and definitely not one baked into web browsers or NodeJS (or adjacent) tools. In essence, Typescript is jank sitting on top of and trying to fix Javascript's uber jank, simultaneously fracturing the webdev space while not offering itself as a true competitive and independent language for said space.
That's my amateur two cents for what it's worth.
The fact that TypeScript doesn't attempt to obfuscate JavaScript, and just fills in the gaps, is what makes it the best solution to the problem.
It's not a separate language, it's Javascript tooling
I've used JavaScript since its creation. I would describe typescript as JavaScript as it should have been. I've always actually liked JavaScript's simplicity, but I've never liked its lack of type safety. At its core, JavaScript has a tiny conceptual footprint, and that's actually pretty refreshing compared to other very complicated languages. But it was plagued with terrible implementations and the inherent messiness of dynamic typing. I've watched it evolve over the years and it's improved beyond my greatest hopes. Between the advent of transpilation, tooling, and typescript, I'm very proud of where the language has gotten to. Having made websites in the 90s and 00s, I feel like people don't realize how much work has gone into getting the ecosystem in a much better place.
I don't think it really fractures anything considering you can call a ts package from js without knowing. The other way also works with third party typings in DefinitelyTyped.
It really just adds a bit of extra type info into js, looks like js, and transpiles into js that looks almost exactly like the input, including comments and spacing and such if you like, so there isn't any lockin.
There isn't any competition, it's just an extra optional tool for the js ecosystem in my eyes.
The transpilation that typescript does doesn't really have anything to do with typescript, it's just there because typescript wants to support the latest ecmascript features, so transpilation is necessary for that, but technically you could simply strip out the type info and have another transpiler like babel handle the backwards compatibility. I think there are a few minor exceptions to that, like enums. There was even a proposal to add some typescript types to native JavaScript that would be ignored by the interpreter and just act as comments.
I mean, tsc without any of the backporting functionality is still a transpiler since it goes from a high level language(ts) to another high level language(js). Transpilation as a concept doesn't imply that it is for backporting language features or that the source and destination languages are the same, just that it is a transformation from source code to a similar or higher abstraction level language source code
Yes, it's still a transpiler, I'm not saying it isn't, but what I mean is that it doesn't add any functionally specific to the typescript language. There's a transpiler for TS that doesn't even do any type checking at all and just does the type stripping and back porting. But of course, that's not why people use typescript. All the features that are actually important to typescript could be done through a linter instead. If type annotations were added to JavaScript you could get most of typescript's features with linting rules and just handle back porting in a more standard way.
I think too many people ITT are conflating Typescript with Typescript frameworks like Angular.
As a professional with 25 years of experience I agree with you. The entire modern architecture was created by people who don't like simple things that work. I'm pretty sure there are a couple of high ranking master developers sitting at the head of W3C competing to create the most convoluted system possible.
You are correct.
That says I would never ever EVER start a project without TS.
It's like coding with hands vs coding with your elbow.
I also don't want to compile my C++ code myself. I'm pretty happy with letting a compiler do it's job...
I really don't get how people can feel more productive in JavaScript. With typescript the code practically writes itself. Sometimes when refactoring I'll change a functions input and output signature and just fix compiler errors until it stops complaining, and the code just works without me having to really even think about what the code is doing.
Any time I'm forced to go back to js I feel like I'm going crazy trying to keep track of what's in all the variables. With typescript I can use more powerful object structures without having to constantly double check where they came from.
Just fyi, while they don't help with running TS in the browser, the Bun and Deno runtimes both natively run TS without any compilation.
That's not true, deno compiles TypeScript to JavaScript, it just does it transparently. The code still runs on v8.
V8 also doesn't run js, it does some byte code compilation stuff amongst other things, then interprets that. But that's all a bit pedantic too, V8 runs js, deno runs ts.
fwiw https://deno.com even has as one of their first bullet points that they have "native support for TypeScript and JSX"
Sure, but part of the claim was "without any compilation". But bun/deno do compile TS into JS.
What we really need is a browser that runs something other than Javascript. Until then, stack of jank it is.
WASM?
Is that a standalone thing? This is obviously not my specialty but I thought it was part of Javascript.
I've never worked with it and don't know in detail, but it lets you compile several languages into web based client/server code (basically, converting other languages into website code). Works with C, C++, C#, Go, Rust, Swift, etc)
I agree.
I'm a hobbyist. I don't work on really large or complex projects. I just want to get the most productivity for my spare-time-dabbling and having tried a few times to get into typescript it seemed to create more "extra steps" for me than it saved.
Typescript doesn't have strong typing but static typing still gets you really really far. It means you need to be more careful with your io and avoid dangerous type assertions, but I don't think that's a bad thing. Having used typescript an absolute ton, the only real jank I've encountered is from bad library typings that either use it lazily or incorrectly, but for code bases that use it through and through it has been smooth sailing, and having professionally used both traditional static typed languages and dynamically typed languages, I really enjoy typescript's type inference and structural typing. I think you should give it an honest try before judging it. But that's just my 2 cents as an industry professional who has used many languages and have been programming for decades for what it's worth.
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...
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.
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.
But a statically typed language would catch those errors before it even compiles...
The fact it doesn't need to be compiled is also a big reason why it's used on the web.
But I absolutely agree. I'm not a fan of dynamic typing at all.
Si you say I should use python for websites?
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.”
Unsafe rust is your best bet.
They used to be more attractive around the 2000s, before type inference became commonplace and when IDEs/editors were still a lot less powerful.
As for making a dynamically typed language, to my knowledge, they are actually easier to create than statically typed languages...
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.
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.
HTML + CSS. No need for any of that newfangled "*script" bloatware / malware.
If it fits the need...
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)
I like TypeScript for its types and type-checking, but I also want to write JavaScript to avoid having a local build step, and having to wait for things to transpile/compile/etc when running locally. I have a pretty large project where I've gotten both worlds by just using JSDoc and only using TS for type-checking. VSCode still offers built-in type-checking with JSDocs and ofc the type-checking can also be run separately if needed.
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).
If js docs are a good working replacement then I can understand wanting to avoid all the annoying issues with typescript. I haven't used it before but it seems less flexible and more verbose, what's other people's experience with it? I'd have to check it out myself but for the moment typescript makes JavaScript a little more bearable.
Javascript is a standard, typescript is not. You're at their whims if they ever want to change anything, break anything etc. If typing would get introduced in JavaScript, I would be on that instantly. But for now, I'd rather not touch typescript
I wasn't sure if this meme worked until I saw what he was eating
javascript but more for philosophical reasons. when projects use typescript they always get focused on writing more scripts rather than optimizing HTML/CSS. Too many times I've seen overly complex scripts trying to solve what a properly arranged div and css tag have already solved.
I've been dealing with this at my job because a layout library was deprecated and is used throughout our codebase instead of proper css. Came to learn that my whole team doesn't like/know css, so they used this library that used angular directives in the html instead. We had multiple giant scripts for arranging elements in a grid that changed based on screen width
There are some cases where this is a serious issue that can't be solved through pure CSS. Once container units are finally approved though, that will solve quite a few problematic layout issues in CSS.
Aren't these already supported in all major browsers? Also I agree, but in this case we did not even need a container query, just a media query
Yes but the support is very recent and hasn't been fully accepted yet. Therefore, I can't use it in enterprise. I have to wait for full adoption.
"In own my lane"
Segment 0xA000 gang
I've been designing CPUs and writing machine code and assembly for the last month and it's been a blast.
I prefer JavaScript personally, but it's time to acknowledge that TypeScript has won. If you want to contribute and succeed as a developer in the JS ecosystem, you need to learn TS, like it or not.
I'm on the side of NoScript.
From a privacy and security standpoint, both are evil and need to die.
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've been writing my own render framework and component library for about a year now.
One thing I enjoy most about it is that the types are automatically inferred. There's a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic this, dynamic return types based on input, Class type reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).
It's all written in JavaScript with "JSDocs". It's not really JSDocs because there's a lot of recursion that's not possible with regular JSDocs. It's TS type information slipped into JSDoc comments.
But that is to setup the ability to tap into inferred types. The actual code that's written (eg: components) is fully typed check with little or no type declaration.
The reality is, no complex piece of code should be written without some form of type checking. TS isn't perfect and if there were something better, I'd move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.
The result means all my code today just runs in the browser. I don't have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it's an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don't need npm to package and release. (CodePen Sample)
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.
I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.
I'm with the guy sitting at the table
I've always felt it doesn't solve the problem people think it's solving.
Truthy
!&&
All the stuff I write is personal tools anyways so I do the same. They're small anyways.
Keen to see how this one turns out. Maybe it'll light the fire under people's asses and we'll get native types in JS finally
well, I mostly create SPAs, with big projects a type system is a necessity...
To be perfectly frank, I've only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.
I don't like blocated crap, so vanilla js es6 is the way
I'm still using CommonJS and occasionally ESM, but I always get to integrate JSDoc for weak typing in IntelliSense. It's like getting the (almost) juiciest part from Typescript without committing to it
Javascript.
Because my exposure to Typescript is wading through over-engineered and bloated Angular front ends that could easily (and should) be thrown out and re-written in html/ js.
But also because I exclusively write simple shit that doesn't have a build step for the front end, because 90% of the stuff I make gains no benefit from needlessly overly complex front ends.
Modular front end design is convenient in the long run tho
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.
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.
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.
Typescript is an abomination. Been writing JS just fine for 30 years without it.
Typescript is an abomination.
Why? (I've only used vanilla JS and jQuery.)
Not OP, but generally the arguments I've been told are:
Microsoft is an abomination (true).
"Don't make me explicitly state types; it is too confusing!" Installs 20 libraries including fucking pad left to eek out basic functionality.
Strongly typed haters are right up there with curly brace haters.
Microsoft is an abomination (true).
Reflexive MS hatred is just as dumb as any other kind of reflexive hatred. TypeScript is free and open source, so what's the danger?
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
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?
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.
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.
lol, that's hilarious. Thanks, you made my day.
Another junior with a god complex it's funny how writing an if statement make you feel like you know everything in the galaxy
Fuck typescript.
(30,27): error TS7006: Parameter 'fuck' implicitly has an 'any' type.
Error: Cannot read properties of undefined (reading 'fuck')
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.
Me, who's not in web dev:
Web development needs a whole lot of change and these kinds of fights are meaningless indeed.
What Typescript drama is there? It's fantastic. It's been an industry standard for years. In my anecdotal experience the only people that hate it are juniors who did pure JS at their bootcamp and seniors that have refused to learn anything for the last 5 years.
DHH (guy who founded Ruby on Rails) ripped typescript out of a supporting library and swapped it for JavaScript. He did it in his typical fashion of not allowing discussion and being a dick (PR only open for a couple hours and then merged disregarding all the negative feedback about the change) . So people are mad at him again.
He does stupid shit like this all the time because he’s a fucking knob.
RoR will always have a special place in my heart, but yeah... DHH sure does have opinions. What possible justification is there for removing it when it's already there? Guess someone could just shift the types out to DT.
Edit: So I read his blog post about it. He's dropping it because he just doesn't like it and he's allowed to not like it. Okay then 🤷
His blog to me sounds like he did it because it was too difficult for him to understand a few errors. Says it all.
I wasn't going to say it, but yes, 100% 😂
You only have to read the PR comments with people asking how you know if something is optional when there is absolutely zero jsdoc to know it was idiotic.
From his blog post:
By his logic, JS linters are bad because they're tooling that restricts your access to all of Javascript. But linters mean you don't have to read PRs with a fine tooth comb to make sure there's no footguns like using == instead of ===.
Also, you could use that same logic to advocate for writing JVM bytecode directly instead of Java/Kotlin/Scala/Clojure/etc.
The question is really whether tooling pays its way in terms of lower bug rates, code that's easier for coworkers to read, and code that's easier to reason about.
As a general rule, if DHH says something, the opposite probably has some true merits.
or people used to work alone never having to go back to their code (e. g. bad consultancy jobs)
Even alone I find it indespensible. I find it's mainly useful for writing code correctly the first time around.
Some people think better with typing information explicitly written out. Some people don't. In my opinion it is a creativity thing. Some people like to make art that is photo realistic, some people like to make abstract art.
I understand both viewpoints. In my free time I vastly prefer late bound, dynamically types languages with robust reflection engineers built into their interpreters. For work, I heavily prefer late bound, strictly typed with reflection optional or minimal.
Different people think differently.
I think that's fine if that's how you like to work on your own, but I'd challenge anyone to do that and write better documentation while also getting a team or whole business to do the same. A huge strength of TS is that it gives people no choice but to document their work.
I didn't say JavaScript... and I certainly wouldn't choose TS for a personal project because I personally feel that its organization is terrible but I would choose TS over vanilla js for work projects because it does produce better group work and is easier to maintain long term because of the structure imposed on it.
Haha well that's fair enough then!
TS is amazingly powerful when it comes to refactoring. I swear it practically writes itself. Half the time by the time I fix all the compiler errors the refactoring is done. I barely need to think about it which means I can spend more time thinking about the best architecture. When people say they don't see how TS makes you more productive it just makes me think they never refactor their code.
Svelte decided to ditch it because it became impractical due to the compilation step slowing down development and making debugging their compiler harder. I think for libraries it makes sense to go the jsdoc way as long as consumers can choose typescript.
Am I the only one scratching my head trying to understand why Svelte supported it at the first place?
The TS type system is not a good match for the project.
I feel like there's no typescript drama, just JavaScript drama. Things are pretty happy in the TS community. I've been writing js code since it literally first came out. I'm definitely no js hater. In the early days js code bases quickly turned to spaghetti code, but I genuinely think the js community has done miracles turning what was essentially a super simplistic toy language into a seriously good production quality language. I've seen first hand how much work has gone into it, and while most of the js community has been great with embracing change for the better, there's always been the niche of detractors against any change that adds complexity even when it makes coding safer and more productive.
I've always had a love hate relationship with JavaScript, but with typescript it's really been just straight up love. Pretty much all the trouble I have with typescript has been due to external libraries that use types lazily or incorrectly, and even then there are solutions to add safety to your own codebase. Sometimes I run into some trouble with the type system itself, but it's pretty much always because I'm doing something really complicated that would be hard in any type system. I've been working with typescript for years now and my code bases are some of the most solid ones in my company. Typescript is really safe as long as you're actually using it and not telling the compiler to ignore types through using any or making unsafe assertions.
It makes no difference to me if other people prefer JavaScript. Any important js library will get ts support anyways through definitely typed, and if a library is so sloppy it can't be typed well then it's not a good library to use anyways. Having people proudly announce they only want to use JavaScript is also great for hiring. It easily tips me off on who not to hire.
I refuse to use it because it is backed by Microsoft.
I can understand that. Does it's open source status not change anything for you?
They have a vert high chance of pulling slack.
If it's dumped under an open-source license, but still developed exclusively by one corporation, they can swap out that license pretty easily.
For what? If they took it away, the source code would still be there if someone wanted to fork it. Not to mention removing TypeScript from an application is relatively trivial.
They're not that dumb, to just pull it completely. That would obviously result in a successful fork.
Companies usually start with e.g. the BUSL, so source-available but proprietary restrictions.
For TypeScript/Microsoft, I could imagine some variation of their EEE playbook.
But really, the whole point of avoiding Microsoft et al, is that I don't want to think about, how they could fuck this whole thing up. They've proven quite creative in this regard for as long as they've existed.
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.
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.
vanilla javascript? what are you, fucking Amish?
I'd rather stay out of the frontend all together but I'd rather chop my balls off than go back to JS.
Plot twist: You are transgender and love working with JS
TypeScript of course. The compiler often times catches mistakes in variable names, API methods, whatever. So it saves time by not having to run the whole application all the time. Also the input help is much better, when the editor knows sth is a string or a number, for example.
Honestly, as a mainly backend dev wanting to do more full stack, webdev is frustratingly intimidating. I keep trying to look up best practices but there's so little in the way of consensus. "Use JQuery, no use Vue! React is better, but also React is clunky and bad. Write pure js, no don't that's a waste of time, at least use typescript." It's all such a mess and I spend so long trying to figure out what to use. I'm trying to just pick something and stick with it, but I keep worrying that I'm not doing things the best way.
I'd agree with you if you were saying this about 8 years ago, but IMO the post-jQuery-front-end dust has settled and the "best" (in terms of what most organisations end up choosing) hasn't really changed in a while.
Sure, someone may like a React alternative, and that's completely fine. But at the end of the day, most companies are using React because it's basically industry standard at this point, and it's got too much momentum behind it for that to change any time soon.
I'd say the back end is where all the choice is these days
Webpack..... Aren't you on the vite train?
We must be in different organization circles because almost every frontend I've seen at my jobs or those of my friends at other organizations uses Angular
I'll be honest, I think it's been years since I last saw anyone even mention Angular anywhere.
Maybe I'm just too used to it, but with next.js static site generation I find react to also work really well for simple sites too. If you're not dealing with state, react is basically just functions that return templated html. IMO it's pretty sleek for static websites since tsx let's you do basic templating with functions.
Don't worry, none of us are doing things the best way.
Lol yeah. Op needs to realise we are just throwing shit at the wall and waiting for the next new tool we have to learn this week
As a previously front-end gone full-stack gone and settled in backend/infra... don't bother. But if you have to bother, or really, really want to 🙂, pick a relatively popular thing (e.g. Vue), and learn that, ignore the rest. By the time you come up for air the new hotness will have changed anyways, and the wheel will have been reinvented twice. It's a moving target, just learn the fundamentals with something and you'll be good to go.
Wait until you meet "Platform Engineering"/DevOps. The sheer amount of CNCF projects and new tools out on a daily basis are on par with the JavaScript world.
If you just want to try frontend, not trying to get a job there are these frameworks you should try:
And i think everyone should use either Typescript or JSDoc for any bigger application.
Svelte is a happy middle ground between vue/react and SolidJS which is maybe too bleeding edge still
Agreed on the svelte part.
But I think solidjs has a real chance of taking over React, because its similar, meaning JSX and hooks, but without the footguns. After using React, its so much cleaner and easier to work with, i cannot recommend it enough.
Thanks for recommending it, it does look really nice. I'll definitely check it out when a fitting project comes along.
For sure don't use jquery.
React is industry standard, but not my favorite. That being said, even my personal projects I do in react. I'm happy with my current role, but if I wanna switch down the line there's less openings for a dev with mostly Svelte (my favorite framework) experience.
Right now I'm working on a personal project with Vue because it happened to be the one I was hearing most about when I started. I've got one project that I'm definitely gonna finish at some point started in react, so maybe I'll try out svelte on my next project.
jQuery is obsolete and insufficient if you're looking for an easy monolithic framework. Angular, React and Vue are all good (disclosure, I haven't used react), just pick one and learn it well and you'll have a good foot in the door. If you already know JavaScript and don't want to learn typescript, Vue can be used with plain JavaScript.
Where'd you get your time machine, that you obviously would've needed to set to 2008 to find anyone actual recommending jQuery?
It's still the best API for imperative access to DOM.
Do you need to support 15 year old browsers? Practically all the jQuery features I used (which was a lot) are now available in standard js
Even if you do, you can still use most modern js features with transpilation.
Yes, the features are there. Just the API is still horrible.
As an example, make a hidden element visible (extremely common imperative operation).
jQuery:
Native JavaScript:
I hope you'd agree that the native JS is certainly not an example of good API.
That's actually a great example of the shortcomings of jQuery. There are multiple ways to hide an element yet they standardized on one that often wouldn't work.
Also you're using an ancient method getElementById... I think visuals should still be controlled with css. So what is the right way to do that in modern js? document.querySelector('.some-name').classList.add('hidden') with that class defined in the css, with whatever makes sense, including maybe a css transition.
It's the most common one. And it's not like you can't hide the element with some other mechanism with jQuery.
And? What's the difference from
document.querySelector()when querying for ID?What is the right way is context dependent. I don't see how having extra
.hidden { display: none; }boilerplate is somehow modern or superior.Your code reads like it's from 1992 mainly, which makes sense I guess, given that you still find jQuery better than modern vanilla js. jQuery was created as a way to account for browser support challenges but is now obsolete. Anyhow, if I read "getElementById" in recent js code I would assume something was weird about that code. It's old hat and there is rarely a reason to use it.
Precisely my point. Which is why I think it's opinionated in a bad way to arbitrarily pick one of them as the defacto. I often had trouble with jQuery's .hide() method because while it felt natural to use it, it often conflicted with what actually needed to happen for good UX.
What you're missing is that the hidden class can contain anything you want. Animations or whatever else. In other words, the idea that there is a "right" or "most common" way to hide an element is flawed at its core.
Lol. You write a lot of text to mask the fact there's no good reason why
getElementByIdshould be bad. It's the same groupthink as with the jQuery, you're told it's bad, so you just follow the crowd.That was one of the reasons. The other was that DOM API was and still is crap. There were many such libraries to abstract away browser differences back in late 00s (Dojo, script.aculo.us, Prototype.js, MooTools), and the main reason jQuery "won" was that it provided the nicest API.
You're missing the fact that jQuery does not prevent you from hiding the element in other ways. It's just optimizing for the most common case, which is one of the principles of good API.
Sure, and when I just want to ... hide it, without any animations? Then this hidden class is boilerplate only.
I mean you're coming across like more of an old man than I am and that's saying a lot more than you know. For the first 2 years people shit talked jQuery I didn't agree with them. And then I got the opportunity to work without it and it seriously took like 3 days to completely change my mind. And all my pages were I believe about 100KB lighter.
jQuery is trash. And that doesn't mean it wasn't a great tool for its time. It's truly obsolete now though. If you hate the native JavaScript stuff so much.. I dunno maybe go work with Java or something?
Just fluff, no real arguments, ok.
I sure am glad I don't work with a moron like you who would ship a fuckton of JavaScript to users because they're too much of a pussy/old fuck to use modern practices
Why would you not want to be using a rendering library? Your code is basically storing your application state in the dom which will turn into a horrible mess as soon as you reach any actual level of complexity. I know first hand. I'm traumatized from having to maintain large jquery code bases in the 00s. No serious professional writes code like this anymore.
Also, your vanilla code isn't modern. It should look more like this:
I could see not wanting to use a rendering library if you're building a simple site on top of basic static HTML, but that's not a serious discussion for industry professionals, and even still, jQuery is such a heavy dependency for saving some characters. If you find yourself using it so much you need the extra convenience then your site is already complicated enough that you should be using a rendering library with state management instead.
Because it's just not very useful in some contexts. I've seen web extensions which mostly query the current page, and it doesn't render much or even anything.
Not all pages are SPAs either. Many apps are the old request-response with some dynamic behavior sprinkled on top. jQuery covers that well.
This model is also quite compatible with the rising HTMX where the state/rendering is driven from backend and you just insert few dynamic pieces with JS.
There's no difference between
document.querySelector("#element")anddocument.getElementById("element"), they're both same level clunky.Also, what you wrote is not functionally identical.
$el.show()is idempotent, theel.toggle("hidden")is not (as the name suggests, it toggles a class). It also needs an extra boilerplate class.There are plenty of non-professionals doing web stuff and I think it's great!
jQuery is 24 KiBs (minified, gzipped), that's a good price for the egonomics it provides. If you're constrained, there are API-compatible alternatives like cash which go down to 6KiBs.
The main issue is that frontend is complicated and it can do a lot of very different things. Frameworks exist to solve some issues that may or may not exist in your project.
Best practices are pretty straight forward in the typescript community. Frankly I think all the serious professionals from the JavaScript community just went to TS so the people left over that didn't migrate are well...
React and typescript. If anyone tells you otherwise, ask them where they work.
Typescript is great for catching long standing bugs in old legacy JS.
Me: 2024 is finally going to be the year of WASM, boys!
And then there's me, missing flash :(
Flash and AS3 was so much fun to work in. I completely understand why the industry moved away from it but even today we have yet to fully catch up to all the media animation and programmatic features it provided all in one. RIP.
I still have a hobby website with an AS flash animation on it that I don’t have the heart to get rid of. It was so cool.
Have you tried porting it to Haxe? It's what I found whose selling point was "programming for those that know AS3"
Thanks, I will look into that
You could use something like Ruffle. Newgrounds also uses it to allow people to play flash games.
Thanks, will check it out
That's awesome.
But I'm picturing you keeping a retro computer to load it on and enjoy it.
Starfield has a bunch of AS3 and Flash files. I've been hacking it all week.
And, uh, I use vanilla JavaScript with Typescript checking via JSDocs.
I just wish WASM could replace JS rather than merely augment it for non-DOM work.
You can have frameworks which fully generate the JS DOM code for you, allowing you to write complete single-page applications without writing a single line of JS.
I'm using the leptos framework (Rust) and really like it so far. Not a single line of JS, not even npm as a dependency in that project.
Yep, that's the framework, I'm using, too. But most frameworks in the Rust ecosystem can do DOM interop, as the heavy lifting for that is provided by the
wasm-bindgenlibrary.Unpopular opinion: I hope it's going to be a flop (apart from the few use cases where it does make sense). The limitation of having just JavaScript ensures level of interoperability which is IMHO one of the big advantages of web as an application platform. If WASM becomes successful, it will fragment the web.
I definitely feel you. Not sure WASM is the answer, but it’s still neat.
I think there's a positive coming from this competition, though. Apparently this infighting has re-lit the want for type annotations to be embedded in vanilla JS (ECMAScript proposal). I feel like this would be the ideal scenario: things working right out of the box without needing a compile step or additional tooling.
You can get as close as it gets to this experience by using alternative runtimes such as Deno or Bun, which have native TS support (meaning you can just execute a .ts file without having to transpile it), but of course as soon as you have to write code for a browser you are back in the middle ages.
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
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.
It's just annotations. No proposed semantics of a type system which your browser could check on its own.
Uhhh, typescript devs? Enums were useful once, but typescript evolved everything else around it and these days using direct values is actually far better.
And I don't think anyone uses Namespaces other than for defining external modules.
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.
Yeah it’s interesting because JS is interpreted, not compiled. The proposal allows for type annotations in the syntax but no actual interpreter consequences. On the one hand that makes sense because otherwise you’re in the territory of runtime type-checking which would be a huge performance hit and would sort of defeat the purpose of static types anyway. But that means you still have to rely on your IDE or a linter for this to be useful.
I don't see any practical use case for it as is as anyone wanting to use them would want the full TS feature set anyways, 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.
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.
Typescript may have a million problems that make getting into it annoyingly hard and even seem pointless, but once it's settled in your project and used well... Damn is it fucking good.
And I'm saying that even though I had to disable intellisense and most of those advanced features because the project I work for is too large and typescript would easily use over 20GB of RAM and get my computer to freeze.
But if you're trying to use it like a traditional typed language, you'll only see the bad side of it and you'll certainly hate it.
Tell me you're a dinosaur without telling my you're a dinosaur
Telling me you have nothing to contribute without telling you have nothing to contribute.
typescript is a bandaid on a severed leg
More like a tourniquet and a prosthetic. It doesn't solve the underlying problem, but it's the best solution we've come up with.
I view it more like a powered exoskeleton around a blob fish. IMO static typing is way more valuable than strong typing and I'd take static typing only over strong typing any day if I can only choose one.
MyPy for Python hides in the bushes. https://imgflip.com/7yinbx.jpg
image not found :(
Mypy is just okay. Haven't used TS to know the dark corners there, but any type system that's bolted on to the language is going to have dark corners in the best case.
It's better than no type system, however. I remember when typed languages were "bad" because it "slowed you down" and "wasn't necessary if you know what you're doing"... how naive I was when I repeated those words so many years ago :)
My issue with typescript... and, correct me if I'm wrong... is it doesn't exist without Javascript. Typescript needs to be compiled down into Javascript to be run. It has no stand alone interpreter (that I'm aware of) and definitely not one baked into web browsers or NodeJS (or adjacent) tools. In essence, Typescript is jank sitting on top of and trying to fix Javascript's uber jank, simultaneously fracturing the webdev space while not offering itself as a true competitive and independent language for said space.
That's my amateur two cents for what it's worth.
The fact that TypeScript doesn't attempt to obfuscate JavaScript, and just fills in the gaps, is what makes it the best solution to the problem.
It's not a separate language, it's Javascript tooling
I've used JavaScript since its creation. I would describe typescript as JavaScript as it should have been. I've always actually liked JavaScript's simplicity, but I've never liked its lack of type safety. At its core, JavaScript has a tiny conceptual footprint, and that's actually pretty refreshing compared to other very complicated languages. But it was plagued with terrible implementations and the inherent messiness of dynamic typing. I've watched it evolve over the years and it's improved beyond my greatest hopes. Between the advent of transpilation, tooling, and typescript, I'm very proud of where the language has gotten to. Having made websites in the 90s and 00s, I feel like people don't realize how much work has gone into getting the ecosystem in a much better place.
I don't think it really fractures anything considering you can call a ts package from js without knowing. The other way also works with third party typings in DefinitelyTyped.
It really just adds a bit of extra type info into js, looks like js, and transpiles into js that looks almost exactly like the input, including comments and spacing and such if you like, so there isn't any lockin.
There isn't any competition, it's just an extra optional tool for the js ecosystem in my eyes.
The transpilation that typescript does doesn't really have anything to do with typescript, it's just there because typescript wants to support the latest ecmascript features, so transpilation is necessary for that, but technically you could simply strip out the type info and have another transpiler like babel handle the backwards compatibility. I think there are a few minor exceptions to that, like enums. There was even a proposal to add some typescript types to native JavaScript that would be ignored by the interpreter and just act as comments.
I mean, tsc without any of the backporting functionality is still a transpiler since it goes from a high level language(ts) to another high level language(js). Transpilation as a concept doesn't imply that it is for backporting language features or that the source and destination languages are the same, just that it is a transformation from source code to a similar or higher abstraction level language source code
Yes, it's still a transpiler, I'm not saying it isn't, but what I mean is that it doesn't add any functionally specific to the typescript language. There's a transpiler for TS that doesn't even do any type checking at all and just does the type stripping and back porting. But of course, that's not why people use typescript. All the features that are actually important to typescript could be done through a linter instead. If type annotations were added to JavaScript you could get most of typescript's features with linting rules and just handle back porting in a more standard way.
I think too many people ITT are conflating Typescript with Typescript frameworks like Angular.
As a professional with 25 years of experience I agree with you. The entire modern architecture was created by people who don't like simple things that work. I'm pretty sure there are a couple of high ranking master developers sitting at the head of W3C competing to create the most convoluted system possible.
You are correct.
That says I would never ever EVER start a project without TS.
It's like coding with hands vs coding with your elbow.
I also don't want to compile my C++ code myself. I'm pretty happy with letting a compiler do it's job...
I really don't get how people can feel more productive in JavaScript. With typescript the code practically writes itself. Sometimes when refactoring I'll change a functions input and output signature and just fix compiler errors until it stops complaining, and the code just works without me having to really even think about what the code is doing.
Any time I'm forced to go back to js I feel like I'm going crazy trying to keep track of what's in all the variables. With typescript I can use more powerful object structures without having to constantly double check where they came from.
Just fyi, while they don't help with running TS in the browser, the Bun and Deno runtimes both natively run TS without any compilation.
That's not true, deno compiles TypeScript to JavaScript, it just does it transparently. The code still runs on v8.
V8 also doesn't run js, it does some byte code compilation stuff amongst other things, then interprets that. But that's all a bit pedantic too, V8 runs js, deno runs ts.
fwiw https://deno.com even has as one of their first bullet points that they have "native support for TypeScript and JSX"
Sure, but part of the claim was "without any compilation". But bun/deno do compile TS into JS.
What we really need is a browser that runs something other than Javascript. Until then, stack of jank it is.
WASM?
Is that a standalone thing? This is obviously not my specialty but I thought it was part of Javascript.
I've never worked with it and don't know in detail, but it lets you compile several languages into web based client/server code (basically, converting other languages into website code). Works with C, C++, C#, Go, Rust, Swift, etc)
I agree.
I'm a hobbyist. I don't work on really large or complex projects. I just want to get the most productivity for my spare-time-dabbling and having tried a few times to get into typescript it seemed to create more "extra steps" for me than it saved.
Typescript doesn't have strong typing but static typing still gets you really really far. It means you need to be more careful with your io and avoid dangerous type assertions, but I don't think that's a bad thing. Having used typescript an absolute ton, the only real jank I've encountered is from bad library typings that either use it lazily or incorrectly, but for code bases that use it through and through it has been smooth sailing, and having professionally used both traditional static typed languages and dynamically typed languages, I really enjoy typescript's type inference and structural typing. I think you should give it an honest try before judging it. But that's just my 2 cents as an industry professional who has used many languages and have been programming for decades for what it's worth.
Like 2023 CoffeeScript?
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...
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.
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.
But a statically typed language would catch those errors before it even compiles...
The fact it doesn't need to be compiled is also a big reason why it's used on the web.
But I absolutely agree. I'm not a fan of dynamic typing at all.
Si you say I should use python for websites?
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.”
Unsafe rust is your best bet.
They used to be more attractive around the 2000s, before type inference became commonplace and when IDEs/editors were still a lot less powerful.
As for making a dynamically typed language, to my knowledge, they are actually easier to create than statically typed languages...
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.
I’m not on Twitter, what’s happening?
https://youtu.be/5ChkQKUzDCs
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 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.
HTML + CSS. No need for any of that newfangled "*script" bloatware / malware.
If it fits the need...
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)
I like TypeScript for its types and type-checking, but I also want to write JavaScript to avoid having a local build step, and having to wait for things to transpile/compile/etc when running locally. I have a pretty large project where I've gotten both worlds by just using JSDoc and only using TS for type-checking. VSCode still offers built-in type-checking with JSDocs and ofc the type-checking can also be run separately if needed.
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).
Scala can also compile to JS.
Best place to learn it?
Kotlin Koans is a good hands on intro, especially if you're already familiar with Java.
Kotlin for Javascript
What's happening?
Same question
If js docs are a good working replacement then I can understand wanting to avoid all the annoying issues with typescript. I haven't used it before but it seems less flexible and more verbose, what's other people's experience with it? I'd have to check it out myself but for the moment typescript makes JavaScript a little more bearable.
Javascript is a standard, typescript is not. You're at their whims if they ever want to change anything, break anything etc. If typing would get introduced in JavaScript, I would be on that instantly. But for now, I'd rather not touch typescript
I wasn't sure if this meme worked until I saw what he was eating
javascript but more for philosophical reasons. when projects use typescript they always get focused on writing more scripts rather than optimizing HTML/CSS. Too many times I've seen overly complex scripts trying to solve what a properly arranged div and css tag have already solved.
I've been dealing with this at my job because a layout library was deprecated and is used throughout our codebase instead of proper css. Came to learn that my whole team doesn't like/know css, so they used this library that used angular directives in the html instead. We had multiple giant scripts for arranging elements in a grid that changed based on screen width
There are some cases where this is a serious issue that can't be solved through pure CSS. Once container units are finally approved though, that will solve quite a few problematic layout issues in CSS.
Aren't these already supported in all major browsers? Also I agree, but in this case we did not even need a container query, just a media query
edit: https://caniuse.com/css-container-query-units about 85% of users have browser support for container query units
Yes but the support is very recent and hasn't been fully accepted yet. Therefore, I can't use it in enterprise. I have to wait for full adoption.
"In own my lane"
Segment 0xA000 gang
I've been designing CPUs and writing machine code and assembly for the last month and it's been a blast.
I prefer JavaScript personally, but it's time to acknowledge that TypeScript has won. If you want to contribute and succeed as a developer in the JS ecosystem, you need to learn TS, like it or not.
I'm on the side of NoScript.
From a privacy and security standpoint, both are evil and need to die.
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've been writing my own render framework and component library for about a year now.
One thing I enjoy most about it is that the types are automatically inferred. There's a lot of Typescript wrangling going on, and it gets really deep into what TS is capable of and barely capable of (polymorphic
this, dynamic return types based on input,Classtype reconstruction, mixins that influence both static and instance properties, event listeners based on event name, typed property watchers based on property name).It's all written in JavaScript with "JSDocs". It's not really JSDocs because there's a lot of recursion that's not possible with regular JSDocs. It's TS type information slipped into JSDoc comments.
Ridiculously complex core Class
But that is to setup the ability to tap into inferred types. The actual code that's written (eg: components) is fully typed check with little or no type declaration.
Declarative-style component with almost no explicit typing
The reality is, no complex piece of code should be written without some form of type checking. TS isn't perfect and if there were something better, I'd move. Alliances are stupid. There are problems with some things that have not been, and likely will never be, fixed. But what type-checkers should do best is infer types dynamically.
The result means all my code today just runs in the browser. I don't have to wrangle builders or compilers (bye Webpack!). At most, I use just esbuild to minify, though it's an optional step, not a mandatory one. If I want to mess around on Codepen with my library, I can refer to a git commit directly and load the file. I don't need npm to package and release. (CodePen Sample)
I haven't managed to break into the JS-adjacent ecosystem, but tooling around Typescript is definitely a major part of the problem:
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.
I’m idealistically/philosophically committed to a Purescript Halogen front end with a Haskell Servant backend, biatch. Maybe someday I’ll get WASM in there. One thing I will not do is use TS or JS.
I'm with the guy sitting at the table
I've always felt it doesn't solve the problem people think it's solving.
Truthy
!&&
All the stuff I write is personal tools anyways so I do the same. They're small anyways.
Keen to see how this one turns out. Maybe it'll light the fire under people's asses and we'll get native types in JS finally
well, I mostly create SPAs, with big projects a type system is a necessity...
To be perfectly frank, I've only seen the drama on social media platforms. Outside of this one library Ive hardly seen anyone trying to fight typescript in the professional community.
I don't like blocated crap, so vanilla js es6 is the way
I'm still using CommonJS and occasionally ESM, but I always get to integrate JSDoc for weak typing in IntelliSense. It's like getting the (almost) juiciest part from Typescript without committing to it
Javascript.
Because my exposure to Typescript is wading through over-engineered and bloated Angular front ends that could easily (and should) be thrown out and re-written in html/ js.
But also because I exclusively write simple shit that doesn't have a build step for the front end, because 90% of the stuff I make gains no benefit from needlessly overly complex front ends.
Modular front end design is convenient in the long run tho
When I write JS:
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.
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.
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.
Typescript is an abomination. Been writing JS just fine for 30 years without it.
Why? (I've only used vanilla JS and jQuery.)
Not OP, but generally the arguments I've been told are:
Microsoft is an abomination (true).
"Don't make me explicitly state types; it is too confusing!" Installs 20 libraries including fucking pad left to eek out basic functionality.
Strongly typed haters are right up there with curly brace haters.
Reflexive MS hatred is just as dumb as any other kind of reflexive hatred. TypeScript is free and open source, so what's the danger?
I’ll be downvoted again but I agree.
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
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?
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.
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.
lol, that's hilarious. Thanks, you made my day.
Another junior with a god complex it's funny how writing an if statement make you feel like you know everything in the galaxy
Fuck typescript.
(30,27): error TS7006: Parameter 'fuck' implicitly has an 'any' type.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.