7 ms·

VueJS turns 10 years old

133 points by YourCupOTea 3y ago

codethief 3y ago
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-tsc and Volar. What's worse, type checking was largely an afterthought in the development of Vue. Can we, as an industry, please finally agree that languages & frameworks with proper (tools for) static type checking are infinitely better than those without, instead of having to painfully re-learn that lesson time and again? Heck, even Python devs are using type hints these days!
- troupo 3y ago
  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
  - codethief 3y ago
    The translation from JSX to JS is rather easy, though. It is just syntactic sugar.
    - ipaddr 3y ago
      The class vs className breaks every css style.
      - zdragnar 3y ago
        It is a macro ("syntactic sugar") for JavaScript, not HTML.
    - whizzter 3y ago
      You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are < in JSX). / 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.
  - mostlylurks 3y ago
    You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
    - moritzruth 3y ago
      I know you didn’t explicitly say the opposite, but I want to point out that everything you said about React also works with Vue. You can use .vue files, use JSX or write the h-function invocations by hand. Except for SFC-support, this also works without a build step: https://vuejs.org/guide/quick-start.html#using-vue-from-cdn https://vuejs.org/guide/quick-start.html#using-vue-from-cdn
    - martini333 3y ago
      SFC is not required for Vue either.
    - troupo 3y ago
      > You don't, because JSX is not required for react. And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?
  - 4death4 3y ago
    Typescript supports JSX out of the box. It was once true you need custom tools for React, but JSX has proven useful enough that support is provided almost anywhere you need it. Also, as someone else mentioned, JSX is really just syntactic sugar around vanilla JS, so supporting it is much easier.
- bcaxis 3y ago
  I use webstorm, works pretty good out of the box. I agree that messing with vscode plugins isn't a great experience.
  - codethief 3y ago
    I moved away from JetBrains to VSCode a while ago because of bugs related to Vue. Now, a week ago, I moved back to JetBrains because of a bug in Volar. Sigh.
- Hawxy 3y ago
  > What's worse, type checking was largely an afterthought in the development of Vue I'm not sure what you mean. For Vue 3 it was a priority and extensive work went into exposing types that would make it easier for IDE tooling to integrate. Features like the `defineProps` macro are specifically designed to make TS development easier.
  - codethief 3y ago
    You're proving my point. > For Vue 3 it was a priority Right, for version 3. And type checking & IDE support still don't work glitch-free. > Features like the `defineProps` macro are specifically designed to make TS development easier. As you say, in more recent Vue versions, defineProps is a compiler macro, no longer something you `import […] from 'vue'`. So IDE developers had to put in effort to support it.
- uallo 3y ago
  > 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 couple of custom React attributes. Obviously, there is a little more to add React support to an IDE, but this is the very first step. Vue has (but does not require) single-file components. It introduced a new file format: vue. Vue files are already valid HTML syntax. For an editor/IDE, that means it does not need new syntax but only a couple of custom Vue attributes. Obviously, there is a little more to add Vue support to an IDE, but this is the very first step. PS: Vue 3 has great TypeScript support.
  - robertoandred 3y ago
    Vue files are absolutely not valid HTML.
    - uallo 3y ago
      > A Vue SFC is syntactically compatible with HTML. https://vuejs.org/api/sfc-spec.html https://vuejs.org/api/sfc-spec.html
      - robertoandred 3y ago
        No, Vue’s template attributes are not valid html
        uallo 3y ago
        Vue uses @:[]. in their attributes and these are valid HTML attribute syntax. HTML attribute syntax only disallows SPACE"'>/= and some specific code points. Everything else is valid syntax. https://vuejs.org/guide/essentials/template-syntax.html https://vuejs.org/guide/essentials/template-syntax.html https://html.spec.whatwg.org/#attributes-2 https://html.spec.whatwg.org/#attributes-2
