[homebrewer]

Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers. One of the projects I'm working on has been going for many years (since before React hooks were introduced), and I remember building it back in the day with tooling that was considered standard at the time (vanilla react-scripts, assembled around Webpack). It look maybe two minutes on a decent developer desktop, and old slow CI servers were even worse. Now Vite 8 builds it in about a second on comparable hardware. Another demonstration of how much resources we're collectively wasting.

[this_user]

> Very pleased to see such performance improvements in the era of Electron shit and general contempt for users' computers.

Luckily, we have invented a completely new nightmare in the form of trying to graft machine-usable interfaces on top of AI models that were specifically designed to be used by humans.

[itsTyrion]

the vite Homepage lags on both an A55 and s23fe regardless, which bears at least some irony

[vbezhenar]

It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me. Web development should strive to launch unchanged sources in the browser. TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

[__alexs]

JavaScript was not supposed to a lot of things.

[karel-3d]

Well JavaScript was supposed to be a glue between browsers and Java Applets.

[Aldipower]

Steve Jobs decided differently when he hated on ActionScript.

10 years ago this sentence probably would have start a flame war. ;-)

[brookst]

Jobs’ complaint wasn’t actionscript the language, it was the security and performance nightmare of the Flash runtime.

Though it’s hard to imagine what the web would look like if the language had become the standard. JS is a pain but AS was even less suitable for general purpose compute.

[Aldipower]

And at least the "performance nightmare" is an irony from today's perspective as the Flash player wasn't actually slow at all! It was the incapability of the Safari browser to handle plugins in a good way and on mobile devices. Today's implementations of mobile application, JavaScript heavy applications and websites are much much more performance heavy.

ActionScript3 was a very suitable language.

[c-hendricks]

Flash performance was also hit or miss on Linux.

[brookst]

Eh, language was fine, runtime was pretty bad.

[dschu]

And yet it pays my bills for almost two decades.

[azangru]

Probably wasn't supposed to either :-)

[dschu]

Nice gatekeeping. :-)

[olmo23]

If you're already passing over the sources to strip the types, why would you also not do tree-shaking and minifications?

[ZiiS]

Why would I want to strip my types?

[wildpeaks]

Because it's a waste of bandwidth if they're not enforced at runtime, the same reason why minification exists.

[ZiiS]

Both not minifying and including unenforced type hints consumes a little bandwidth though this can be largely offset by compression. This is an engineering trade off against the complexity of getting source maps working reliably for debugging and alerting. If I am shipping a video player or an internal company dashboard how much of my time is that bandwidth worth?

[dminik]

Maybe because TypeScript is not valid JavaScript (yet)? If you don't strip types, your code doesn't work.

[wildpeaks]

It depends on the runtime: Node can run Typescript because it automatically strips types (which is so convenient during development).

But in browser, for now only the more limited JSDoc-style types can be shipped as-is indeed.

[1dom]

This feels like a ridiculous thread that captures everything wrong with modern Javascript ecosystem.

It's grown into a product of cults and attempted zingers rather than pragmatic or sensible technical discussions about what we should and shouldn't expect to be able to do with an individual programming language.

edit: to clarify, I assume there needs to be a basical level of comprehension of programming languages to debate the nuance of one, and if you can't think of a single reason as to why someone would want types removed, that's a possible indicator you don't have that necessary level yet, and I think the most effective way for you to learn that is to Google it. Sorry for coming across as rude if you genuinely don't know this stuff.

If you already know many reasons as to why types would be removed, then it seems disingenuous to ask that question, other than to make the point that you feel types shouldn't be stripped. If you think that, say it, and explain why you think they shouldn't be stripped.

[ZiiS]

The current state of Javascript is you _have_ to remove types; I was pointing out I can think of reasons why I sometimes wouldn't want to. (Admittedly in a glib manor; though on this site many prefer that to four paragraphs)

[1dom]

I agree entirely on all points. It'd save me time too:)

[pestatije]

How goes that saying?... always assume ignorance or malice will getcha

[curtisblaine]

Hear me out: javascript integrates types as comments (ignored by default) in its standard and engines start to use types as performance / optimization hints. If you mistype, your program runs, but you get worse performance and warnings in console. If you type correctly, your program runs more efficiently. We already have different levels of optimization in V8 or JSC, why can't they use type hints to refine predictions?

[azangru]

> TypeScript also was specifically designed so engine could strip types and execute result code. These build tools should not exist in the first place.

Was it? Have you forgotten namespaces and enums?

[MrJohz]

More recently, it's been designed so this is the case. Namespaces, enums, and the property constructor shortcut thing were all added relatively early on, before the philosophy of "just JS + types" had been fully defined.

These days, TypeScript will only add new features if they are either JavaScript features that have reached consensus (stage 3 iirc), or exist at the type system only.

There have been attempts to add type hints directly to JavaScript, so that you really could run something like TypeScript in the browser directly (with the types being automatically stripped out), but this causes a lot of additional parsing complexity and so nothing's really come of it yet. There's also the question of how useful it would even be in the end, given you can get much the same effect by using TypeScript's JSDoc-based annotations instead of `.ts` files, if you really need to be able to run your source code directly.

[tshaddox]

> TypeScript also was specifically designed so engine could strip types and execute result code.

That's no less a build step than concating, bundling, minifying, etc. When people say "I'm against processing code before deploying it to a web site" but then also say "TypeScript is okay though" or "JSX is okay though," all they're really saying is "I like some build steps but not others." Which is fine! Just say that!

[mexicocitinluez]

> It is especially weird because JavaScript was not supposed to be processed at all! This is all wrong if you ask me.

You're not actually suggesting that technology can't evolve are you? Especially one whose original design goals were to process basic forms and are now being used to build full-blown apps?

It's absolutely wild to me that with everything that has happened in the last 2 decades with regard to the web there are still people who refuse to accept that it's changed. We are building far bigger and more complex applications with JavaScript. What would you propose instead?

[jhgb]

If you want to make ultra-complicated clients, I assume that's what WebAssembly is heading towards. And it doesn't limit you to a poorly evolved language that wasn't intended for ultra-complicated software in the first place, or even force you to use that poorly evolved language on a server if you need to run the same logic in both places.

[mexicocitinluez]

You're moving the goal posts.

It was originally about build steps but now you're talking about it's design.

And your only response is to use a technology years away from being practical for most web apps?