How can you even form an opinion on this if, as you stated in that thread, you literally have no idea what typescript is and are just a beginner in js? You got down voted for saying typescript is unnecessary without even knowing what it is or what the thing you’re working with’s limitations are, which is a pretty objectively braindead stance to take. You’re a beginner js developer, you have no idea what you’re talking about when it comes to preferences of ts vs js, just that all of the beginner level stuff you have tried to do works in js so therefore typescript or frameworks must be unnecessary
if you’re a beginner, and you post an opinion and lots of people say that many years of professional experience make them disagree with you, why would you not take that on board? I wish you well on your learning journey. at some point you’ll outgrow vanilla js and you’ll have learned enough to configure transpilation and webpack etc. it’ll be a good day.
The fact that you're doubling down on your ignorance is quite problematic. Typescript is not an enterprise system that forms arcane JS. It's literally JS with a slight adjustment that allows you to say "also this is this type". You write JS the entire time and can "disable" the typescript at any location you need to not be typed.
After this and saying that you’re a beginner to JS, I would instead suggest spending time to develop perspective from a place of knowledge and experience rather than… I guess, being proudly ignorant?
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.
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 many 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.
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.
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.
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 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.
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 deno.com even has as one of their first bullet points that they have “native support for TypeScript and JSX”
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.
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.
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.
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.
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.
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.
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.
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 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 generally agree with the statment under that image and it’s certainly a funny meme but also Illegal, sadly the enforcment is a joke but that’s not really the laws fault!
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.
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.
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
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.
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.
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.
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.
I’ve used all 3 although, not very much Angular so I don’t have much to say on it. Vue is the easiest to learn imo. It bundles in routing and state management so you don’t have to worry about picking supporting libraries for this. It’s a pretty standard template style with lots of helpers and some magic going on behind the scenes. React is better if you want to write JavaScript. I prefer it for this reason.
Curious if you’ve used next with react. React itself has a scope rendering design goal and leaves the rest of the app to the community, and next sets up all the stuff around it for you and I think they did a really great job with the defaults they close, and it’s still fully extendable.
Yup! Next is the most mature and complete framework for React. If I need SSR and/or SSG with hydration, it’s my go to for now. It adds some complexity, so it can be overkill if you don’t need these things. My experience working with it has been excellent.
It can be overkill if you need something simple that doesn’t match next’s defaults, but if the default settings of next work for your use case I found the base project setup very simple to use.
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.
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.
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.
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.
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?
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
So far they didn’t complain. My manager is all praise too ;-) It’s kinda weird that I’m supposed to be the asshole for not being hateful of a technology. But you the hater are the nice guy?
The things is, I don’t diss on technologies without arguments. I’ve grown to recognize that they are tools, not a subject of passion, at least in a professional context.
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.
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…
programmer_humor
Hot
This magazine is from a federated server and may be incomplete. Browse more on the original instance.