- habosa 3y ago
  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)
  - simlevesque 3y ago
    You could look at the Vue SFC Playground's code, seems like this does what you want using monaco: https://play.vuejs.org/ https://play.vuejs.org/
  - taskylizard 3y ago
    Shiki (https://shiki.style https://shiki.style) might be good enough for your usecase, use the latest beta versions as it's the new fresh esm rewrite.
- gilfoy 3y ago
  > 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.
- evnp 3y ago
  Couldn't agree more. We've been having good luck working with TSX-templated Vue components (using "render functions"[1]) after getting fed up with gaps in VTI back in the day – most of https://radiopaper.com https://radiopaper.com is built in this way and we're closing in on it all being so. We haven't run into any issues with Vue's (alleged) lack of ability to optimize TSX templates in certain ways as opposed to traditional Vue templates – maybe comes down to the nature of our use cases – but our view is that this trades off against many other benefits: - File extensions are all .tsx, and thus work with bog-standard editor tooling and syntax highlighting - We're more confident about typechecking in templates, because template code is 1 minor transformation away from raw typescript, and basic `tsc` has understood TSX well for years now. Up and down the component stack, it feels like we understand typings better without "gaps" at each template layer. - Scoping of values in templates is easier to understand. Everything you write is what it says it is, it's just whatever's in the same scope as the template. There are no transformations, no omissions of various words, no magic. - It's easier to compose templates from small easy-to-understand parts in the same file, without fragmenting code across many small components. Not everything needs to live in a `<template>` tag separate from your `<script>` tag. - When React folks have joined the team they've had no problem ramping up. - By the way, in Vue TSX you just say "class" not "className" which is refreshing. Feel free to email me at evan at radiopaper dot com if any of this interests you – we're currently working on expanding the team and looking for like-minded people interested in contributing. [1] https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html
  - codethief 3y ago
    Hi Evan! That sounds really interesting! Would you have a short code example for me, demonstrating what your typical Vue component looks like? Is it similar to the examples at the end of https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html ? I'd also be interested in how you write (S)CSS for your components – do you use some form of CSS-in-JS?
    - evnp 3y ago
      CSS-in-JS has been a challenge – we're currently using https://github.com/astroturfcss/astroturf https://github.com/astroturfcss/astroturf which seemed the simplest zero-runtime-cost option back when we were looking, but the library is starting to feel a bit under-maintained (if the author of Astroturf reads this, we love your work and will do whatever we can to support you in it!). But it's worked well for us over the last 2 years. Happy to share a component example. We also use a small library for managing CSS classes in a typed fashion, which can also be used by our UI test code to target various elements. So that does add a bit of cryptic boilerplate, but the repo README has an example component with syntax highlighting: https://github.com/evnp/namespace.style#usage https://github.com/evnp/namespace.style#usage
tgsovlerkhgsel 3y ago
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 churned away under their feet, twice.
- ceejayoz 3y ago
  We transitioned from Vue v0.14 to v2 to v3 without all that much code churn. Most of the work was a couple third-party components that got abandoned in the 2 —> 3 switch. A couple major version upgrades in a decade seems reasonable.
- PaulRobinson 3y ago
  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 completely recognisable and completely usable. Is it new and shiny and full of awesome features? No. Do I understand it? Yes. Are there plugins for most things I need? Sure. I feel old, but I'd rather make progress with something unfashionable than have to deal with deprecation and learning curves with something fashionable.
  - Hasu 3y ago
    I'm genuinely curious - what features does jQuery have that make it better than modern vanilla JS? Back in the day the vanilla DOM APIs were bad, so jQuery was great, but I haven't felt the need to reach for it in ages.
    - ipaddr 3y ago
      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
monero-xmr 3y ago
I dislike react and liked vue. However I’m on the svelte bandwagon now, which is similar to vue but improved. Basically sveltekit makes a lot of opinionated decisions for you but those are all good places to have opinions.
- agumonkey 3y ago
  What i liked in things like vue, is that they get you to prototype things quickly with a thin layer of conventions that guide you softly and avoid creating a mess. Even if I stopped using vue (went to backend) I still appreciated the voyage / lesson.
- notso411 3y ago
  [dead]
- nlh 3y ago
  +1 to Svelte. I used to work in Vue a lot but something about Svelte clicked so much better for me. It's so good that when new fancy reactive frameworks come around I don't even bother to get distracted - not even for a week (LOL) ;) I'm curious to see how Svelte v5 takes hold. I get the motivation behind why it's been created, but it does dramatically change the syntax to make things feel less "Svelty". It's an interesting side-effect of a maturing project. A lot of the things that make Svelte <=4 enjoyable is how approachable and logical it is. I understand how more complex projects need more ability to split up large components, etc., so Svelte 5 logically makes sense, but it loses some of the charm and simplicity of the original.
