Live data from Hacker News

VueJS turns 10 years old

twitter.com

61–70 of 97 posts

Re: VueJS turns 10 years old

#61
post #28

Earlier quoted context omitted.

I fell for a feint though. Reading their docs it seemed like they were going to go in the direction of class components with attributes (class decorators). So we built our app for that, thinking we'd be future proof, but alas the community went 180 degrees the other way, and our Vue 2 app became super hard to upgrade to Vue 3.

Without more context can't comment on your upgrade process. But as others stated above, there's not much difference betweeb 2 and 3, except you do not get composition api on a v2 project, while you can use composables but can't go full composition api and have to stick to options api. Other than that most of v2 code would work on v3.

This isn't correct. I'm using the composition API on all my Vue 2 projects. It's even baked into 2.7.

https://github.com/vuejs/composition-api

Re: VueJS turns 10 years old

#62
post #44
post #38

Earlier quoted context omitted.

Better and shorter syntax, plugins, ecosystem. Hide Show ``` $(".box").hide(); $(".box").show(); vs document.querySelector(".box").style.display = "none"; document.querySelector(".box").style.display = "block"; ``` Both work. The first is more clear

``` const $ = document.querySelector.bind(document); $('.box').hidden = true; $('.box').hidden = false; ```

1. Not really.

jQuery is designed not to fail. So if there's no `.box` on the page, jQuery will not do anything.

`querySelector` may return null, so `$('.box').hidden` will hard break your page if you're not careful enough

2. `$('.box').hide()` is just one such example.

The hilarious https://youmightnotneedjquery.com/ shows that jQuery remains more consistent, concise, and composable than most things in modern browser APIs

Re: VueJS turns 10 years old

#63

I still don't understand why they had to introduce a proprietary file format. It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. Unfortunately, developing those takes time – apparently more than 10 years: To this day (I set up a new Vue project just a few days ago) there are countless bugs in vue-t…

> Heck, even Python devs are using type hints these days!

I switch between Python and TS regularly at work, Python type system is honestly kind of shite compared to TS.

Re: VueJS turns 10 years old

#64
What I love about Vue/Nuxt devs are not only the powerful tooling they create, but the way they build it so any framework can utilise it. Biggest examples are Vite, Unjs, Nitro. Plus I love the way they think about providing so much flexibility with deployments. Want to deploy your SSR Nuxt app to Cloudflare workers? It’s a 1 line config change in the Nitro config

Re: VueJS turns 10 years old

#65
post #51

I still don't understand why they had to introduce a proprietary file format. It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. Unfortunately, developing those takes time – apparently more than 10 years: To this day (I set up a new Vue project just a few days ago) there are countless bugs in vue-t…

Does anyone know of a good open source syntax highlighting library for Vue SFC? That’s my biggest issue with the file format (I maintain a code review tool)

You could look at the Vue SFC Playground's code, seems like this does what you want using monaco: https://play.vuejs.org/

Re: VueJS turns 10 years old

#66
post #26

I still don't understand why they had to introduce a proprietary file format. It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. Unfortunately, developing those takes time – apparently more than 10 years: To this day (I set up a new Vue project just a few days ago) there are countless bugs in vue-t…

> It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. React has (but does not require) JSX. It introduced a new file format: jsx or tsx. JSX is not valid JavaScript syntax. Hence, tooling needs explicit support for JSX. For an editor/IDE, that means it needs to add a relatively easy new syntax and a…

Vue files are absolutely not valid HTML.

Re: VueJS turns 10 years old

#67
post #26

Earlier quoted context omitted.

> It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. React has (but does not require) JSX. It introduced a new file format: jsx or tsx. JSX is not valid JavaScript syntax. Hence, tooling needs explicit support for JSX. For an editor/IDE, that means it needs to add a relatively easy new syntax and a…

Vue files are absolutely not valid HTML.

> A Vue SFC is syntactically compatible with HTML.

https://vuejs.org/api/sfc-spec.html

Re: VueJS turns 10 years old

#68

I started using VueJS when I got thrown off the deprecation treadmill by Angular. Regardless of whether something is a hobby project that you want to only touch a couple times a year or a big project with dozens of developers, having your platform deprecated under your feet and being forced to do migration work sucks. Vue is now on version 3 within 10 years. That means anyone who relied on v1 has had their work churn…

I was around for the first Angular deprecation treadmill, and it was jarring. I was thinking about doing some stuff for a hobby project recently and as a mostly back-end engineer, I am very out of date for most front-end code. I did a scout around, and didn't feel too impressed. Finally last week I was thinking "I wonder what happened to jQuery", and there it was. Just as it ever was. Updated, freshened up, but compl…

I would look around more. You might like one of the small reactive frameworks if you find the large ecosystem of React and Vue off-putting. My last jQuery app was several years ago, when I realized I was just maintaining a slower reimplementation of a reactive framework. These are mature technologies now that quickly save time and prevent headaches down the road. jQuery's best lessons have been absorbed into both the reactive frameworks and native JS and you can alias the handful of selectors you're used to.

For development, browsers and version managers/containers are stable enough that you won't be on a deprecation treadmill. Any pressure would come from including other people on the project, which you'd get even more of with jQuery.

I appreciate the 'do what works' mindset quite a bit but I hope you'll give a modern reactive framework or library a try; I'm glad I made the change.

Re: VueJS turns 10 years old

#69
post #26

Earlier quoted context omitted.

> It means that, instead of being able to rely on existing tools for type checking & proper IDE support (like React does), you need custom tools for that custom file format. React has (but does not require) JSX. It introduced a new file format: jsx or tsx. JSX is not valid JavaScript syntax. Hence, tooling needs explicit support for JSX. For an editor/IDE, that means it needs to add a relatively easy new syntax and a…

Vue files are absolutely not valid HTML.

Template, script, and style are all valid tags.

Re: VueJS turns 10 years old

#70
post #3

Earlier quoted context omitted.

You need custom tools for React, too. Because JSX is not valid JS. In most (all?) IDEs you can also tell the IDE to treat the file with a certain extension as written in any language

The translation from JSX to JS is rather easy, though. It is just syntactic sugar.

You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are / and < in operator positions becomes operators, whilst / in plain JS in a value position becomes the start of an reg-exp and < becomes the start of an JSX tag, so to handle it there needs to be a full parser (with a pull-lexer to correctly handle the contextual part) as you cannot just do a textual replacement due to ambiguity.
Post reply on HN