Astro framework lowers competitors by ~40% on performance graph to looks better
twitter.com
twitter.com
At least, none they publish first.
People want better abstraction than HTML, and JS is the only simple way.
Why i should use HTML input while i have better abstraction for it ?
TLDR is, HTML is the issue, not JS frameworks.
Compared to the older alert/confirm dialogue which was driven by a C++ browser window + JS boolean it kind of makes sense for <dialog> to use JS for such a thing and keep it within the HTML/stylable context. Like confirms the only place it will be used is within JS. So there's no separating the two really.
Unless you're just looking for a glorified HTML5 tag that you have to do yourself.
But yes, HTML was clearly designed for producing output markup; but in reality the people who want to generate markup want to handle nested data, if/else, and loops, because that is better than copy pasting a bunch of markup everywhere and occasionally fat-fingering something.
<fragment href="site-menu.html"/>
I'm not sure why JS would be needed here? (i.e in the same way html <select> elements are interactive without needing "JS").
Going a little more out there, what about cross domain imports for easy web component consumption?
<fragment href="https://weather-widget.org?location=london" />
It used to be sorta possible with HTML Imports but that spec got dropped [1].
h("div", { class: "container" }, [
h("p", {}, "oh hi!"),
...projects.map(renderProject),
])
<link rel="import" href="/partials/browser-vendors-hate-this.html" />Don’t need JS to do tracking, and browsers can track without needs any marketing tags at all
Obviously browsers that directly track users will lead a stinking public cloud and litigation. Vendors prefer their customers do the tracking for them. And make the ecosystem unable to function without tracking.
Personally I love single file components. In specified having html, js and my scss in the same file, but split into <template>, <script setup>, and <style>. Nuxt 3 is fantastic DX.
Open source is supposed to be merit-driven, not hype-driven and resorting to dirty tricks like these.
I wouldn't single out the JS community is the only one affected by it. To name just two examples outside JS, I blame pipenv authors for the same truth stretchi, and if you look at the current hype around open source AI libraries, there's a lot of it going on as well.
I've never used it but I can see the value in good web design. Good Web design = good copywriting/colours/information design etc.
Maybe fancy marketing and good Web design are two different things though
> Focused on web standards and modern web app UX, you’re simply going to build better websites
I'd go with thinner fonts, less saturated colors (e.g.: the code on the right is easy to read) and larger line heights.
My main complaint would be the scrolljacking on mobile.
Remix is also run by/evangelized by people who: 1. hype their own work on Twitter with misleading comments, 2. released their framework as "pay-only" intially, 3. sell expensive coursework for their own tools instead of, yknow, having adequate documentation.
Remix also spun off into its own company before being acquired by Shopify. In fact, the whole "open-source library spins off into a company" is kind of creepy to me, although I'm sure not all are bad actors.
Someone has to get paid at some point. If this is their business why shoot it down? It's either that or subsidize this work by working somewhere that pays and leaves you with enough time for other projects.
Always wondering why devs are so cheap when they are supposed to earn that much more... Or perhaps it is just the vocal few on the internet.
I want to like Remix, but they have an odd culture around it, aren't really all that willing to talk openly about decision making or hearing valid criticism of the framework, and made some very bizarre design decisions with the framework itself, such as having zero ability to customize the build pipeline in any meaningful way
I'm not that unhappy about this, end of the day there's more accessible code, but it's also good to see what's going on.
That said, there's a certain project where I want to see the API front and center. I've seen companies make all sorts of vague marketing promises that I never understood until I saw their API.
const scoreWidth = (Astro.props.score - 33) * (100 / (100 - 33))
> (Astro.props.score - 33) * (100 / (100 - 33))
It's awesome just how quickly this got addressed.
I've started adding companies I've caught doing this to my Pihole blocklist so I can stay away from them myself, but the sad truth is that most people won't care about the lies and misdirection because advertising has normalized this type of behaviour.
This is probably the greatest time in modern capitalist history where this is wrong. If anything the youth have grown up being assaulted with marketing and become savvy dechiperers and careful. My parents generation were more easy suckers.
Being honest matters a lot on social media. People love nothing more to expose this sort of thing (drama!) and point at a company to laugh at them. This thread on HN and Twitter is good proof. Although one could argue the no press is bad press angle.
I gave Astro a look over and promised myself to be open minded; but I wasn’t really digging how opinionated their code was to themselves. Thousands and thousands of devs built on top of each others JavaScript improvements for years, and then Astro comes along and decides that us developers need to learn a new “.astro” syntax as well.
Imagine if Tailwind or Laravel forced you into funky .tailwind/.laravel named files because they felt a certain way about their name.
I took this as a sign that Astro might become a very money hunger shark at the first drop of blood like other popular CMS providers have done in recent memory.
I’m working on a free open source side project now for fun with the goal of helping more people create and own their own content online, without paying an arm and a leg for it.
I’d love more support and feedback if anyone has any to give :)
If you feel that developers need an open and extensible product for creating content, please give me a star, and open some PR’s and issues.
There is massive value in being the most popular framework. Even if it's not as nice as the other ones just the pure scale and quality of the 3rd party packages, plug and play integrations, component libraries, support posts, etc... that stuff really matters when it's your day job.
One big one that's burned me is a lack of (well supported) Vue SSR integration in Ruby on Rails.
I'd personally just stick to Next.
Next/Nuxt really take Vue and React to a whole new level when building a wet application.
I’m very well versed in all 3 of big reactive JavaScript frameworks, and React is my go to for now.
I switched from Vue to React as my default after struggling with complex data tables in Vue; when React had a bunch of libraries on GitHub that would work for my project at the time.
The final nail in the coffin was a contract requirement for .Net core framework, and it came bundled with React in it already. From there, I found Next, Typescript, and Tailwind, and haven’t looked back :)
More packages is good and bad. Any given project you picked up in Vue over the years mostly used the same router, store, etc. You didn't have to learn a new css-in-js library every time you work on a different codebase. The only thing consistent was everyone (over)using Redux, which I honestly wasn't a big fan of vs Vuex.
React did / does have a much larger selection of quality ui component libraries, which is nice. The biggest upsides imo were that Vue has relatively bad typescript support vs React, and it's easier to hire shitty contractors that already know React.
That's a very good point
I look at each of the 3 big reactive frameworks as different types of screwdrivers in my tool belt; each with their own pros/cons, and purposes.
As commenter above said, I’ve seen a mess of all 3 frameworks; and I’ve also seen some beautiful works of art, with even Angular too lol.
> I took this as a sign that Astro might become a very money hunger shark at the first drop of blood like other popular CMS providers have done in recent memory.
You’re reading way more than what’s reasonable. Vue, React, Svelte have their own file types. The reason has nothing to do with branding. Astro’s syntax is just different from anything that exists and having a dedicated file type makes sense.
.astro files are not .ts or .tsx. Similar to .vue files, they have their own structure that needs to be interpreted.
Please explain why they needed to create their own style?
Just a plain old dumb JavaScript file, but just written in the Typescript superset.
JSX is an optional extension of JavaScript which adds a few syntactic sugar features, e.g. writing `<FooComponent ...` instead of `const FooComponent = () => createElement(...`. It's completely distinct from templates in Vue or Svelte. This is crucial, because templates are a bad idea. As Steven Wittens[1] put it:
> Many competing frameworks acted like this wasn't so, and stuck to the old practice of using templates. They missed the obvious lesson here: every templating language inevitably turns into a very poor programming language over time. It will grow to add conditionals, loops, scopes, macros, and other things that are much nicer in actual code. A templating language is mainly an inner platform effect. It targets a weird imagined archetype of someone who isn't allergic to code, but somehow isn't smart enough to work in a genuine programming language. In my experience, this archetype doesn't actually exist. Designers don't want to code at all, while coders want native expressiveness. It's just that simple.
The .astro extension is the glue needed to put together react/vue/svelte under the same project. You don’t even have to use any of it’s features.
But that's not the only use case - it's actually simpler to setup any of those libraries with Astro, than using their own recommended frameworks. And you get partial hydration as a default, instead of sending your entire app over the wire including all static content.
Not labeling the axis is of course even worse.
While Hugo and Zola can generate light and heavy websites easily depending on the developer's choices, Astro aims to express that it's easier to create fast websites, even ones that are interactive, with Astro than with a fuller framework like NextJS.
The core web standards are designed for future and possibly non-human archaeologists to be able to view just about every web document created since 1991.
World's first website. http://info.cern.ch/hypertext/WWW/TheProject.html
So if the job is to deliver content focused websites, then the best tools are those that are designed to get out of your way. Astro and the every other tool that is not a single executable is completely outclassed due to their reliance on package management ecosystems. People want fast consumption and production? Send fewer bytes over the wire, use less bytes to produce them, and let the platform do its job.
But this is just like my opinion, man. None of this matters if the power goes out. Fun game, though.
This is a learned behavior and it can be fixed. I'm mostly broken of it; I assume it's not until I see that it is. Only mostly, not claiming to be a bias-free superhuman here, but as a for instance I had to check the comments to see what was offending people about this chart because I didn't assume it was anchored at zero in the first place. I recommend making the effort if you can; most charts out of school aren't anchored at zero, many wouldn't even be useful if they were.
What jumped out at me actually was the lack of units. At least it links to the original report, and I think this is the Lighthouse Performance Score, which... is itself in units I don't understand? It's some sort of percentage, not speed measure, I think... looks like percentage conformance to an SEO/performance test suite? I'm not sure this is really something that can be bar graphed in the first place sensibly. Percentage conformance to test suites is at least a marginal case at best for a bar graph... how "numeric" such a quantity is is very debatable. e.g., a 40% compliant product may in fact be "less" compliant than a 30% compliant product if the former is compliant on a whole bunch of incidental check points but misses the most important ones, where the latter is compliant on the important ones and misses the incidentals, so such "percentages" can break simple numeric properties like comparability or the transitivity of such comparisons and really aren't numbers. Compliance to such a test suite will also be highly dependent on how you use the system; odds are its competitors can be tuned to go higher without much work and that very easy-to-make mistakes will send a Astro-based site plummeting because of what a user might naturally do with it, through no fault of the framework.
What would make it useless to start a graph at zero?
Whether that is "useless" depends on your point. If you want to make a point that they are not large percentage fluctuations you may prefer to anchor it at zero. But if you want to talk about the fluctuations themselves, you want the chart to be full of those fluctuations, not anchored at zero and all the fluctuations just little wiggles relegated to the top.
So it does depend on what you want to do, but there are use cases where anchoring at zero is either useless, or even itself at times deceptive, especially in cases where "zero" is not a particularly distinguished value on its own. (e.g., voltage. zero voltage is itself a relative measure to some standard of voltage, so a voltage chart being anchored to zero may not mean anything if zero voltage in some context isn't special but is itself somewhat arbitrary.)
The problem that people have with not starting at zero is how arbitrary it is. You can tell a completely different story depending on where you choose the starting point. So there should be some kind of justification for the chosen Y range.
Wouldn't you then plot the _fluctuations_ anchored at 0?
Same with voltage, using some 'absolute' voltage value doesn't make sense. If you put ground and zero at 100V and the positive node to 105V, your 5V device will work just fine.
Always good reading, find at a library near you!
document.querySelectorAll('div.noise-underlay').forEach(e => e.innerText = e.style.width);
Gatsby 52.2388% Score:68
Next.js 44.7761% Score:63
WordPress 37.3134% Score:58
Nuxt 31.3433% Score:54
Scores need to be adjusted by and looked at through the lens of complexity. Next.js powers some of the most sophisticated web applications in the world, not just your blog and mine.
e.g.: the instant you bring "necessary evils" like display ads, your scores WILL suffer.
The bias we're seeing here is that NextJS is more popular and slow sites are being made with it, while people who choose Astro are more inclined to value the speed of their site.
Edit: It seems specific Tweet URLs and the status page work but the timeline does not.
all this while the stats themselves seem to be correct.
It‘s probably done to provide a more interesting graph. Something quite common in infographics. Playing devil’s advocate here, if you aren’t able to see that a number higher than 50% isn’t supposed to be left of center, you’re probably in the wrong business anyway.
Arguably it would have been more innocent if they indicated the shift by cracked bars [1], but then this is probably not provided by the charting library they use (or any that I know of).
[0]: https://astro.build/blog/2023-web-framework-performance-repo...
(Did this by just changing the width percentages of the bars to the numbers shown on the graph itself.)
What's the deal with that?
It did ask me if the image contained matured content, to which I said no. But for some reason it still marked it as mature? Very weird...
They can't guarantee a random picture uploaded by a random user isn't porn. (though they give a best effort). Additionally the side bars show what's most popular. In theory something NSFW could end up with a thumbnail on an unrelated picture. So they give you the warning ahead of time. (I've used imgur tons and never seen this.)
This picture was a graph.
They really don't have to. I really like astro. They got a lot of things right. It is my go to choice for websites these days. I say this as a creator of one of the popular Static Website Generators.
I’m sure there’s a solution somewhere out there - perhaps a crowdsourced website akin to the Google Graveyard[0], or certain fact checking sites, where bad faith decisions could be archived and accumulated until it becomes obvious which companies are simply not worth the trouble of working with.
It's like we have a fire alarm going off in a building other than the one that's on fire.
I don't know if the JS community is specifically vulnerable to this, or it's universal. It seems to happen a lot though.
What's in it for them? Bunch of free souls just showcasing their excellence or what's at play? Or there's hidden underground cash flow rivers that a casual observer misses totally?
Genuinely oblivious and curious.
Real world performance degradation happens due to poor coding, endless dependencies, large amount of API calls that block rendering, and a huge amount of 3rd party (tracking) tags.
The core framework is the least of your problems.
It's perfectly fine to display data this way, but they should make it clearer that the start isn't 0 by using wiggly lines or by labelling the origin.
"Have you ever seen a hospital that doesn't have string?"
I’d like to hear more of your thoughts on this.
Those differences manifest as real pains/joys when used by devs. Market those!
I can see perf being a marketing point on some things. But for static site generators it feels like a symptom of the bar of quality being too low, or everyone just cargo cults Apple’s marketing schtick.
[0]https://www.engadget.com/twitter-quietly-backtracks-on-requi...
(ok, they pretty much all do this...)