code_runner 3y ago
I really enjoyed vue for a large project back in the day. I seemed to have loved everything that everyone else here disliked... which is sometimes par for the course on HN. My project pre-dated the composition API and some other bells and whistles that I've never looked into since leaving FE projects... but IMO, a really good framework with a good community and lots of resources to learn.
uallo 3y ago
I like Vue a lot. It has a terrific documentation, good official—but mostly optional—tooling (Volar, Router, Pinia, Vite), built-in component-scoped styling, fine-grained updates (like signals, but already before it was cool), generates small bundles, their TypeScript support is great, their IDE support is great, single-file components are a blast to work with, and much more. What I also like is that their decisions are not rushed. They observe other frameworks and copy the best ideas from them but address the learnings and add even better versions of these features into Vue. They are rarely the first, but often (imho) the best. Thanks to all contributors and happy birthday!
timetraveller26 3y ago
"Vue.js: JavaScript MVVM made simple (2014)" https://news.ycombinator.com/item?id=7169288 https://news.ycombinator.com/item?id=7169288 (Referenced in tweet)
coding123 3y ago
To me Vue is just a maintained version of angular 1
- huskyr 3y ago
  ...without the cruft and needless complexity of Angular 1 ;)
- whizzter 3y ago
  It got so much right from the start, looking at Angular 2 just made me throw up my hands. But saying "just" is unfair to Vue, it's a big upgrade thanks to the internal mechanics as it solved a lot of brittle and error prone ceremony associated with writing Angular that just went away with the same elegant style of templating.
synergy20 3y ago
This is an amazing project, it tells yet another story how one guy can start a project ended up challenging big companies like Google(Angular) and Meta(React). While React is adding all those complexity by SSR and server component etc these days, Vuejs separates them wisely, if you need just the original SPA, use vuejs as-is, if you want SSR, add Nuxt. I am moving back from React to Vuejs after realizing how heavily React is nowadays affected by VC company Vercel, which has its own agenda of SSR-first(Next.js) and make React even further complicated, Vercel hijacked React in my opinion and made it no longer a "neutral" OSS project, so long, thanks for all the fish. On the same note, Vercel also bought up Svelte and made it SSR first. If you just need SPA and has no need for SSR, which made frontend even more complex, go with Vuejs.
- todd3834 3y ago
  I build React apps without SSR all the time. What has changed in React besides optional support for it?
  - jgalt212 3y ago
    If the preponderance the documentation and examples favor SSR, I can see what the poster is speaking of.
  - ringofchaos 3y ago
    CRA is officially not supported and the official react documentations do not mention creating spa with Vite. They mention using next or remix.
- impulser_ 3y ago
  Svelte is not SSR first. Svelte has nothing to do with the server. There is no server related code in Svelte. Svelte is a UI library/framework/language w.e you want to call it. SvelteKit can be bundled with server code, but it's just as easy to bundle it without any server code. SvelteKit is essentially just a Vite plugin. You can add adapter-static and have to bundled as an SPA and not change anything with you code as long as your not using .server.js files which are files meant to protect server code from not being bundled with the client.
samwillis 3y ago
I think it's a shame the reactivity/signals system from Vue 3 wasn't broken out as a separate project under a different name. They had so much success with building Vite as a separate project, and the reactivity system they built for Vue 3 is so good it warrants the same attention. It can, and is, used outside of Vue, see Alpine.js, but it's adoption would be so much greater if it was packaged under its own name. There is this project that even combines it with react: https://github.com/antfu/reactivue https://github.com/antfu/reactivue. I wish we had slightly looser compiling between templating and reactivity systems...
- Rapzid 3y ago
  I agree and that's one reason I've stuck with MobX. Works with React, Vue, Solid, and even mixed solutions. Heck, I've bridged it with backbone codebases..
