Plans for the Next Iteration of Vue.js(medium.com) |
Plans for the Next Iteration of Vue.js(medium.com) |
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.
remove the (properly) and I'd give the technology some credit. Otherwise it's just "no true Scotsman" fallacy.
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.
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.
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.)
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.
The IDE support in VSCode is at least partially driven by type declarations from TS projects, so regular JS is benefiting from TypeScript.
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?
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.
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.
- 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).
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.
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.
> 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.
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.
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.
So, atleast we're very glad for this decision.
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).
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.
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.
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.
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?
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?
https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...
There's also a plugin for VSCode that let's you switch between Button.js and Button.html for example.
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.
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.
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)
Is there something specific you are looking for that is not addressed in the article? (e.g. they are adding render tracking)
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?
Can somebody shed some light on that design decision?
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.
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.
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.
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.
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).
I can't imagine recommending TypeScript to anyone I like.
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?
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.
@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
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.
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.
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...
Shame the site is one of the rather large group of sites that assume everyone's default CSS is black on white text, though.
(I work on React. Vue seems to make more sense to many people, and React to many others.)
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.
How come?
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)
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" ???
I guess with Vue I just don't feel in control any more, and that's a big no for me.
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...
[0]: https://medium.com/@ryanseddon/rendering-to-iframes-in-react...
"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."
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.
>> 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 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.
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.
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.
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.
I've never personally felt inconvenienced by having this at the bottom of my .vue files:
<style src='./style.css'></style>
<script src='./script.js'></script>
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.
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.
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.
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.
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.
TS is like swift, and it does not require type declaration. A lot is automatic.
enum Color { Red = 1, Green = 2 }
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.
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.
* 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 love JS too, but I have yet to get Webpack or Babel working in less than a couple of hours.
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.
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).
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...
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.
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 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.
https://unpkg.com/@arijs/vue-generator/outra/pagina/index.ht...