Reminds me of this quote by Bill Gates to Steve Jobs, when Jobs accused Gates of stealing the idea for a mouse:
> "Well, Steve… I think it’s more like we both had this rich neighbour named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it."
I'm sure it can diagnose common, easily searchable well documented issues. I've tried LLMs for debugging and it only led me on a wild goose chase ~40% of the time.
But if you expect it to debug code written by another black box you might as well use it to decompile software
Sometimes the error message is a red herring and the problem lies elsewhere. It's a good way to test imposters that think prompting an LLM makes you a programmer. They secretly paste the error into chatGPT and go off in the wrong direction...
Absolutely the AI. At that point in the future I'm presuming that if something breaks it's because an external API or whatever dependency broke, not because the AI code has an inherent bug.
But if it does it could still fix it.
And you won't have to tell it anything, alerts will be sent if a test fails and it will fix it directly.
I didn't say Messenger wasn't successful. I said that Meta rewrote Messenger twice and did not meet their internal goals both times.
Even today you can see Messenger completely break down if you have to sync for more than ~30 seconds. JS console fills up with errors about your broken state as you start to lose messages. Local storage is out of sync, session state breaks, and it's all right there in the console. It's been like this for years on WebKit. React just has too many bugs for a complex behemoth like Messenger.
React Native is just as bad and basically everyone I know in real life can corroborate lost messages, broken group chats, horrible photo experiences, and memory leaks!
You can just look at Messenger vs WhatsApp and the difference is just night and day in the user experience. The e2ee backends are the same (according to my pcaps, I could be lying), it's purely the front end that changes - and you won't find anyone that says Messenger is better than WhatsApp.
Yeah I don't know where the parent comment got this from. Every few weeks I seem to see these low effort posts that basically boil down to "javascript bad", but gets a lot of upvotes. And when you read into it, you see the author often has a poor grasp of js, or its ecosystem, and has set up some unholy abstraction, assuming that's how everyone does it.
> Maybe that's because they're an ex-JS programmer who wants to use the exact same interface they'd use in JS with no compromise, or maybe it's just because they think it's cool
That sounds a little reductive and gate-keepy. Maybe an advanced type system allowing for complex types to be expressed easily actually allows you to write simpler, more effective code.
I've been researching 'local first' solutions like electric recently and tried out powersync, triplit and instant for now. All three of these solve for both reading and writing to databases, with offline support.
Wondering if you have plans to support writes too.
There's a variety of valid patterns for writes & we don't want to be prescriptive about how you do them. We aim instead to help you easily use Electric with your preferred/required write pattern.
It's possible we'll write our own write library but it's equally likely we'll continue to find it better to partner with other projects building excellent libraries (like we are with https://livestore.dev/).
This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site
> This reads like the perspective of someone who really doesn't understand nor appreciate the real world complexity and technical trade offs involved in building something like twitter or a shopping site
You're describing websites simple enough that they're often used in beginner tutorials for web development.
Online shopping and text-based social networking absolutely and emphatically do not require a spaghetti soup of JavaScript frameworks. These were relatively simple websites to build for decades before web frameworks ever came along.
Compilers are a common project for university CS students. That doesn't mean GCC is overly complicated.
There's a huge difference between making a simple prototype of a concept and making an actual production app that fulfills a myriad of requirements that help you run a successful business.
Agreed, but not even a battle-hardened production compiler requires a particle accelerator or an optical fibre cable to the Webb space telescope. Similarly, a shopping site or text-based social media does not require a soup of web frameworks. It just doesn't - it's not a solution commensurate with the scale of the problem. Complexity is expense, and this doesn't remove complexity, it introduces it, reams of it, and totally needlessly.
No one has ever sat in front of a shopping site and thought - 'you know what this needs? A dozen extra mb of JavaScript that introduce no actual new customer-facing features, but that put a noticeable delay in every interaction, break the user's scrollbars and screen readers, and dramatically complicate maintenance.'
What a beautiful Straw man. What are these social media sites with more than one framework?
> ever sat in front of a shopping site and thought
But do you know what actually think? That they want to have products filtering, they want to have more products loaded with a simple button click, they want to add reviews and comments, they want to see product photos (or maybe even 3D models) - all fast without unnecessary page reloads. It's your problem you can't build it without breaking user experience.
All of the things you list can be achieved with minimal or no JavaScript, and many are completely trivial (filtering? adding reviews and comments?).
In general, if a prospective employee told me they needed React to implement website comments, I would not walk away with a very high opinion of that dev's abilities.
They cannot be achieved without JavaScript and still be fast (good luck having product filtering with full-page reloads, your users will flee) - that was the whole point. And I didn't say you have to use React specifically. But without framework you in the end just create a custom one (as was said multiple times by other commenters).
As I said, minimal to no JS. Something like HTMX or Turbo* is more than sufficient to solve this fictitious full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons). Ask the average person whether websites have gotten better or worse since 2014. That's their opinion of SPAs.
> But without framework you in the end just create a custom one
Only if you've only ever written React-style webpages, and can't imagine any other way a website may work. Which, needless to say, would reflect a very limited experience of the web.
* Or just a plain XMLHttpRequest call? Dynamic loading is exceedingly simple, and certainly doesn't require a convoluted web framework.
But we're not talking about SPAs, we're talking about e-commerce websites.
> full page reload aversion that users supposedly have (they don't, they have much more of an aversion to endless spinners and websites that break their browser's scrollbars and back buttons)
I'm simply saying user wants performant websites. You're basically saying the same. Full-page reloads are, ceteris paribus, always slower than some JSON payload. And when you're saying to use HTMX, I then don't understand what you mean by "minimal to no JS".
> Only if you've only ever written React-style webpages
Again, I'm not saying anything about using React specifically.
ceteris is rarely paribus: JSON-based APIs have to make a choice between being general purpose, in which case a web app written against them may end up chatty with multiple requests per page, or they end up application specific, in which case they can be churney and a bad general purpose API.
Also, producing JSON often involves reflection and can be more CPU intensive than straight templating (w/ fixed properly lookups) depending on your technology. Finally, the size delta between JSON and hypermedia is lower than most people think, particularly with compression:
As I said, using HTMX isn't "minimal to no JS". I agree that HTMX can be fast - but that's not what we're talking about. Even in the video of converting a React app to HTMX you linked the presenter literally says - "no JavaScript, just HTMX" - but HTMX is written in guess what? Very dishonest.
i think it's reasonable to call htmx "minimal JS" in that it is relatively small, dependency free, can be used without a typical javascript build chain (npm, etc.) and frees the end user of writing javascript in many cases
the speaker is referring to them not needing to write javascript for a specific feature, which is true, but they do use scripting for some aspects of the application, which is perfectly acceptable in hypermedia-driven applications:
This seems like an exceedingly mean-spirited and unconstructive type of response to have to people who have been giving up their time trying to explain a different point of view to you. I would also gently point out the HN guidelines at this point.
I note you haven't responded to my more substantive reply here,[0] so I am unsure you saw it. I would encourage you to read it with less of a zero-sum 'I-win-you-lose' mentality. I won't be engaging with you further though.
> Full-page reloads are, ceteris paribus, always slower than some JSON payload
That must explain why websites are so fast and responsive these days! /s
If you're wedded to the idea of dynamic reloads, which - imho - you ought not be, HTMX or Turbo are ways of achieving that without needing to write any JS. HTMX is designed to complete HTML as a hypermedia language, which it does using JS, but it itself does not require any additional JS to use. I'm sure the authors would dearly love it if HTMX's ideas were taken directly into HTML5, and they could scrap the JS library altogether. Its use of JS is an implementation detail borne of necessity.
If you're coming from SPAs and can't imagine websites working any other way, I highly recommend reading something like Hypermedia Systems (https://hypermedia.systems/). Come with an open mind, let it be your gateway drug. HTMX builds on a very old tradition of hypermedia, all the way back to Computer Lib/Dream Machines, through systems like HyperCard, to the actual, original definition of RESTfulness (that modern Ajax SPAs generally do not meet). It draws deep from the hacker ethos (you know, that thing that this website is about!).
Personally, I don't even think HTMX is all that necessary. What I feel like you're missing is that the overwhelming majority of websites are technically very simple, and their value to their users is in their contents, not in their stack. Did you notice the full page reload when you hit Reply on your comment, here on HN? Were you terribly put out by it? Would HN be an improved website were it full of spinners and Ajax? I would respectfully suggest it would not. It delivers amazing value running as a Lisp program on a machine under someone's desk.
> This seems like an exceedingly mean-spirited and unconstructive
It's not, it's precise.
Sorry you wasted time writing all this, because I don't care about hypermedia systems - it's not that it's bad technology, I simply don't want to write yet another awful templating language. But that's just an aside, because once again you're talking about something else. But okay, let's switch to debating HTMX. My point then still stands: you simply need JavaScript. Now instead of this useless arguing, go find/build some big e-commerce website with this hypermedia stuff (or truly with no JavaScript) and then we'll see.
> "Well, Steve… I think it’s more like we both had this rich neighbour named Xerox and I broke into his house to steal the TV set and found out that you had already stolen it."
reply