y-c-o-m-b 3y ago
I've been in FAANG for a couple of years now and stuck in React world unfortunately. Prior to that I had to use Angular, which imo was even worse. I've had a couple of short opportunities to use Vue professionally in an enterprise application though and damn I loved every second of it. Vue is still my favorite by far. It's just so elegant with its simplicity, it allows me to actually focus on the app and not any bullshit cognitive overhead dealing with state or weird incoherent syntax (looking at you, Angular). I wish there was a larger adoption of Vue.
rpmisms 3y ago
Thanks for 10 years of opinionated, efficient UI dev!
jthemenace 3y ago
We have a large legacy PHP code base originally using "xajax" in many places for asynchronous parts of the UI. We've pretty much got somewhat of our own "framework" and any sort of re-write is absolutely out of the question. We have been slowing replacing xajax with VueJS via a script tag and it's been working great for us as a modern / supported alternative to xajax . There are certain VueJS niceties we can't take advantage of because of the script tag approach, but that hasn't been a big deal.
- downsplat 3y ago
  Similar story here, we have a fairly large code base which has been continually evolved since year ~2000, with our own legacy "framework" for much of the server-side structure. Back then the forms used to reload the whole page, keeping user input and adding error messages (fun times!), then some kind of AJAX was added, where the server would send actual JS back to the client for execution. Some older pages still use jQuery. A couple of years ago we needed to choose a way forward for new front-end dev, and we chose Vue just as Vue 3 was maturing. I didn't know much about reactive frameworks back then, so it was a bit of a hunch, but I'm very happy with how Vue3 has worked so far. We did however do the effort of adding a build step. The site is basically multi-page, with small SPAs sitting at their own URLs for individual jobs. So we wrote a Rollup config to bundle each of the mini-SPAs into its own file, and modified the framework to add a way to configure "this page wants Vue3 and this is the path to its bundled JS". We load the main Vue script as a <script> tag of its own, instead of adding it to all the bundles, for better caching. But as far as I can tell, in this way we can use all the Vue3 niceties, including Single-File Components.
alexcroox 3y ago
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
huqedato 3y ago
Really loved it 7-8 yrs ago. It was a revelation (after bad experiences with Angular). Now I'm finding it a bit on the heavy side... I switched to Svelte and more recently to Solid.

133 points by YourCupOTea 3y ago

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-tsc and Volar. What's worse, type checking was largely an afterthought in the development of Vue. Can we, as an industry, please finally agree that languages & frameworks with proper (tools for) static type checking are infinitely better than those without, instead of having to painfully re-learn that lesson time and again? Heck, even Python devs are using type hints these days!

troupo 3y ago
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
- codethief 3y ago
  The translation from JSX to JS is rather easy, though. It is just syntactic sugar.
  - ipaddr 3y ago
    The class vs className breaks every css style.
    - zdragnar 3y ago
      It is a macro ("syntactic sugar") for JavaScript, not HTML.
  - whizzter 3y ago
    You still need a full JS(x) parser (and lexer) though since / symbols are contextual (as are < in JSX). / 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.
- mostlylurks 3y ago
  You don't, because JSX is not required for react. This isn't even just a theoretical point, but something I've actually done in the past several times; it's very convenient to just try something out by throwing react into a script tag and then just writing a small prototype or something without utilizing JSX and thus avoiding the need to set up a build system and everything else. I would still use JSX for larger projects, of course, but it is mostly just a small quality-of-life improvement, and I'd be using react even if JSX didn't exist, as the actually important parts of the library are not about JSX.
  - moritzruth 3y ago
    I know you didn’t explicitly say the opposite, but I want to point out that everything you said about React also works with Vue. You can use .vue files, use JSX or write the h-function invocations by hand. Except for SFC-support, this also works without a build step: https://vuejs.org/guide/quick-start.html#using-vue-from-cdn https://vuejs.org/guide/quick-start.html#using-vue-from-cdn
  - martini333 3y ago
    SFC is not required for Vue either.
  - troupo 3y ago
    > You don't, because JSX is not required for react. And what does this have to do with the fact that the absolute vast majority of react code is written with JSX and that you need special tools in IDEs to deal with React code (because regular JS tools would break)?
- 4death4 3y ago
  Typescript supports JSX out of the box. It was once true you need custom tools for React, but JSX has proven useful enough that support is provided almost anywhere you need it. Also, as someone else mentioned, JSX is really just syntactic sugar around vanilla JS, so supporting it is much easier.
bcaxis 3y ago
I use webstorm, works pretty good out of the box. I agree that messing with vscode plugins isn't a great experience.
- codethief 3y ago
  I moved away from JetBrains to VSCode a while ago because of bugs related to Vue. Now, a week ago, I moved back to JetBrains because of a bug in Volar. Sigh.
