Live data from Hacker News

Vite 8.0 Is Out

vite.dev

211–216 of 216 posts

Re: Vite 8.0 Is Out

#211

Earlier quoted context omitted.

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.

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.

Eh, language was fine, runtime was pretty bad.

Re: Vite 8.0 Is Out

#212

Yesterday I stopped hating AI because it converted an old webpack project with impenetrable plugin settings to a single simple Vite config. I still don't understand how people used to think scripts like this are the proper way to bundle an app. https://github.com/facebook/create-react-app/blob/main/packa... vite is great, is all I am saying

People fought to replace the tools of the era with this. It had some advantages over time - ES6, a good plugin ecosystem, react adoption - but quickly it just became "the standard" which everyone is afraid to question.

I used to maintain a build workflow library [1] a lifetime ago; while our frontend build needs have evolved way beyond it, I can't avoid the feeling that we overengineered a little too much.

[1] https://github.com/ricardobeat/cake-flour

Re: Vite 8.0 Is Out

#213
post #205

Earlier quoted context omitted.

Dude you're complaining about the efficiency of free software. Go write the software yourself, no one owes you anything. Maybe if you had to actually write it yourself, you'd quickly figure out why people prefer "inefficient" languages for these things. A cron job scheduler does not in fact require 500 MB of memory. You're just being disingenous, that software is doing a lot more than just that.

I am writing software myself and your attitude is just weird. We should always strive for better more efficient software, the climate crisis is a real thing and our industry has done an excellent job exacerbating it with more inefficient tools, libraries, and languages. People prefer JS because all they know is JS, it's that simple. Please tell me why you think devs choose JS, I'm legitimately curious but your attitu…

People choose JS because it’s the only first class browser language. Why they choose it on the backend I honestly couldn't tell you.

Re: Vite 8.0 Is Out

#214

Yeah, it makes you wonder how much computing power the industry has wasted over the years on tools that nobody questioned because "that's just how long builds take." We planned our work around it, joked about creating breaks, and built entire caching layers to work around it. Kudos to the Vite maintainers!

Build performance has been a pet topic for me for quite some time when I realized I was wasting so much times waiting for stuff to build 14 years ago. The problem is especially endemic in the Java world. But also in the backend world in general. I've seen people do integration tests where 99% of the time is spend creating and recreating the same database over and over again (some shitty ruby project more than a decad…

>With Kotlin/Spring Boot, compilation is annoyingly slow. That's what you get with modern languages and rich syntax.

This is because the kotlin compiler is not written in the way people write fast compilers. It has almost no backend to speak of (if you are targeting the jvm), and yet it can be slower at compilation than gcc and clang when optimizing.

Modern fast compilers follow a sort of emerging pattern where AST nodes are identified by integers, and stored in a standard traversal order in a flat array. This makes extremely efficient use of cache when performing repeated operations on the AST. The Carbon, Zig, and Jai compiler frontends are all written this way. The kotlin compiler is written in a more object oriented and functional style that involves a lot more pointer chasing and far less data-dense structures.

Then, if run on a non-graal environment, you also have to pay for the interpreter and JIT warmup, which for short-lived tasks represents nontrivial overhead.

But unlike header inclusion or templates, which are language level features that have major effects on compilation time, I don't think kotlin the language is inherently slow to compile.

Re: Vite 8.0 Is Out

#215
post #93
post #82

Earlier quoted context omitted.

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…

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)

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