Plans for the Next Iteration of Vue.js • Hacker News Board

Re: Plans for the Next Iteration of Vue.js

#141

Post by Allower » Mon, Oct 01, 2018, 1:14 PM UTC

eksemplar wrote: post #125

russellbeattie wrote: post #81

I'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…

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…

It saves a ton of time in the maintenance phase. Also the compile time type checks are very useful when working with more junior developers (though they save me time too occasionally). Coupled with a good IDE intellisense makes later code extensions a breeze.

Re: Plans for the Next Iteration of Vue.js

#142

Post by russellbeattie » Mon, Oct 01, 2018, 1:35 PM UTC

linkmotif wrote: post #139

russellbeattie wrote: post #121

Earlier quoted context omitted.

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 simila…

> 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…

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.

Re: Plans for the Next Iteration of Vue.js

#143

Post by james-mcelwain » Mon, Oct 01, 2018, 5:24 PM UTC

eksemplar wrote: post #125

russellbeattie wrote: post #81

I'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…

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…

> 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.

Re: Plans for the Next Iteration of Vue.js

#144

Post by klodolph » Mon, Oct 01, 2018, 8:54 PM UTC

guessmyname wrote: post #114

klodolph wrote: post #97

Earlier quoted context omitted.

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-comp…

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.

Re: Plans for the Next Iteration of Vue.js

#145

Post by klodolph » Mon, Oct 01, 2018, 9:01 PM UTC

aczerepinski wrote: post #103

klodolph wrote: post #97

Earlier quoted context omitted.

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.

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

Re: Plans for the Next Iteration of Vue.js

#146

Post by glitchdout » Tue, Oct 02, 2018, 12:40 AM UTC

realusername wrote: post #134

russellbeattie wrote: post #124

Earlier quoted context omitted.

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…

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:

    enum Color { Red = 1, Green = 2 }

would be the same as:

    var Color = {
      Red: 1,
      1: 'Red',
      Green: 2,
      2: 'Green'
    }

See for yourself: https://www.typescriptlang.org/play/#src=enum%20Color%7B%0D%...

But I agree with you, it would be quite easy for an automated tool to replace a TS enum with pure JS.

Re: Plans for the Next Iteration of Vue.js

#147

Post by eksemplar » Tue, Oct 02, 2018, 4:55 AM UTC

james-mcelwain wrote: post #143

eksemplar wrote: post #125

Earlier quoted context omitted.

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…

> 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.

Re: Plans for the Next Iteration of Vue.js

#148

Post by realusername » Tue, Oct 02, 2018, 5:50 AM UTC

glitchdout wrote: post #146

realusername wrote: post #134

Earlier quoted context omitted.

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: enum Color { Red = 1, Green = 2 } would be the same as: var Color = { Red: 1, 1: 'Red', Green: 2, 2: 'Green' } See for yourself: https://www.typescriptlang.org/play/#src=enum%20Color%7B%0D%... 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.

Re: Plans for the Next Iteration of Vue.js

#149

Post by jeremychone » Tue, Oct 02, 2018, 4:30 PM UTC

russellbeattie wrote: post #81

I'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…

> 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).

Re: Plans for the Next Iteration of Vue.js

#150

Post by another-cuppa » Wed, Oct 03, 2018, 2:22 PM UTC

porsager wrote: post #85

another-cuppa wrote: post #62

Earlier quoted context omitted.

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.