Hawxy 3y ago
> What's worse, type checking was largely an afterthought in the development of Vue I'm not sure what you mean. For Vue 3 it was a priority and extensive work went into exposing types that would make it easier for IDE tooling to integrate. Features like the `defineProps` macro are specifically designed to make TS development easier.
- codethief 3y ago
  You're proving my point. > For Vue 3 it was a priority Right, for version 3. And type checking & IDE support still don't work glitch-free. > Features like the `defineProps` macro are specifically designed to make TS development easier. As you say, in more recent Vue versions, defineProps is a compiler macro, no longer something you `import […] from 'vue'`. So IDE developers had to put in effort to support it.
uallo 3y ago
> 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 couple of custom React attributes. Obviously, there is a little more to add React support to an IDE, but this is the very first step. Vue has (but does not require) single-file components. It introduced a new file format: vue. Vue files are already valid HTML syntax. For an editor/IDE, that means it does not need new syntax but only a couple of custom Vue attributes. Obviously, there is a little more to add Vue support to an IDE, but this is the very first step. PS: Vue 3 has great TypeScript support.
- robertoandred 3y ago
  Vue files are absolutely not valid HTML.
  - uallo 3y ago
    > A Vue SFC is syntactically compatible with HTML. https://vuejs.org/api/sfc-spec.html https://vuejs.org/api/sfc-spec.html
    - robertoandred 3y ago
      No, Vue’s template attributes are not valid html
      - uallo 3y ago
        Vue uses @:[]. in their attributes and these are valid HTML attribute syntax. HTML attribute syntax only disallows SPACE"'>/= and some specific code points. Everything else is valid syntax. https://vuejs.org/guide/essentials/template-syntax.html https://vuejs.org/guide/essentials/template-syntax.html https://html.spec.whatwg.org/#attributes-2 https://html.spec.whatwg.org/#attributes-2
habosa 3y ago
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)
- simlevesque 3y ago
  You could look at the Vue SFC Playground's code, seems like this does what you want using monaco: https://play.vuejs.org/ https://play.vuejs.org/
