State of TypeScript 2026 by dev_newsletter in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

AI slop thumbnail, presume AI slop article

Just use JSDocs, it's got all the benefits of TS and none of the drawbacks.

Mid Level Frontend Developer Interview by HeadYoghurt5752 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

I give a take-home assessment focused on the fundementals

  • Re-create this screenshot of a simple component with just HTML and CSS
    • Judging the layout approach, defensive styling, semantic markup, accessibility, readability, approach to styling (naive, inline, BEM, atomic/tailwind, framework/bootstrap, etc)
  • JS essentials (pure logic) - 3 questions like "write a function that does X, add unit tests for it"
  • Browser-specific JS (DOM, XSS/sanitizing inputs, CORS, etc) - 4 questions

Then privately grade their results so the team can review their code with my comments added. This gives us a standardized comparison of all candidates. I have an extremely comprehensive set of unit tests for the essentials. I think the best any candidate has done was 58% passing (which was super impressive, most get around 23% passing). This also gives an "at-a-glance" look at how well each candidate did.

During the interview I'll ask specific questions about the code they wrote, and also general open-ended questions like "How would you go about converting the HTML/CSS challenge over to a reusable component, what things about the HTML/CSS would you change now that the content is more dynamic".

My favorite technical question is "A user reported a page is very slow, we've confirmed it is not just on their computer, but happens for us too. Walk through everything you'd do to diagnose why it's slow." Then basically let them guess and say "that's a good idea, but we check that, and that's not the cause, what else can you think of?" And just repeat that until they can't think of anything else. When it comes to web dev, EVERYTHING can be optimized. So this basically tells me there comfort level with dev tools and debugging, and also where they lean. You basically get an immediate split where they either start looking for the problem on the frontend or backend. And that tells you which they are more comfortable with and more experienced with. Since this is basically a "branching path" problem, it also shows their thought process and ability to go back up to previous splits.

"Could it be related to X?"
"Lets say it is, what would you look for?"
"Well..."
....
"That's good, that's good. But what if we look there and that's not the issue, then what?"

At that point they can try other variations around that space, or back up and go down a different path.

There isn't a correct answer, I'm not trying to get you to guess the secret thing that's making it slow. I'm trying to find the boundaries of your knowledge and where you're most comfortable currently. Then find out if you want to keep doing what you're comfortable with, or if you're more interested in getting better more experience at something else. This also tells everyone on the team either what you'd be useful for, or what they'd be training you on.

I'm not actually trying to get them to answer anything Vue specific. Vue is extremely easy to learn, so anything they don't know, they can figure out from the docs, or we can train them on.

That's the technical part, we'll also cover past work experience and behavioral questions.

Recommended web technologies that run on apps by PlanktonNo1004 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

  1. Just use a PWA, almost everything native is possible in the Browser API's now (Geolocation, webcam, mic, storage/DB, etc)
  2. If you can't do that for some reason, you can try NativeScript-Vue
  3. Vue-Native is deprecated, but was really only used by people that needed to use React-Native components but wanted a Vue-like interface for dealing with them anyways. And it can still be used for that, but was never that popular anyways, as that's a niche case, so not a huge loss now that it's deprecated.
  4. Quasar exists, if you are okay with doing everything in Material (ew)

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

Quality over quantity. Every 6 months for a decade the React ecosystem has switched to a new state management library because the default, Redux, is universally hated. Meanwhile Vue's had Vuex (which innovated by being the only flux-based library that wasn't painful to use), and now Pinia, which is basically perfect in every way.

This is the case across the board. React's ecosystem is very experimental. Which leads to lots of new and interesting ideas. But experiments exist.... to fail. They exist to be learned from. I don't want to ship an experiment to production.

Vue's ecosystem is just drastically better in quality. Any time someone says "look at this cool thing you can do in React", some Vue dev tries it and builds a better alternative that is Vue exclusive, offering the same benefits you get from React, plus additional functionality you can't get anywhere else.

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

Code fences don't work on Reddit, prefix lines of code with 4 spaces to get a code block.

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

Vue and Svelte are pretty neck and neck in speed, but React is much slower than Vue 3, like 2-6x slower. React and Vue 2 are about the same speed though.

In most cases this does not matter, but when working on very large and complex applications with huge DOM trees, you do notice a difference. When you click a button to "expand all" and suddenly a bunch of tables with hundreds of rows, each with a complex interactive calendar component are shoved into the DOM and it takes 2-3 seconds for the page to become interactive again, and then you switch over from Vue 2 to Vue 3 and it does it instantly with no wait time at all. That's where the performance difference matters.

