Plans for the Next Iteration of Vue.js
medium.comI'm really worried about the wholesale move to Typescript in so many projects. To me it's the new coffeescript combined with the verbosity of J2EE. Yes it's corporate sponsored, so hopefully will be maintained indefinitely - but I like JavaScript, and Typescript isn't JS.
What's worse is so many developers using their own slightly tweaked versions of JavaScript. I spent a solid day this week trying to get decorators and class fields to transpile reliably with as few dependencies as possible. It seems every project creates their own DSL that sorta-kinda is JS, then figures out a way to get it to compile and calls it a day. This sort of goes against the whole reason we have language standards in the first place.
Anyways, I admire Evan's desire to hold back on the need for decorators and class fields, but since he's developing the project in Typescript, I have little faith that any of the projects that use Vue will avoid them.
I agree that TS increases barrier to entry for contributors. However, it's very different from Coffeescript. It offers better program correctness via types whereas CS was mostly sugar. Libraries that (properly) use Flow/TS are less likely to have bugs and are safer to contribute to (you're less likely to introduce a bug) and that's a good thing.
Libraries that (properly) use {{insert anything here}} are less likely to have bugs and are .... etc
remove the (properly) and I'd give the technology some credit. Otherwise it's just "no true Scotsman" fallacy.
Typescript is a strict superset of JS and everything is additive. You don't have to add a single character beyond normal JS if you don't want to, but can still benefit from the compiler providing intellisense and refactorings.
> To me it's the new coffeescript combined with the verbosity of J2EE
How is this the top voted comment on here? How does one go from Coffeescript/J2EE to TS? Coffeescript was... well... Coffeescript, a JS variant with better ergonomics. J2EE was a Java framework that also has no resemblance or connection to TS. What a bizarre comment but truly disturbing to see masses voting this up.
No, I get it.
As a JS dev, Cofeescript appeared to be nothing more than an attempt to make JS more like Ruby.
From this perspective, TS appears to be nothing more than an attempt to make JS more like C#.
Either way, both appear to be attempts to use JS's massive flexibility to make the language work more like another language, because people are more familiar with that other language. And in both cases, there's a familiar response of "please don't do that. Please stop complaining about JS because it's not like your favourite language. Please learn to use it properly instead".
I played very briefly with CS to see what the excitement was about, and haven't touched TS at all, because I enjoy JS. But with Vue moving there, I think I'm going to have to bite the bullet and take a look.
I suggest you give TypeScript a try. You might like it, you might not, but at least then you'll know. It uses gradual typing - you can use static types as little or as much as you like. It's not C#.
I'm writing the backend in Go, so static typing is not where the resistance is coming from ;)
It's more like separation of concerns. I want Postgres to take care of data integrity. I want Go to take care of type safety. I want to give Vue all the flexibility it needs to handle user interaction. I don't really want to care about types in the UI, because Go can sort out whatever it sends to the server.
If I have to start writing code in the browser to translate between Go structs and TS classes then that's a step too far imho.
Try it before saying something like that.
TS is like swift, and it does not require type declaration. A lot is automatic.
Coffeescript - like Typescript - is a non-language. There are no native VMs for either. They have to be transpiled to work. If you're writing in either language, you're basically using large DSL macros which pump out JavaScript. Think PHP for scripting.
J2EE wasn't just a framework, it was core enhancements to the Java language, which caused a ton of bloat. EJBs, JSF, annotations, XML configurations, etc. Very similar to Typescript's bloat it adds on top of JavaScript. (You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all.)
> a non-language
It has a BNF that’s different from any other language, so it’s definitely a language. A language isn’t defined by its runtime.
> Think PHP for scripting.
PHP is a language...
> J2EE wasn't just a framework
What language features did J2EE introduce?
> You can't argue that it's not all bloat, as the resulting JS it produces runs fine without it all
Yeah, just like C, which compiles yo machine code, is complete bloat.
I love pedantic, stubborn techies. You asked how one goes from Coffeescript/J2EE to TS, as you apparently couldn't understand and considered it bizarre. I (and another commenter) explained what everyone else seemed to grasp that you couldn't, and now you're nit-picking simply to win an argument.
You're right, it's all just machine code in the end. Real programmers use a magnetized needle and a steady hand. You totally win.
I especially don’t get the ide support bit, because Visual Studio Code already does that for regular JS.
I think typescript is s mistake that most people will regret because it adds so much complexity to the process for so few advantages gained. I mean, we were predominantly a C# house, if anyone should be using Typescript it should be us, but we found it to be much less productive than JS exactly because stuff like prototypes becomes more complex and typesafety kind of gets in the way of the process when you’re not exactly sure what you’re making.
I don’t think it’s exactly coffeescript though, I mean, I just ranted about typescript, but it doesn’t get in the way like coffescript. Since it integrates sort of decent into JS, it’s not a horrible thing, we just found it unnecessary.
> I especially don’t get the ide support bit, because Visual Studio Code already does that for regular JS.
The IDE support in VSCode is at least partially driven by type declarations from TS projects, so regular JS is benefiting from TypeScript.
I didn’t say typescript was horrible, it’s just been unnecessary and unproductive for us. I think it does have a place in applications like VS code, because maintaining them is quite a lot bigger than most projects, and you don’t include VS code in yours.
if you're not sure what you're making then just type everything you're spiking on with any or unknown?
> …I like JavaScript, and Typescript isn't JS.
Considering that you don't need to use it unless you plan on contributing to Vue.js itself, my (sincere) question is: Why does it matter to you?
One always ends up going through a library or framework's source code at one point or another while trying to track down bugs. Using Typescript makes this a lot harder.
For example, I was going to contribute to the Visual Studio Code project with a simple tweak: A setting that would make global find key-command happen without have to click the search icon after. After asking online and then wading through the TS source code trying to get something to work, I finally just gave up. Typescript isn't JavaScript.
Did you try running the build script and working directly in “out/“? I doubt it would have been easier. Big projects simply take time to learn and contribute to, TypeScript or not.
Actually, I’d say VS Code would be much harder to contribute to without TS. You mentioned adding a setting. This requires touching several different methods (parsing, cleansing, etc.). With TypeScript, the compiler instantly tells you when you have forgotten to implement a part of the setting pipeline. With JS, the runtime gives you some “undefined is not a blah” error to track down.
Type annotations strongest advantage is when diving into a new code base you've never read before. Can't see how it can make it harder to track down bugs. It does prevent monkeypatching so some "i'll just add a quick fix here" are going to be harder, and that is a good thing, otherwise you end up with spaghetti soup.
> Using Typescript makes this a lot harder.
Does it? I think type annotations makes it easier. It means you don't need to think less hard, which makes unknown code, which is always harder to read, a bit easier to read.
Yep, this is a huge problem in the ecosystem right now. The irony is that JS, an interpreted language, is becoming slower to compile than some of the newer compiled language (i.e. golang, which compiles to machine code and therefore avoids all compatibility issues).
Golang doesn't avoid all the compatibility issues. On the contrary, there's a ton of Golang that won't run on anything but Linux.
> […] there's a ton of Golang that won't run on anything but Linux.
Please give examples so I can fix them.
Go code is highly portable to the supported platforms. In all my 5+ years developing code on Mac and cross-compiling for Linux servers, I can count with one hand the number of broken packages due to compatibility issues with the target operating system.
With my experience I am sure that I can fix the cross-compatibility issues in the code that you have had problems with, but I need names and/or links, please point me to them.
I don't have examples off the top of my head, but I'll tell you how it happens.
* Use of cgo and platform-specific headers / libraries
* Use of golang.org/x/sys/unix, especially ioctl
* References to external utilities and files only typically installed on Linux, especially with os/exec, or use of GNU extensions in system utilities
* Inability to correctly handle paths on Windows (use of "path" instead of "path/filepath")
* Inability to correctly handle case-insensitive file systems
* Creation of paths containing characters illegal on NTFS, or with names that are otherwise illegal on NTFS (through the normal APIs)
* Deleting files or using deleted files in a way that works on POSIX but not Windows, this particular one is especially common because the mandatory file locks on Windows will bite you hard if you are used to the POSIX way of doing things
* Difference in semantics for filesystem change notifications. In JavaScript I can use chokidar and in Golang I can use github.com/fsnotify/fsnotify, but that doesn't change the fact that the underlying notification systems have radically different semantics. You can't really paper over these differences, you have to actually test your code on different platforms and make sure they work correctly on those platforms
Go code doesn't strike me as radically more portable than, say, Java, C#, or JavaScript. The fact that you haven't personally encountered problems often is good, but this isn't an indication that Go "avoids" portability problems. And compiling to machine code is not really a piece of the platform portability puzzle... it just means that you don't have to worry about having a different runtime version on your target.
The bottom line is that while Golang makes portability easier, for anything but relatively trivial programs (and "trivial" is getting larger and larger every day), your program is only portable as far as you have actually tested it on other systems. This is less work in Golang than it is with C++, and I'm really thankful for it, but it's not a radical change and it's not substantially different from the portability story that Node.js has.
I cross-compiled to Windows the other day for the first time (from Linux). It gave me a perfectly-working .exe in less than a second on my first try.
I love JS too, but I have yet to get Webpack or Babel working in less than a couple of hours.
Can you expand on this? I’ve used a decent amount of Go packages and they all run as expected on my Mac.
I expanded on this here: https://news.ycombinator.com/item?id=18116730
Probably stuff that hardcodes paths like /tmp
Unlike CoffeeScript, you can't have any technical debt with TypeScript, if one day TypeScript disapears, you just remove the types and you have a perfectly working JS file.
Really? This isn't even close to valid JS.
enum Color { red = 1, green = 2, blue = 4 }
namespace Color { export function mixColor(colorName: string) { if (colorName == "yellow") { return Color.red + Color.green; } else if (colorName == "white") { return Color.red + Color.green + Color.blue; } else if (colorName == "magenta") { return Color.red + Color.blue; } else if (colorName == "cyan") { return Color.green + Color.blue; } } }
* Edited with a better example.
enums are probably the only TS thing which does not exist in plain JS (at least I can't think of any other one), and it's quite easy to replace. In your example you just replace enum by a hashmap and remove all the types and it's a valid JS file, it's not really that different. It would be quite easy for an automated tool to do that.
It's not that simple because you can reverse lookup a TS enum. So:
would be the same as:enum Color { Red = 1, Green = 2 }
See for yourself: https://www.typescriptlang.org/play/#src=enum%20Color%7B%0D%...var Color = { Red: 1, 1: 'Red', Green: 2, 2: 'Green' }But I agree with you, it would be quite easy for an automated tool to replace a TS enum with pure JS.
Ah that's a good point, thanks for bringing it. I did know TS enums supported that, I thought it was just some syntax sugar for a hashmap.
> new coffeescript combined with the verbosity of J2EE
- Saying that TypeScript is like CoffeeScript is almost equivalent than saying that CoffeeScript is like Babel.
- The only part that CoffeeScript and TS (and Babel) have in common is the transpilation step.
- CoffeeScript, Dart, ReasonML, ... are all about creating a pure/clean/elegant languages that use JavaScript as a runtime, and since JavaScript "bytecode" is "sourcecode", they transpile to it.
- TypeScript is all about adding Type annotations to JavaScript without removing or redefining any of the language structure. In fact, the transpilation step is mostly about removing TypeScript more than anything else. Besides enum, as mentioned in one of the comment, TypeScript does not add any language structure beside type related ones (another one is class fields, but coming soon to EcmaScript)
- J2EE (JEE and Spring in some respect) are frameworks, and not languages, and does not really have any comparison with TypeScript. They just encode what they see/saw as best practices/patterns into a set of APIs. TypeScript is a language (or language superset), and can support many different design patterns.
- Perhaps a better statement would have been "verbosity of Java," and while developers can use TypeScript to code JavaScript "Java-style", and bring a lot of the J2EE/Spring/JEE patterns to JavaScript/TypeScript, nothing in TypeScript force or even favor this approach.
- In fact, we use TypeScript to write more robust and maintainable javascript code following a "Functional first, OO/class as needed" style allowing our modules to expose simple and intent-driven APIs. Same signatures as if we were not using TypeScript, but now we know what comes in and what comes out.
- Thanks to TypeScript expressiveness and following our functional first and OO as needed code design, we migrated one of our Java backends to TypeScript/Node, and made the code 40% lighter, better typed, and much simpler and cleaner intent-driven module apis.
Btw, been there as well, where a couple of years ago I mistakingly classified TypeScript in the Dart / CoffeeScript category. I was misguided by the then tight "marketing" coupling with Angular, which I would describe (Angular) as the J2EE for Web UI, and my anti-Microsoft bias for open source project (which I rectified since).
Yes, there is a learning curve, but it is not that high (mostly on setup side), and the value back for any sizable JavaScript code is huge. Even for small projects, once you get the habit of including it, the value is great, especially for 3rd party api discovery.
Also, as a developer will finally drop IE11 support, Babel value will probably diminish, and TypeScript benefits will probably become even more noticed. TypeScript's cost of adoption for babel developers is relatively low since they already have a transpilation step.
(btw, class fields are coming to the JS spec, so this was very babelish of TypeScript to have added this support early on).
Phew. After the Angular 2 disaster, I am traumatized by posts with this title format. It seems like the changes will be simple, useful, and mostly backwards compatible. I look forward to upgrading my current Vue projects to use 3.x. I am especially excited about not having to worry about missed observable mutations with arrays. That was annoying.
How was Angular 2 a disaster? I know it was basically a new Framework but I think they made it very clear and even did a rebranding (AngularJS -> Angular) and AngularJS is still being maintained.
While I agree Angular 2 isn't a disaster, AngularJS -> Angular is probably the laziest and most ambiguous "rebranding" I've ever seen, considering the fact that historically AngularJS was often referred to as Angular. This will be a clunky simile, but it's like if all of a sudden Coca-Cola decided to rebrand Cherry Coke as just Coke and branded regular Coke as CokeNC. (Coke NoCherry).
The front end team at my last company was pretty pissed that they spent months migrating to Angular and then learned that Angular 2 was not backwards compatible.
They were hoping that by going to Angular they were buying in to a platform that would serve them for years, but that was not the case. That’s a huge deal. Why should they trust Angular ever again?
I suspect the Angular 2 debacle was a big factor in moving React ahead of Angular.
> How was Angular 2 a disaster?
Because these were basically 2 different projects that have absolutely nothing in common. They should have called it something else. I'll be hyperbolic but imagine jQuery then jQuery2 is React, to give you an idea. Why still call that jQuery? for marketing purposes obviously and it's a bad reason.
Big changes that come so sudden are disasters in the real world where people don’t adopt new things a lightning speed or for free.
If you spend money upgrading your employees from whatever mvc to angular1 and then have to do the same thing a few years later, you’ll be pissed.
If you have to take time out to learn a new framework every two years, just because. You’d be pissed.
And you have to keep in mind that angular was meant for ebpnterprise, not young indies who change their frameworks more often than I change my pants, so that made it extra terrible. I mean, there is a reason COBOL is still a thing, enterprise doesn’t like change.
I guess you could have kept going with angular1, but how would you hire for something that only lived s few years? Nobody knows it.
I think Microsoft is in danger of going this route as well with all the changes they are doing to .net though, so it’s a general trend these days, by my god, it sucks.
Nice performance improvements:
> The constant baseline size for the new runtime is <10kb gzipped.
> Faster: on preliminary benchmarks, we are seeing up to 100% performance improvement across the board, including raw Virtual DOM mounting & patching (we learned quite a few tricks from Inferno, the fastest Virtual DOM implementation out there), component instance initialization and data observation. 3.0 will shave off half the time spent in JavaScript when your app boots up.
Written in TypeScript and with TS type support in mind! That was the thing missing for me to look at Vue, looking forward to the release.
Yeah this is great. Last time I tried, Vue itself wasn't too bad to get going with TS. The real issue for us was Vuex. The official examples and the Typescript examples we found looked completely different. It wasn't easy to get started.
We actually moved to React + Redux since it was early enough in the project to make that decision. Typescript support is much better there. If typescript support was better in Vue/Vuex, I doubt we'd have made that decision.
> Vue itself wasn't too bad to get going with TS
Last time I tried, there wasn't any support for type check across component boundaries (props, events). Did something change?
A deal-breaker for me. I mostly know types from within the component; if you keep them small enough it's not much of an issue to just look up/down to check for a name, for example. But cross-component communication is where I need TS the most. Hopefully 3.0 addresses that (didn't read the whole article thoroughly, maybe it's mentioned).
Oh wow. We didn't get far enough to notice that was a problem. We needed Vuex for something and that's where we got stuck and switched.
It's a good job - at that stage in the project, it wouldn't have been a big problem so we didn't notice. If we had continued, I would have a hard time justifying a switch at that stage and could have been in a bit of a corner right now.
Props can have a type.
The type is verified at runtime though
It can also be verified at compile time when using vue-class-component.
If it's a primitive type, yes. Throw in a union, a generic, or a conditional and everything blows up.
Will it still be possible to run in an ES2015-compatible browser without transpiling? That was one of the killer features of Vue for me.
Do you mean running Vue by just adding a script tag to the page? That will still work because it's just using a precompiled/transpiled JS file, which will continue to be available as part of the package. FYI, React can also run the same way.
As there is no mention of it, it should be available. After all, as you said, Modern mode is a killer feature.
How are they running TypeScript in the browser without transpiling?
You transpile TS at build time, i.e. when the library itself is built, not when your project is built.
Nope, and it won't run with ECMAScript-compatible editors, linters, static analyzers, or type checkers (see: Flow).
I can't imagine recommending TypeScript to anyone I like.
What are you talking about? Typescript is what the Vue source code will be written in, which is compiled to javascript when distributed and includes Typescript definitions for editors that make use of it.
Your code can continue to be written in regular javascript with whatever toolchain you want.
And Typescript is a fantastic platform for bringing strong typing to Javascript, it's a rather extreme comment to say you don't recommend it to anyone.
Why would you use flow with typescript? Also valid javascript is valid typescript, you can even have typescript's tooling lint your javascript with a jsconfig file.
I never had a time to take a look at type script.
What is the benefit of adding static typing to an inherently dynamically typed language?
As I understand, they don't get any performance improvement from that, as the browser still runs it in JS vm?
While there can technically be a perf improvement by making the types of functions less likely to change over time meaning to better jit code, the real reason is for safety (you'll get a warning if you pass an array of elements into a function that expects an array of functions that return elements) and IDE-style tooling assistance (like intellisense).
Types let you shift more of the testing load to the compiler instead of run time. Also, auto complete (not just string based) works much better because it's easier to reason via information that is exclusively in the realm of compile time (types).
I have seen very little value in dynamic languages in practice. Cool, you can pass any old thing into this function I wrote. Well, no, you can't really, because the function has assumptions about the structure of the things that it can operate on. So then I've got to start checking that the foo that you gave me has the kind of properties of a foo that I care about accessing, and you've got to know when you construct your foo that I care about those things. With a typed language, those assumptions are made explicit, whereas in dynamicland they remain implicit, and I've got to make runtime checks to verify that this foo can be bar()'d, and you have to determine, from docs, or reading the source, or trial and error, that I'm expecting it to be bar()-able, or things go sideways. Also, we have to agree on naming, down to pedantic stuff like case-sensitivity, so that if you give me a Bar()-able foo when I expect a bar()-able foo, we don't, in the best case, fail loudly, or worse, just do nothing. Not farming this kind of tedious drudgework off to a compiler or type-checker seems really stupid, especially nowadays when JS is already run through a compiler like babel as a preprocessing step anyway.
If anything, I think most typed languages don't go far enough in making assumptions about their data explicit, and there is far too much primitive obsession. In an ideal world, I would not have to ever refer to documentation to understand what subset of inputs from the type that is declared on a function parameter are actually valid - a function that only handles integers from 0 to 100 would raise a compiler error if I tried to pass it 200, and whole classes of runtime errors would become impossible, and vast swathes of trivial unit testing harnesses would be irrelevant.
This was the only thing stopping me from using it in larger projects. Can't wait to see how it plays. Hopefully the class-based interface has no weird object notation (methods, props, computed) and uses decorators like Angular.
With the current TS helpers you have:
And a bunch of decorators to connect vuex actions etc.@Prop myProp!: string; get myComputedGetter(): string {… set myComputedSetter(val: string) {… myMethod(in: number): string {… @Watch('property') methodToCallOnChange() {…I assume the Vue3 version will be similar
I'd been out of the loop of frontend Web stuff for several years but I tried Vue.js because I read here and elsewhere that Angular was a mess. I just couldn't stand the weird hybrid html/css/js editing. At no point did I feel I had the slightest clue what was going on and it felt like I wasn't supposed to ask. React felt much more natural to me. Is there any way to do stuff differently with Vue or should I just stick with React?
This one was pretty good and goes into deeper details instead of just claiming x is better than y: https://medium.com/@swizec/some-thoughts-on-vue-after-deploy...
The fundamental difference between React and Vue is vision. React bets on functional programming and moves closer to reaching its goal, perhaps shedding the last OOP parts some day.
Vue follows an older paradigm, Angulars basically, but with React underpinnings. It's heavily inspired by OO templating, pseudo code mixed into html. Perhaps the gravest difference if you come from React is that it encourages mutation, to an extent that now forces it to maintain two incompatible versions going forward due to IE11's lack of proxies.
I’m the exact opposite. I took several React courses and wrote a few apps, but it didn’t click. My mind would bend but fail to fully wrap around, if that makes sense.
In comparison, within 10 minutes of reading Vue “getting started” docs I had it up and running and everything just... made sense. I have been using it for a year and a half and haven’t looked back.
You can skip both, and most of the churn by taking a look at https://mithril.js.org . It's one of the only frameworks I've seen that gets you 95% of the way while supporting you through the last 5% instead of getting in your way. It includes all the regular things you need (view, router, requests) while staying under 10kb and having better performance than those two. If you need any help at all, there's a super friendly community at gitter as well. Did i mention 0 dependencies?
If you want to give it a go quickly, just load up https://flems.io/mithril .
Here's a quick hello world. https://flems.io/#0=N4IgZglgNgpgziAXAbVAOwIYFsZJAOgAsAXLKEAG...
I have been using it for the last few years and found it to be the easiest simplest and fastest library to create an app with.
That looks really great. Bookmarked.
Shame the site is one of the rather large group of sites that assume everyone's default CSS is black on white text, though.
Well I'd be happy to make a pull request to fix it. What is your setup?
I use the option "use theme colours" in Firefox and therefore my default background is grey and default color is whitish. Basically, if you change color, make sure you change background appropriately, and vice versa. Don't assume background will be white and color will be black for everyone.
Curious: if React makes more sense to you, what would tempt you to stick with Vue?
(I work on React. Vue seems to make more sense to many people, and React to many others.)
I'm honestly shocked to see someone say they found React natural, but felt Vue was confusing.
>Is there any way to do stuff differently with Vue or should I just stick with React?
On technical side, not much.
But there are much more to it than just technical stuff.
Angular was great for big, organized teams, with spec driven development.
Separation of concerns and work was also great - having junior devs concentrate on templates and to spec written directives, while seniors deal with something more arcane.
But further they went, the more dogmatism showed up, and more it felt that they are effectively trying to invent their own language. Remember the famous "you are not doing it the Angular way!"
A big benefit of Vue is that China and big money are on the Vue train now. In China, companies are reluctant to use React.
In China, companies are reluctant to use React.
How come?
It's made by Facebook
How will they feel about Vue's new dependency on TypeScript, a Microsoft-owned technology?
Microsoft is still "kosher"
Does that really matter to them? Why?
Vue is really nice. I think a lot of the complexity, at least to me was wrapping my head around redux itself, which as you know is optional.
If next.js wasn't as nice as it appears to be, or nuxt was just as good, I wouldn't be looking at react for another project. The lack of plugins is "meh", the dev tools in React are pretty amazing. I haven't figured out a way to get a really nice stack trace in the browser for an error in Vue, react does this much better.
Experience in Vue (2.5 years and continued, 1 shipped SaaS, fairly large internal project) React (1.5 years off and on, big ecommerce furniture place)
>At no point did I feel I had the slightest clue what was going on and it felt like I wasn't supposed to ask
what exactly do you mean? you didn't understand the templating language? you didn't understand the data model? you didn't understand webpack? what does "i didn't have the slightest clue what was going on" even mean? do you know what gcc does when it compiles your C code to assembly? is that the resolution at which you'd like to know "what's happening" ???
It's hard to explain. I know how the web works. I used to write HTML in Notepad many years ago. With Vue I just didn't know how the stuff I was writing was turning into the stuff that the web browser actually sees. React is just a JS library that you can add on to your HTML and CSS and makes sense in the standard model.
I guess with Vue I just don't feel in control any more, and that's a big no for me.
It's usually React that people complain about.
If you like jQuery, you should like vue. Cause, you can use vue just by adding a script tag in your web page.
You don't need command line, web pack or any other tool to use most of vue.
You can do that with React too.
React is a great framework, the only thing I couldn't find is a great solution to have runtime templates. I know they're not optimal but for some small projects it's better to eliminate the build step. Of course no one in the right mind would manually write render functions.
I figured that's what he's doing with React. He probably stumbled upon complicated Vue tutorials.
edit: Sorry. Didn't know I was replying to you.
If you're happy with React, by all means continue with it. If you want to understand Vue, then get simpler articles/videos and ignore the unnecessarily complicated ones.
I guess with Vue I just don't feel in control any more, and that's a big no for me.
I understand your feeling, even though I don’t work in React.
I worked for a company that brought in a new guy who was all hung-ho on Vue as the new hotness. He managed to convince the project manager that we had to convert the entire site to Vue.
I was never able to wrap my brain around the fact that so much of it was opaque. You just had to trust that A would lead to B would lead to C. And when it didn’t, even the Vue evangelist couldn’t untangle it.
As I’ve explored more and more languages and frameworks over the years, some I immediately grok, and others just never make sense. I think some programmers, brains are just wired differently than others. It’s too bad that there’s this undercurrent of tribalism and brand loyalty in the industry.
I understand that because of some of Vue default conventions (like webpack and single file components). But i'm building a simple architecture to build Vue apps without the need to compile your scripts, you can check it out here:
https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...
I'm not sure what you call "hybrid html/css/js editing". Vue components are stored in single .vue file (newer angular versions also default to SFC). Within said .vue file, HTML/CSS/JS are very obviously separated. Scoped style and templates are very easy to reason about and manage, IMHO, as an underqualified front-end developer.
I’m somewhat sad that there’s so much focus on HOW related improvements and less on the WHY. What I really like about Vue was that it was one of the first tools where it’s whole MO was to get out of the way of the process of creation instead of being very in-your-face about specific features and techniques . It was iOS while react was Android.
I hope that It’s initial success bringing it more mainstream doesn’t cause enterprise pressures to make the project lose focus on this core.
Not having to deal with weird tricks for certain types of data mutations is quite nice though.
Sounds great, but why bother with the added work supporting IE11 if Vue 2.x can be used with IE11? Especially that time continues to fly until 3.x is released, and IE11 is replaced with EDGE already.
edit: I am guessing this has to do with having one codebase for projects that move to vue 3 and still need support for IE1.. makes sense. Hmm.
IE11 is still supported by Microsoft atleast up until 2021, possibly further. We bet on Vue and 5% of our enterprisey customers rely solely on IE11 for some reason or another and our competition supports it unflinchingly.
So, atleast we're very glad for this decision.
I’ve got almost 25% IE11 and XP to support. I feel your pain.
Unfortunately, IE11 is still quite prevalent in large enterprise organization with IT departments that control which browsers are installed on desktops across the org. There's a lot of bureaucracy and legacy apps to contend with before making a change to swap out a browser. For example, IT might first have to certify that a browser change would not break usability with any number of old internal company web apps.
There are also quite a number of Win32 apps with embedded browsers that are essentially running IE11. Depending on what Win32 control/plug-in was used to embed a web browser, those embedded web browsers might be stuck on IE11 indefinitely (until the authors of the Win32 app re-compile with an embedded web browser that uses Edge).
Because IE 11 is currently being used in a lot of places.
In my company, majority of desktops are on Win 7, hence edge is not an option.
the same must be the case in a lot of companies as well.
Their decision to switch to a Proxy-based observer is very much welcomed. Other libraries ( https://github.com/ElliotNB/observable-slim ) have shown that Proxy-based observers are robust and performant, but do have some polyfill restrictions for IE11 users. The ability to monitor for properties added dynamically at runtime will allow for a lot more flexibility.
Proxies still behave unusually with more complicated Objects (e.g., Date), but they work brilliantly with plain objects. Implementing an observer with Object.defineProperty is a lot more complicated IMHO.
Wow , reading comments was quite interesting.
I didn't thought so much people got "exhausted" by Angular. I personally tried it ( v2 , v4 , v5 , v6) and i really fell in love with it.
I use mostly Vue and Angular they complete each others very well , i prefer NGRX over Vuex and Angular native support for Typescript.
Typescript with Vue is a bit of hassle to set up and maintain, but with this new update this a bit of a game changer.
It appeals to a larger audience , especially those looking to build large scale project , while keeping the core of the community.
Really great news.
> I didn't thought so much people got "exhausted" by Angular. I personally tried it ( v2 , v4 , v5 , v6) and i really fell in love with it.
It's basically Java Spring IoC container ported to Javascript. But Javascript doesn't need an IoC container, it's a dynamic language... That's why I despise Angular. It's a framework that does absolutely nothing new then tries to mask its vacuity with layers and layers of complexity. It's like some people need to justify their salaries at Google so they churn useless yet elegant code. Why the heck does a JS view framework need a AOT compiler as well?
I share your view. I am generally a backend developer, I spent a lot of time with Angular(2+), recently started a project with react and also looked at Vue. so my time spent on Angular > React > Vue. If I have to choose a framework for a new project I would definitely choose between Angular and Vue, I won't write react unless I am paid. It is just verbose and ugly, no magic.
As someone who writes complex applications on the client side, I welcome a lot of the changes coming up for the next release and they are seriously anticipated.
Anything that positions JSX for Vue to be similar to that of React would be awesome for me.
I have some issues with relativity with deeply nested JSX templates. Unfortunately I wasn't able to get any help from the discord channel as most are opposed to JSX, couldn't understand my code and also state I'm doing it wrong and should use Vue components. (sigh)
In one SFC, I have over 500 instances of this.$set, really looking forward to proxies.
Finally, iframe support isn't as mature as in React. Sure there is [0] but libraries such as VideoJS [2] don't work correctly. Thus you need another Vue instance inside the iframe and have postMessage communicating updates between both data Objects with something like [1]. Which ulimately slows down the UX.
[0]: https://forum.vuejs.org/t/render-inside-iframe/6419/2
[1]: https://gist.github.com/pbojinov/8965299
[2]: https://forum.vuejs.org/t/videojs-not-rendering-inside-using...
I should mention, I do love Vue, it's awesome and a major step up from something like jQuery.
-------
Maybe someone from the core team comes across this or someone might know [4].
Taken from the: State of Vue by Evan: [3]
He mentions 4 release channels:
- Stable
- Beta
- Nightly
- LTS
Would really like to see if 2.6-next beta/nightly fixes these issues.
How can I get my hands on such a release?
That's a lot of sets. I've have you tried out deep-model? I've had varying success with this, essentially it creates a proxy object that wraps, its a computed property on your component. If vuex is too much for your application, but you're using that many $sets for whatever reason, maybe it would help?
I havent tried deep-model. To be honest, knowing about 2.6-next/3.0 on it's way. I can let it be for now and then refactor when the new version hits in 2019.
I'm not quite sure about VueX. There's this [0]. Which I'm going to attempt soon. Would be nice if VueX could help. Would solve the UX and postMessage issue that I have.
For context. It's a page builder like leadpages, elementor for wordpress, unbounce, etc. It's one big array which then gets parsed as JSX and then rendered out to the vDom.
[0]: https://forum.vuejs.org/t/share-vuex-store-with-vue-app-in-i...
What does React do with iframes? I don’t understand how you could have a component in an I frame without having two instances of React either.
Check the article here [0].
[0]: https://medium.com/@ryanseddon/rendering-to-iframes-in-react...
The ability to split Vue components into multiple (html, ts, scss) files in a single directory would be nice. I dislike the single file approach and it makes things like having nice syntax highlighting and completion more complex than it should be.
Having to repeat the component name in the "src" is less than ideal, IMO.
I've been doing that for years in one of my projects. Just reference the CSS and JS files in the .vue file (e.g. <script src='./file.js'></script>) instead of inlining them in their respective tags. How else would you want to do it?
I'd just like a directory containing a template, style and code file, the referencing would be straightforward to imply without having to repeat everywhere. Similar to how views work in Rails I guess.
You want more magic, basically. I guess that's a personal choice.
I've never personally felt inconvenienced by having this at the bottom of my .vue files:
It's not like I ever have to type it out. It gets copied along with whatever else is in the .vue file I copied from.<style src='./style.css'></style> <script src='./script.js'></script>
Another one here building a simple architecture to build Vue components in a folder instead of a file, you can check it out here:
https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...
I do it like this: https://github.com/ktsn/vue-template-loader
There's also a plugin for VSCode that let's you switch between Button.js and Button.html for example.
Using such an approach in this project: https://github.com/garage11/ca11 You can just use the vue template compiler for that.
I wish there was some sort of inbuilt support for template inheritance that you currently have to do with stuff like "pug."
Laravels blade templating engine does a great job at @extending templates from child to parent and it can be used for inspiration. Vue already has a slot tag so maybe then can add an extend tag for extending a parent template in a derived child template component.
Wow, hats off to the vuejs team. Vue is already lightning fast and I've been able to pull off some pretty computationally intense state changes which render like butter whilst other frameworks lagged. A speed increase of 100% is almost unimaginable—but welcome!
Seems like they're repeating the mistakes of Angular 2.x+. Breaking backwards compatibility and adding a ton of tool requirements and libraries for basic usage. We're still stuck on Angular 1.x for exactly that reason.
They also seem like they're going to drop IE10/11 support (ES2015 everything) thus either pushing the tool/library requirement even higher or simply not working on older browsers.
Vue.js was attractive because it was the anti-Angular 2.x, it was light weight, simple, and with nearly no requirements (on either browser or developer's machine). Now they'll just be a "me too!" Angular 2.x clone, but with a smaller community.
Did you even read the article?
"The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support. But alas, we know a lot of our users still need to support IE11 for the foreseeable future. Most of the ES2015 features used can be transpiled / polyfilled for IE11, with the exception for Proxies. Our plan is to implement an alternative observer with the same API, but using the good old ES5 Object.defineProperty API. A separate build of Vue 3.x will be distributed using this observer implementation. However, this build will be subject to the same change detection caveats of Vue 2.x and thus not fully compatible with the “modern” build of 3.x. We are aware that this imposes some inconvenience for library authors as they will need to be aware of compatibility for two different builds, but we will make sure to provide clear guidelines on this when we reach that stage."
Yes? Your quote is literally one of the things I'm complaining about.
Most of these changes are going to be added as minor version updates to Vue 2. This is unwarranted FUD.
They're dropping IE11 in some version of Vue 3, but will maintain a compatibility build, along with polyfill if a compatibility isn't possible.
They're still light weight (going to be lighter), still simple, and at its most basic, will just be a script tag added at the bottom of your HTML page.
Underqualified to speak for Vue, but practically everything you're saying is addressed in the post in very simple terms. They are breaking bc because JS and browserland are doing so, and quite quickly. That is what major releases are for. If you never do that you sink in tech debt - you know, like angular.
>> Seems like they're repeating the mistakes of Angular 2.x+. Breaking backwards compatibility and adding a ton of tool requirements and libraries for basic usage.
>> They also seem like they're going to drop IE10/11 support (ES2015 everything)
It's funny because the article says the exact opposite of these things.
Maybe you haven't read it, or actually attempted to comprehend it?
> It's funny because the article says the exact opposite of these things.
It what now?
> In addition, the API is designed with TypeScript type inference in mind. The 3.x codebase will itself be written in TypeScript, and providing improved TypeScript support. (That said, usage of TypeScript in an application is still entirely optional.)
And:
> Top level APIs will likely receive an overhaul to avoid globally mutating the Vue runtime when installing plugins. Instead, plugins will be applied and scoped to a component tree.
And:
> We are breaking some internal functionalities into individual packages in order to isolate the scope of complexity. For example, the observer module will become its own package, with its own public API and tests. [...] Decoupling the observer and scheduler into separate packages
And:
> The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support. Most of the ES2015 features used can be transpiled / polyfilled for IE11
The above is exactly what I referred to and all taken verbatim from the article. It is Angular 2.x+ all over again.
> In addition, the API is designed with TypeScript type inference in mind.
If I got that right, they plan a first-class TypeScript interface, and a second class Javascript one compiled from it. You choose whatever you want.
Their problem is that you can not derive a good TypeScript interface from Javascript. But there is no problem on doing the reverse. None of that implies in any development-time or runtime requirement.
> Top level APIs will likely receive an overhaul to avoid globally mutating the Vue runtime when installing plugins.
That is a breaking change, yes. But not a large one.
> We are breaking some internal functionalities into individual packages
That is clearly not a breaking change.
> The new codebase currently targets evergreen browsers only and assumes baseline native ES2015 support.
That one implies on development-time requirements. They still can remove that requirement from the JS compiled distribution.
Do you know any of that for sure? Maybe you should be asking more questions?
If you have something you want to contribute I'd prefer if you just did so. I don't feel like you're asking either question in good faith.
I got my information from the article this thread is about. As to if the article itself is "sure" I don't know, if you do then go ahead and contribute something constructive to the discussion.
>> If you have something you want to contribute I'd prefer if you just did so. I don't feel like you're asking either question in good faith.
Your original comment was not in good faith. It claimed the exact opposite of the things said in the article (such as dropping IE 11 support - NOT correct).
> It claimed the exact opposite of the things said in the article
I'm not sure why you've created two comment trees saying the same thing, I responded to your other comment above.
> Your original comment was not in good faith.
My original comment was my opinion based on my experience and after having read the article. If you disagree, fine, but I don't think it is fair to question my motives. Simple disagreement doesn't mean the person you're disagreeing with is responding in bad faith; asking loaded "questions" which read as thinly veiled insulted however...
At no point did I question your motives. I do question whether you understand Vue's plans.
Looking forward to better type support. Just started using Vue about a week ago and my main complaint is the lack of any nontrivial type checking. Basically, types are only checked within the context of a single script block, I can’t ensure my props are the right type, or that my event handlers are expecting the right types.
As you know, you have to register your props. You can do this in the array shorthand where you don't get to specify anything except the prop handle, or via an object with the key being the prop handle and an object with type:Function,Array,String etc. and a required property which can be true or false. You can also provide a default value here. Hope that helps!
I use the decorator (“@Prop”). If that doesn’t emit the appropriate types I would be very surprised, but then again the class style syntax has always seemed to be a bit of an afterthought, so perhaps I wouldn’t be too surprised.
But regardless are those not purely runtime checks? I was of the impression that Vue would just print something to console if you messed up there, not issue an error at build time. (And playing around with an existing project it looks like it indeed does not error at build time. That or the “@Prop” decorator doesn’t do what I’d expect it to)
Yes trying with a fresh, TS-free, default setup of Vue, the props are still verified only at run time.
Impressive list. I wonder if they can maintain the lean size. If so how faster will it be ?
If you have read the article you would have found answers to your questions. -> Gziped <10kb, and about 100% faster then vue2 on average.
I skimmed but too fast obviously
All I'd like to see is just better error reporting and debugging
This was the only thing I missed when I moved over from React 2 years ago. Vue's error messages are relatively useless, and they haven't ever improved much.
Eh, debugging experience is already great. Vue Dev Tools is just phenomenal.
Is there something specific you are looking for that is not addressed in the article? (e.g. they are adding render tracking)
My stack traces for JS errors inside component methods often stop at "This component had an error", with no line numbers or context to indicate which method had the error.
I also have the same issue. I don't know what to do to resolve it. It's not a deal breaker but it would be nice to have it unwind the stack a little bit.
> The constant baseline size for the new runtime is <10kb gzipped.
That's still way more than Preact (~3 KB gzipped), and Preact supports IE 11 out of the box. I wonder why the Vue 3 baseline runtime will still be so much larger. What does Preact sacrifice to get that small size?
One thing I was finding weird about all those template compiling frameworks is the use of javascript for parsing the page/template instead of the lightning fast browser's native parser (DOMParser)
Can somebody shed some light on that design decision?
There are other approaches: Svelte compiles directly to DOM operations, choo/Marko use the native parser through morphdom, hyperhtml and lit-html use string literals and Template instances. Most of them are faster than React and Vue but nowhere as popular.
Virtual DOM tends to be faster because bridging between JS and native layers can be expensive. If diffing is done in the JS layer, some potentially expensive calls can be batched or ignored if a change is unnecessary.
I mean why they use it at the stage when they create their own virtual DOM copy from the template string, not during the time they do changes when the app is running.
IMO, with Vue if your template needs to be parsed in-browser, you're doing something wrong (Vue has "full" and "runtime-only" builds; I don't think that you should use the full build in production). The template should be parsed+compiled to a render() function during the build process, and the browser should only ever see the render() function, not the template (except through a source-map).
Using DOMParser means parsing the template twice, once for DOMParser and once for your template syntax, making perf gains more questionable. Also, doing HTML and template parsing separately means either passing template syntax through the HTML parser, which limits possible template syntax and spends time instantiating bogus DOM elements/attributes, or passing HTML through a HTML-unaware templating language, creating all the problems and limitations of C’s #define and making it hard to react to data changes with minimal updates.
That said, it’s been done both ways. Mustache templates do string templating then use the native HTML parser, and one smaller library, I don’t remember which, parses the template as HTML then tree walks for templating controls, and cites perf benefits.
Vue 1 used to do that.
It caused issues, specifically, the svg attributes are camelCased and DOMParser would convert them to lowercase when used with v-bindings. So, Vue2 come up with its own parser to mitigate the issue.