- taskylizard 3y ago
  Shiki (https://shiki.style https://shiki.style) might be good enough for your usecase, use the latest beta versions as it's the new fresh esm rewrite.
gilfoy 3y ago
> 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.
evnp 3y ago
Couldn't agree more. We've been having good luck working with TSX-templated Vue components (using "render functions"[1]) after getting fed up with gaps in VTI back in the day – most of https://radiopaper.com https://radiopaper.com is built in this way and we're closing in on it all being so. We haven't run into any issues with Vue's (alleged) lack of ability to optimize TSX templates in certain ways as opposed to traditional Vue templates – maybe comes down to the nature of our use cases – but our view is that this trades off against many other benefits: - File extensions are all .tsx, and thus work with bog-standard editor tooling and syntax highlighting - We're more confident about typechecking in templates, because template code is 1 minor transformation away from raw typescript, and basic `tsc` has understood TSX well for years now. Up and down the component stack, it feels like we understand typings better without "gaps" at each template layer. - Scoping of values in templates is easier to understand. Everything you write is what it says it is, it's just whatever's in the same scope as the template. There are no transformations, no omissions of various words, no magic. - It's easier to compose templates from small easy-to-understand parts in the same file, without fragmenting code across many small components. Not everything needs to live in a `<template>` tag separate from your `<script>` tag. - When React folks have joined the team they've had no problem ramping up. - By the way, in Vue TSX you just say "class" not "className" which is refreshing. Feel free to email me at evan at radiopaper dot com if any of this interests you – we're currently working on expanding the team and looking for like-minded people interested in contributing. [1] https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html
- codethief 3y ago
  Hi Evan! That sounds really interesting! Would you have a short code example for me, demonstrating what your typical Vue component looks like? Is it similar to the examples at the end of https://vuejs.org/guide/extras/render-function.html https://vuejs.org/guide/extras/render-function.html ? I'd also be interested in how you write (S)CSS for your components – do you use some form of CSS-in-JS?
  - evnp 3y ago
    CSS-in-JS has been a challenge – we're currently using https://github.com/astroturfcss/astroturf https://github.com/astroturfcss/astroturf which seemed the simplest zero-runtime-cost option back when we were looking, but the library is starting to feel a bit under-maintained (if the author of Astroturf reads this, we love your work and will do whatever we can to support you in it!). But it's worked well for us over the last 2 years. Happy to share a component example. We also use a small library for managing CSS classes in a typed fashion, which can also be used by our UI test code to target various elements. So that does add a bit of cryptic boilerplate, but the repo README has an example component with syntax highlighting: https://github.com/evnp/namespace.style#usage https://github.com/evnp/namespace.style#usage

tgsovlerkhgsel 3y ago

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 churned away under their feet, twice.

ceejayoz 3y ago
We transitioned from Vue v0.14 to v2 to v3 without all that much code churn. Most of the work was a couple third-party components that got abandoned in the 2 —> 3 switch. A couple major version upgrades in a decade seems reasonable.
PaulRobinson 3y ago
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 completely recognisable and completely usable. Is it new and shiny and full of awesome features? No. Do I understand it? Yes. Are there plugins for most things I need? Sure. I feel old, but I'd rather make progress with something unfashionable than have to deal with deprecation and learning curves with something fashionable.
- Hasu 3y ago
  I'm genuinely curious - what features does jQuery have that make it better than modern vanilla JS? Back in the day the vanilla DOM APIs were bad, so jQuery was great, but I haven't felt the need to reach for it in ages.
  - ipaddr 3y ago
    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

monero-xmr 3y ago

I dislike react and liked vue. However I’m on the svelte bandwagon now, which is similar to vue but improved. Basically sveltekit makes a lot of opinionated decisions for you but those are all good places to have opinions.

agumonkey 3y ago
What i liked in things like vue, is that they get you to prototype things quickly with a thin layer of conventions that guide you softly and avoid creating a mess. Even if I stopped using vue (went to backend) I still appreciated the voyage / lesson.
notso411 3y ago
[dead]
nlh 3y ago
+1 to Svelte. I used to work in Vue a lot but something about Svelte clicked so much better for me. It's so good that when new fancy reactive frameworks come around I don't even bother to get distracted - not even for a week (LOL) ;) I'm curious to see how Svelte v5 takes hold. I get the motivation behind why it's been created, but it does dramatically change the syntax to make things feel less "Svelty". It's an interesting side-effect of a maturing project. A lot of the things that make Svelte <=4 enjoyable is how approachable and logical it is. I understand how more complex projects need more ability to split up large components, etc., so Svelte 5 logically makes sense, but it loses some of the charm and simplicity of the original.

code_runner 3y ago

I really enjoyed vue for a large project back in the day. I seemed to have loved everything that everyone else here disliked... which is sometimes par for the course on HN. My project pre-dated the composition API and some other bells and whistles that I've never looked into since leaving FE projects... but IMO, a really good framework with a good community and lots of resources to learn.

uallo 3y ago

I like Vue a lot. It has a terrific documentation, good official—but mostly optional—tooling (Volar, Router, Pinia, Vite), built-in component-scoped styling, fine-grained updates (like signals, but already before it was cool), generates small bundles, their TypeScript support is great, their IDE support is great, single-file components are a blast to work with, and much more. What I also like is that their decisions are not rushed. They observe other frameworks and copy the best ideas from them but address the learnings and add even better versions of these features into Vue. They are rarely the first, but often (imho) the best. Thanks to all contributors and happy birthday!

timetraveller26 3y ago

"Vue.js: JavaScript MVVM made simple (2014)" https://news.ycombinator.com/item?id=7169288 https://news.ycombinator.com/item?id=7169288 (Referenced in tweet)

coding123 3y ago

To me Vue is just a maintained version of angular 1

huskyr 3y ago
...without the cruft and needless complexity of Angular 1 ;)
whizzter 3y ago
It got so much right from the start, looking at Angular 2 just made me throw up my hands. But saying "just" is unfair to Vue, it's a big upgrade thanks to the internal mechanics as it solved a lot of brittle and error prone ceremony associated with writing Angular that just went away with the same elegant style of templating.

synergy20 3y ago