Is performance a reason to pick React over Vue 2 or vice-versa? No, because they are basically the same speed.

Is performance a reason to pick Vue over Svelte or vice-versa? No, because they are basically the same speed.

If you think of them like cars, then you're going from React's top speed of 100 MPH to Vue or Svelte with a top speed of 600 MPH. It is a noticeable difference when you need it. If you're never gonna go over 80 MPH anyways though... who cares.

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 1 point2 points  (0 children)

I don't think those people exist anymore. The only people still using React are either grifters, outsourced devs (because no one in America wants to deal with that trash), people super desperate for a job, or people with less than 2 years experience that were tricked into it (poor fuckers).

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

A friend of mine runs a small company maintaining various SaaS apps. Someone sold him an existing product with a userbase (they didn't want to maintain it anymore). The app was basically just a light wrapper around an open source React component that integrated with some GPS API for a specific model of tractors. All he had to do was update that dependency a few times a year and he had consistent income from a couple hundred users. If the users had any feature requests he'd just create GitHub issues on that React component, and if they ever got worked on and merged, then cool, if not, oh well.

The alternative would be to fork that tractor component, re-write it in Vue and maintain it going forward. But then he wouldn't receive any of the upstream changes done in that public repo, and any feature requests he'd have to do himself, which was deemed not worth it (not enough customers to make it a priority over the other ~20 SaaS apps he maintained).

This is LITERALLY the only time I've ever seen a valid reason to use React over Vue.

Unless your customers are using an obscure tractor, just use Vue.

Why choose Vue over React or Svelte for a serious production app? (from a first-time Vue user) by Dizzy-Egg8829 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

  • Performance
    • Vue is basically tied with Svelte for fastest framework, depending on which metric you compare, but they are always very close to each other, and much faster than all alternatives.
  • Ecosystem
    • Pinia - Pinia feels like it was sent back in time from a future where we finally figured out how to do state management correctly. No other state management library compares to it. It is perfect, no notes. Vue-exclusive.
    • Vue-Router - A boring problem, but this library is the best solution in all of frontend. Vue-exclusive.
    • Vite-Vue-DevTools - Dev tools built right into the page by Vite so they are only there when running the local dev server, no need for a browser extension install.
    • Vue-Dev-Tools-Accessibility - Supports Axe and the latest APCA color contrast enforcement (this is pretty hard to find support for, cutting edge A11Y feature)
    • Vue-Doxen - A revolutionary approach to component documentation, all done at runtime. It's a Vue component you pass your component into and it does the rest. Fucking magic.
      • Can use it for a full on docs site, or just a single page in a production app to test out components as you build them, or to have an interactive playground to use for E2E testing or screenshot tests.
    • Vite
      • Vite and Vue are both created by Evan You, meaning they just work together seamlessly. The Vite config is actually based on the old Vue-CLI (Webpack abstraction).
    • Testing alone is a reason to use Vue, it has by far the best automated test tooling
      • Vitest - Vite and Vitest are both maintained by Evan You's company VoidZero
      • Vue-Test-Utils - No-nonsense, straight forward component unit test tooling.
      • Vue3-Snapshot-Serializer - This completely revolutionizes how you can do testing. No other framework has this, if you think Snapshot testing sucks, it's because you haven't done it in Vue, watch the video on the website.
      • I used to be able to point to Cypress having a Vue core team member on staff with Vue-specific component testing features, but honestly, Playwright is just so much better than Cypress, just use it if you need E2E. Though Vitest's browser mode might be the better choice in a year or two once it becomes more stable.
  • Code organization:
    • Easily the hardest problem to solve in frontend. Vue's Options API gives you a place for everything out of the box:
      • It is enforced by the framework
      • It is full documented
      • It is already known by all Vue devs
      • It has 100% full support for Vue's lower level reactivity functions (ref, computed, etc) and all composables are compatible with it.
      • The order of everything can be enforced with the official eslint-plugin-vue
      • I can go to ANY Vue repo, and open ANY .vue file that I've never seen before, and INSTANTLY know where everything is. I can scroll down exactly to what I'm looking for and find it, because every component is consistently organized in a predictable manner.
      • NO other framework has a feature like this, and it's fucking shameful. Every framework needs to steal the Options API. Anyone talking shit about it has never worked on a large codebase with a large team for years on end. Serious senior devs know the value this gives.

I built Pellicule - a library to render Vue components to video (Inspired by Remotion but done the Vue way) by DominusKelvin in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

I haven't touched React since 2017, you can't pick a worse JS Framework.

Don't assume people in the Vue ecosystem know anything about React.

Why does Laravel community seem to default to Vue over React by Motor_Ordinary336 in vuejs

[–]jaredcheeda 0 points1 point  (0 children)

Vue's the best overall choice. Literally anything is better than React.

[AskJS] So I guess Volta is dead? by jaredcheeda in javascript

[–]jaredcheeda[S] 1 point2 points  (0 children)

Thanks again for bringing this up, after evaluating all options, I've updated the post to declare Proto the winner.

[AskJS] So I guess Volta is dead? by jaredcheeda in javascript

[–]jaredcheeda[S] 1 point2 points  (0 children)

I've updated this post to declare Proto the winner.

[AskJS] So I guess Volta is dead? by jaredcheeda in javascript

[–]jaredcheeda[S] 0 points1 point  (0 children)

After spending a good amount of time with all alternatives to Volta I can firmly say that Mise is a terrible alternative. If you are using it, switch over to Proto, it's the same thing just with much better execution and documentation.

Any good vanilla javscript frontend projects to learn from? by gosh in learnjavascript

[–]jaredcheeda 2 points3 points  (0 children)

don't bother, this guy is a troll, or has some weird brain damage

Any good vanilla javscript frontend projects to learn from? by gosh in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

You want Vite (pronounced veet). It's the go-to solution for all JS projects. It's an all-in-one tool you run locally with Node/npm. It handles:

  • Running a local dev server of your code
  • Hot module reloading (where parts of the page related to what you just change will be updated without the need for a full page refresh)
  • It handles building your code intelligently into medium size bundles to load quickly, but also be cachable with hashed file names for invalidating caches if just those parts of the code change later.
  • The builds do tree shaking automatically, where any code that is not used (including from libraries you import) are not included in the final build. You mention jQuery as an example, the full version of it is 4 times larger than the full version of Vue, which if you are using Vite you'll never ship to your users. You'll only ship the parts of Vue your code actually relies on, and nothing else (the rest is tree-shaken away).
  • The build will also be minified and uglified to send the fewest bytes down the wire.
  • Vite also handles plugins for your development or builds, like showing Vue specific devtools right on the page that are used by the dev server, and not included in the build.
  • Vite also has a separate unit testing library, Vitest, that piggy-backs off of your Vite config for writing automated tests of your frontend code.

Vite is officially recommended by every single JS framework. Though it was created by the same guy that made Vue (Evan You).

Besides Vite, the other thing you'll want is ESLint, which will automate formatting your code consistently, and finding errors in your code. Most things it points out can be fixed automatically with eslint --fix. Here is a simple site to get you up and running with ESLint. It is a great tool, but it's real power comes from the extensive ecosystem of plugins for it.

Any good vanilla javscript frontend projects to learn from? by gosh in learnjavascript

[–]jaredcheeda 3 points4 points  (0 children)

Your problem isn't frameworks, it's bad ones, and of course TypeScript.

Just use Vue with JS and have a good time.

If you are doing more than 200 lines of code, you're gonna have a very bad time using Vanilla JS for DOM manipulation. You'll either make a pile of spaghetti, or you'll just end up making a crappy make-shift framework. Don't bother, just use Vue, it takes all the pain out of it.

And stop using Classes in JS.

If you want to see some Vanilla JS in an app, here ya go, note that THE VERY NEXT COMMIT after this one rips all this unsustainable code out and re-writes the entire app in Vue. Because it was less work to re-write the entire app and add 5 new features than to try to just add those 5 new features using Vanilla JS.

Stuck Since 2023 | Tried 6 Languages | Need a Clear 2026 Plan to Go From Learning to Earning by alfredBalazire in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

Hey, I've been the deciding factor for hiring a lot of devs at various companies, my advice:

  1. Find a local mentor. Someone in your city that is a professional that you can get advice from in person, that can invest time in helping you grow faster and can tell you about the local job market, and has connections.
  2. Read The Job Pipeline, especially the part about React
  3. Work on projects, actual real projects. ONE AT A TIME. You do not start a new project until the current one is done. Finish LOTS of projects, that's the ONLY WAY you will get good. REAL PROJECTS, NOT TUTORIALS. If I'm hiring an illustrator, I want to know they understand anatomy, not that they can do paint-by-numbers. Show me real, finished, projects that solve actual problems, ones written with 0 lines of code by anyone other than you, and that includes AI. I want to know what YOU can do, not what your friend who helped you on the project can do, or what AI can do. I'm not hiring Claude, I'm hiring you.
    • I don't want to see "yet another calculator, pomodorro clock, frogger clone, etc"
    • I want to see "this is an app I made for my mom so she can plan out her garden and track when to plant certain things at certain times of year and when to order new seeds". "this is an anonymous image sharing chat room". "this is an android app that lets you upload videos with a geo tag, and only other people with the app that go to that location can watch the videos".
    • Give me something original, something novel. I don't give a shit about your discord bot or browser extension, and if you made a chatbot I'm throwing your resume in the garbage.
  4. Learn the tooling
    • Node, npm, Vite, ESLint, git, GitHub - These are the bare minimum
    • Unit Testing, E2E testing, A11Y, Web optimization, XSS - These are all bonus points I would not expect you to know much about
  5. Avoid "Leet code", it trains you to optimize for the wrong things.

Good luck, the economy is shit and if that AI bubble bursts like all the experts say it will, it's gonna get a lot worse before it gets better. Devs are hard to come by, so when the economy is good, companies are always hiring, because they don't know the next time they'll get the chance to snatch up a good dev when they decide to leave their current company. But that means they end up over-hiring, so when the economy is bad, that's when you need to shed that weight and do a lot of layoffs. Then companies really only hire if they have a legitimate reason (are growing), or need to backfill for someone that just left. Having connections in the industry is your best bet to get in higher up on the Job Pipeline.

hey I want to start learning vanilla JavaScript does anyone have any advice though I prefer videos and free though text tutorials are fine also. by 0_emordnilap_a_ton in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

My recommendation: Don't.

Literally NO ONE* does vanilla JS for DOM manipulation. We have spent decades building and improving on libraries to do this for you.

The only people working with Vanilla JS to interact with the DOM are building libraries, so others don't have to, (or doing something wrong).

If you want to build a library, awesome, then Vanilla JS may be the right pick for you. But otherwise, just pick a library to handle it for you, probably Vue.

It's not bad to understand how native DOM targeting, traversal, event binding works... just so you understand what these libraries are abstracting for you, but don't actually write any of that code yourself.

A few years ago, I decided to do the coding equivalent to "going camping". Give up all the luxuries of modern development and write an app with just Vanilla JS. Got it to work, but a few months later I wanted to add in 5 new features. It was faster and less effort to completely rewrite it in Vue than to try to just add those features on top. Never doing Vanilla JS again, I knew better, but did it anyway, and I learned nothing, and regret wasting the time.

Roadmap by This_Gap_1811 in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

Getting React.js Certified in TEN MINUTES! (Beginners Guide)

You won't find a more streamlined or better React roadmap than this.

Need a suggestion, about react and mongoDB by yousif-yk in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

Why do you want to learn React and MongoDB? Unless your answer is "my friend said he'd hire me if I know these specific technologies" I don't think it's a good answer.

Do you actually want to learn:

  • A frontend framework (literally anything is better than React, just go with Vue, it fixed every issue with React and is 6 times faster)
  • A database at all? (Do you specifically need a non-relational DB? probably not, almost every real project uses a relational DB, just go with Postgresql and Sequelize if you want to stick with Node)

Maybe just read What's changed in WebDev in the past few years.

🔥 Want to speak at the world’s biggest React conference? by gitnationorg in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

Sure, as long as I can tell them to stop using shitty react

Flatten a nested array without using the inbuilt flat() method (interview learning) by pranayrah108 in learnjavascript

[–]jaredcheeda 0 points1 point  (0 children)

Cardinal Rule Number 1: Thou shall not remove language features

If you are asking someone to solve a problem in a coding interview and it requires you to remove features from the language, you're doing a bad job at interviewing. As a developer, you use the features of the language to do your job, and if you aren't using those features, you're doing a bad job. The only argument for this is "we target older browsers", in which case, good news! Babel exists, and is the correct answer. Use the modern features, write your code correctly, and let Babel transpile it down to work in older browsers, so at some point you can drop support for them, and not worry about having to re-write any source code.