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 statistics are not by Astro or an affiliated entity. The graph shows average "real world speeds" on sites developed with different frameworks.
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.
Mathematically not wrong, but most definitely misleading/unethical. I don't think this was done unintentionally either, because the graph would still be perfectly readable without this change (as opposed to "a few points variation" where such zoom would be required)
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.
Seems an odd choice of deception, since the real graph really would just compress the competitors closer together, wouldn't make any of them look that much better really?
A bit, but even in the actual numbers, 98 compared to 68 is pretty decent? But yes, of course I'm not commenting on how fair the test was anyway, just the presentation.
"The left side of the graph is not 0% but out of habit we think it is."
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.
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.)
If you want to make a chart about the fluctuations themselves, another way would be to show the differences on chart with a centerline at zero and bars that go positive and negative. Or if you really want the cumulative then normalize the first or last data point to be zero.
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.
I don't know 100% if you think you're disagreeing with me or not, but I'd consider your second paragraph a restatement of my point from a very different (and still valid) point of view. It's always something that a graph maker should be thinking about for sure, and a blanket "anchor it at zero" is neither desirable, nor even necessarily possible all the time.
> 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.
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.
I just assume that if the axes or the columns of a graph are not labelled or they don't have units the graph is worthless and whoever made it is either incompetent or worse, trying to manipulate people.
I looked at this chart just yesterday for a quick evaluation. The statistical axis deception was totally lost on me. However my first thought looking at this graph was that they don't compare themselves to the fast competition.
While Astro technically competes directly with Zola or Hugo, a comparison with them would not make sense. The chart is not about build times or anything like that, it's about the average performance on real world sites built with the framework. Astro with first-class support for interactivity through JS frameworks, and triest to compete with other JS frameworks in speed.
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.
Yeah. I thought about that right after I commented, but their website says "content-focused" not interactivity. Every frontend developer who uses a framework (myself included) will eventually learn the hard lesson of "use the effing platform". Any barrier to serving and delivering HTML, CSS, and JS (for interactivity only where you need it) is a waste of time and energy. Maybe not at the start, but most certainly in the long term through package depreciation, repo weaponizations, or political activism.
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.
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.
There deserves to be a serious discussion of whether Twitter content should even be allowed here anymore if it can't be seen. We already hated it before the acquisition, and it's gotten worse since then.
I don't know anything about Astro, but that graph reminded me of the Monty Python animation of Crelm toothpaste ... seems like Astro only provides 98% protection!
I don't know anything about Astro, but that graph reminded me of the Monty Python animation of Crelm toothpaste ... seems like Astro only provides 98% protection!
"Have you ever seen a hospital that doesn't have string?"
I was enlightened about this decades ago by Edward Tufte [0] - sadly since then I get annoyed by most graphs I see, where they exaggerate the difference in values with a non-zero axis.
I've seen a lot of shenanigans in JavaScript framework benchmarks. For example when Pino (logging framework) compared itself using buffered mode (where the logs don't immediately pipe to stdout and a crash wipes x kb of logs).
I don't know if the JS community is specifically vulnerable to this, or it's universal. It seems to happen a lot though.
JS is in a state where it is so flooded with frameworks that they have to compete heavily in marketing and hype generation. Unfortunately that incentivizes shady and misleading practices like this.
I just want to say that open-source projects like these that have these fancy marketing pages and rely on a huge amount of marketing tricks & twitter reposts makes me less likely to use them. Unfortunately, this is all too common in the JS world these days.
I highly agree. The main web frameworks I use are Svelte and Sveltekit. No comparison charts to other projects, easy to use, simple, created by a seemingly normal guy with sane opinions out of need for something like it for himself.
It's not the end all be all, but works well for me.
The JS world is pretty weird though. It's not only JS frameworks popping up in rapid succession but also browser features and proposals developing quickly. And what's really weird is how some new features rely on JavaScript, such as the newer <dialog> HTML element.
> And what's really weird is how some new features rely on JavaScript, such as the newer <dialog> HTML element.
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.
Yes, it's awful that HTML is now dependent on js... how did we let that happen?? I'm thinking mostly of HTML5 web components, which, unless I missed something, are completely useless without js. All I wanted was a way for HTML to import other HTML. This seems to be the central issue that we've been hacking around for decades with SSI, template languages, and js. It's so basic -- everybody wants a header and a footer and maybe a menu on each page. Should be an HTML feature.
You're basically suggesting implementing JS within HTML, which htmx exists on a technicality, but not sure that's something we should be pushing at all. We're just spreading JS problems to HTML which is a perfectly fine language.
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.
the end result will have no JS if all you want is reuse HTML parts, much better than template languages imo (no additional syntax, has loops / functions / variables out of the box)
That's not true. Declarative shadow DOM is supported in Safari, Chrome, and Edge, but that is not the same as declarative custom elements, which don't have a spec yet.
Web components are custom HTML elements, which typically combine state behavior and state-based rendering. How do you expect to do that without JS, at least without porting a non-trivial subset of a JS-like programming language into HTML?
Once upon a time we had HTML Imports which were lovely. But it made browser vendors nervous since folks could do stuff without Javascript. And what would then happen to all their tracking ? So, they unanimously purged the feature.
Not a big deal. There are already render blocking resources today. Could be ameliorated with an async attribute if needed.
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.
For what it’s worth, Astro is a static site generator that only relies on JavaScript at build time, and has optional integration with the usual js frameworks. In many ways that’s what it does solve (just importing html)
Fantastic docs, and primo documentation is not to be underestimated. Picking it up was a cinch.
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 always seen Remix on mobile not desktop, so I may have to reserve my support for it. I don't mind bold fonts and saturation when it's used on marketing sites. Web standards and the like or most suited for utility sites and business tools like Google and Wikipedia. The documentation section of a framework site and the more serious stuff definitely should keep it simple and standard though.
My main complaint would be the scrolljacking on mobile.
It's a cool site for sure, but it's also hype-driven and buzzword heavy.
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.
Well it's either that or you don't have a library and have wait for someone employed by a company to release something.
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.
Remix has sketchy/questionable marketing. Seemingly independent techfluenchers suddenly endorsing the product. Unfair comparisons with competitors to make the product look better. Most people talking about Remix aren't actually using it. Red flag to me.
Before, during, and current, though the Remix hyping train has fallen quite a bit as of late, I think in no small part due to Twitters recent changes.
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
Yep. And what I'm always pleased to see is projects that have a section or page dedicated to explaining why it might not be the right tool for you, whereas commercial software tries to convince you it's fit for every purpose. And it's quite common to see FOSS projects linking to their "competitors". That sort of integrity is worth far more than any snazzy marketing website (plus some the best tools often have websites that look like they were designed in 2005 anyway)
Projects like these scream "we are VC funded and will need to figure out a 10x exit one day". And that exit will only come by converting all the generated community goodwill into cash. Staying away from them is the correct decision.
Exactly, this is a form of marketing VCs found. Instead of using up say $500k on Google ads, you use up 6 months of development as marketing costs, open source whatever you come up with in that first bit, and from then onwards you only develop the paid parts.
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.
Ideally frameworks will be simple enough that chart isn't necessary and people can tell with their logical engineer mind how fast it will be by understanding how it works (or better, can implement a POC yourself in an hour). If I can't do that for a framework I won't use it because I'll probably mess up (React is an exception because I will still mess up even if I know 100% how it works).
Appearing immature has been a long-standing issue with some open-source projects. Desktop environments have never had the polish or cohesion of even Windows, and a large part of that is not attracting as many UX or design contributors. Seeing a marketing page could be a sign that they also put effort into a cohesive API and good docs.
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.
The experience of using a framework or a library is a very real and tangible thing. You might have 5 different contenders for a particular task and they all exist at different spots in the design space.
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.
Yeah same, I clicked then half a second later realized it probably wasn't going to load... then it did. Seems like Enron might be backtracking already.
Imgur is used for both regular content and adult content.
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.)
Remember, any graph without properly labeled axes and units is trying to mislead you! This goes for Javascript frameworks, startups trying to get their first customers, Apple performance graphs, and any other type of commercial!
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.
> 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 really didn’t hear about Astro until more recently after I started playing with blogging using Next.js.
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.
I develop my company front end in Vue 3 and as much as I love Vue I'm constantly looking over at React with a bit of jealousy.
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.
Yeah I hear your complaints about Vue 3. I had the same experiences when I was building a few apps with it pre 2020.
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 :)
I've worked in Vue since 0.12, and have done a few React projects along the way, and mainly manage projects using React now. Overall I've seen people make a mess of both.
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.
> 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
> 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.
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.
I just read the part about astro components and reasoning about “code fence”. How exactly do you propose to use .tsx files for their case? Specifically, how would you extract a template but run the rest of the code? I have some ideas, but they aren’t more practical than just splitting it across that fence.
The React library requires no custom file types, and doesn't have templates. Just import the React package into your pure JS project, and get crackin'. Just like jQuery.
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.
Well, not everything works or needs to work like that. Astro is not unique in using templates and it is rather justified in using them being a sort of next-gen SSG.
You can use Astro as a build system for React if you want. But using Astro files lets you do some more interesting compile-time stuff, like resizing images for production from their sources.
It can be a great way of migrating from one another while allowing them to coexist.
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.
I'm aware, this was actually an issue prior to my PR as well, but less obvious. I think this would need some more defensive CSS to maybe shift the label around to the inside of the bar? Or perhaps the labels are unnecessary (it is a p90 of an average of a ton of lighthouse scores after all, not like the number quantifies to much)
Seems like now, predators due to some padding with the number text, the bar chart is still not proportional (but in the other direction. 98 should be further out)
This is inexcusable, and provides no benefit other than intentionally confusing the reader. I wish companies were more afraid of using blatant dark patterns in whatever they publish.
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.
Bar graphs not starting at 0 are misleading, even when the axis are labeled. The point of a bar graph is that you can intuitively compare the visual weights or areas of the bars, which doesn't work if they are cut off.
I feel like this is an intentional error designed to illicit exactly the sentiment expressed by many people commenting here. That is to say, this is manufactured outrage. And look at the results: Astro made it to the front page of HN!
The report [0] this graph was based on also has major issues as it does not consider versions of the frameworks and includes sites using old versions of Next or Nuxt compared to only new sites for Astro as it's a new framework. There have been major changes for example between Nuxt2 (Vue2) and Nuxt3 (Vue3). They at least disclose that at the end of the report but it still leaves a bad taste because it should have been possible to differentiate these without too much work and they were aware of the problem. Another issue is that Astro seems to be used a lot for static sites whereas the others mostly for dynamic ones. I feel like it's really not a fair comparison.
148 comments
[ 3.1 ms ] story [ 74.6 ms ] threadGatsby 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.
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.
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!
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.
Edit: It seems specific Tweet URLs and the status page work but the timeline does not.
"Have you ever seen a hospital that doesn't have string?"
[0] https://www.edwardtufte.com/tufte/books_vdqi
I don't know if the JS community is specifically vulnerable to this, or it's universal. It seems to happen a lot though.
At least, none they publish first.
https://youtu.be/AdNJ3fydeao?t=1083
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.
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?
I can't see how this would be less secure than current cross domain JS imports?It used to be sorta possible with HTML Imports but that spec got dropped [1].
[1] https://www.w3.org/TR/html-imports/
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.
https://remix.run/
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.
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...
(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.
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.
https://github.com/elegantframework/elegant-cli
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.
[1] https://acko.net/blog/get-in-zoomer-we-re-saving-react/
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.
> (Astro.props.score - 33) * (100 / (100 - 33))
It's awesome just how quickly this got addressed.
Edit: https://github.com/withastro/astro.build/pull/731
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.
[0]: https://killedbygoogle.com/
Not labeling the axis is of course even worse.
[0]: https://astro.build/blog/2023-web-framework-performance-repo...