This is an amazing project, it tells yet another story how one guy can start a project ended up challenging big companies like Google(Angular) and Meta(React). While React is adding all those complexity by SSR and server component etc these days, Vuejs separates them wisely, if you need just the original SPA, use vuejs as-is, if you want SSR, add Nuxt. I am moving back from React to Vuejs after realizing how heavily React is nowadays affected by VC company Vercel, which has its own agenda of SSR-first(Next.js) and make React even further complicated, Vercel hijacked React in my opinion and made it no longer a "neutral" OSS project, so long, thanks for all the fish. On the same note, Vercel also bought up Svelte and made it SSR first. If you just need SPA and has no need for SSR, which made frontend even more complex, go with Vuejs.

todd3834 3y ago
I build React apps without SSR all the time. What has changed in React besides optional support for it?
- jgalt212 3y ago
  If the preponderance the documentation and examples favor SSR, I can see what the poster is speaking of.
- ringofchaos 3y ago
  CRA is officially not supported and the official react documentations do not mention creating spa with Vite. They mention using next or remix.
impulser_ 3y ago
Svelte is not SSR first. Svelte has nothing to do with the server. There is no server related code in Svelte. Svelte is a UI library/framework/language w.e you want to call it. SvelteKit can be bundled with server code, but it's just as easy to bundle it without any server code. SvelteKit is essentially just a Vite plugin. You can add adapter-static and have to bundled as an SPA and not change anything with you code as long as your not using .server.js files which are files meant to protect server code from not being bundled with the client.

samwillis 3y ago

I think it's a shame the reactivity/signals system from Vue 3 wasn't broken out as a separate project under a different name. They had so much success with building Vite as a separate project, and the reactivity system they built for Vue 3 is so good it warrants the same attention. It can, and is, used outside of Vue, see Alpine.js, but it's adoption would be so much greater if it was packaged under its own name. There is this project that even combines it with react: https://github.com/antfu/reactivue https://github.com/antfu/reactivue. I wish we had slightly looser compiling between templating and reactivity systems...

Rapzid 3y ago
I agree and that's one reason I've stuck with MobX. Works with React, Vue, Solid, and even mixed solutions. Heck, I've bridged it with backbone codebases..

y-c-o-m-b 3y ago

I've been in FAANG for a couple of years now and stuck in React world unfortunately. Prior to that I had to use Angular, which imo was even worse. I've had a couple of short opportunities to use Vue professionally in an enterprise application though and damn I loved every second of it. Vue is still my favorite by far. It's just so elegant with its simplicity, it allows me to actually focus on the app and not any bullshit cognitive overhead dealing with state or weird incoherent syntax (looking at you, Angular). I wish there was a larger adoption of Vue.

rpmisms 3y ago

Thanks for 10 years of opinionated, efficient UI dev!

jthemenace 3y ago

We have a large legacy PHP code base originally using "xajax" in many places for asynchronous parts of the UI. We've pretty much got somewhat of our own "framework" and any sort of re-write is absolutely out of the question. We have been slowing replacing xajax with VueJS via a script tag and it's been working great for us as a modern / supported alternative to xajax . There are certain VueJS niceties we can't take advantage of because of the script tag approach, but that hasn't been a big deal.

downsplat 3y ago
Similar story here, we have a fairly large code base which has been continually evolved since year ~2000, with our own legacy "framework" for much of the server-side structure. Back then the forms used to reload the whole page, keeping user input and adding error messages (fun times!), then some kind of AJAX was added, where the server would send actual JS back to the client for execution. Some older pages still use jQuery. A couple of years ago we needed to choose a way forward for new front-end dev, and we chose Vue just as Vue 3 was maturing. I didn't know much about reactive frameworks back then, so it was a bit of a hunch, but I'm very happy with how Vue3 has worked so far. We did however do the effort of adding a build step. The site is basically multi-page, with small SPAs sitting at their own URLs for individual jobs. So we wrote a Rollup config to bundle each of the mini-SPAs into its own file, and modified the framework to add a way to configure "this page wants Vue3 and this is the path to its bundled JS". We load the main Vue script as a <script> tag of its own, instead of adding it to all the bundles, for better caching. But as far as I can tell, in this way we can use all the Vue3 niceties, including Single-File Components.

alexcroox 3y ago

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

huqedato 3y ago

Really loved it 7-8 yrs ago. It was a revelation (after bad experiences with Angular). Now I'm finding it a bit on the heavy side... I switched to Svelte and more recently to Solid.