421–430 of 467 posts
Earlier quoted context omitted.
Can you give an example of a problem that would take significantly longer solving with React than with DOM manipulation?
https://bugs.chromium.org/p/chromium/issues/detail?id=604033
I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…
For the most part I think the reason so many web devs put up with the “all-react” (and similar) development experience is basically cargo culting. If you admit you don’t like it, chances are there’s at least one front-end hipster around who will mock you as outdated, and that’s enough to silence most. For the hipsters, the problems of SPAs are hard, and engineers like hacking on hard problems. Also the fact that the…
Java appeared on the market. It's a big change. It really brought out the goodness in Object Oriented paradigm. It made software engineering more rigorous. Most enterprise software made the switch to Java. They need the reusability of Java. Microsoft came out with C# to counter the rise of Java.
We have the same situation here with JavaScript and TypeScript/React. React brings structure to the messy world of JavaScript. But it also incurs the cost of traditional enterprise software engineering on the web development. I expect performant libraries to continue in plain JavaScript. Reusable web components will move to TypeScript/React. It's exciting to have better technologies to use for our projects. I don't think one will diminish the other. They'll both co-exist.
I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…
Does wondering that help you come to terms with the idea that you're creating things that range between "not the best user experience" to "thoroughly unpleasant to use"?
Personally I have been building websites (anything between sysadmin to backend and frontend) for 20 years, and my experience of the JS ecosystem is that it's utterly unpleasant to work with and in no-way better than other web technologies, but then maybe that's a delusion brought on by not eating enough.
> It outweighs all the end-user-facing cons by a lot
Well, I got so sick of crappy JS "websites" spinning my CPU fans that I installed the NoScript plugin, and now the web is a far nicer place to be. My browser is more stable and faster, uses less memory, and doesn't hog my CPU as much.
Earlier quoted context omitted.
What a great anecdote. It aligns with my big worry here: we are raising a cohort of front-end developers who don't know how to use plain HTML and forms!
I want to hear a war story of someone starting from a React bug report, reducing it to pure JS, fighting through the Chrome build process, isolating the v8 JIT bug, producing a patch, and going on to a successful compiler career.
... but I'd also submitted the JS fragment to Chrome, of course. They ended up flagging it as a high security bug and, not surprisingly, beat me to a fix.
So I never got as far as making a patch, which I guess is why I still don't have a successful compiler career.
I did get a $1k security bounty from Google, though, so that was cool.
Let me see if I can google the bug report. This is it: https://bugs.chromium.org/p/chromium/issues/detail?id=282736
Ah, report reminds me that at that point, the app was all knockout.js. We ported it to a knockout/React hybrid later.
I think deep down people writing SPAs really just Flash apps or Applets would come back. They want to ignore everything about the web except the ability to deliver content over a network. I'd go so far as to say they hate the web as a concept. Most problems stem from that disdain for the web. Many of those problems are then exacerbated by "opinionated" frameworks being en vogue. None of them are helped by the shit pl…
No reason to be bitter about XML having failed on the web; some important vocabularies, like SVG and MathML, have been incorporated into HTML, and some other parts of the XHTML effort, like XForms, really didn't work out. The web wasn't created on XML but on HTML which is an SGML not XML vocabulary, so there's no point in appealing to a glorious past that never existed (and yes, I actually developed -based sites in t…
A website could simultaneously be a site for a browser and an API for native or web apps by serving the exact same documents to everyone. The server side could focus on data and the client would be responsible for the display or processing.
It did the things modern JavaScript monstrosities do but natively in the browser. XForms even proposed to handle a lot of the stupid validation and state management that requires megabytes of JavaScript to handle today.
Tons of resources are wasted every second parsing and running JavaScript to do the same thing browsers can do natively.
Earlier quoted context omitted.
>“wow, I didn’t realize you could actually do anything useful with just plain JavaScript in the browser. I thought it was like... assembly or something.” Wow. These two sentences completely capture modern day Web Development, Javascript as assembly. >I think there’s a lot of that in front end world today. In modern Web development, ( and in possibly all area of software development ), instead of making things simpler…
FWIW, the first conference where I heard speakers talk about learning JavaScript first before leaning on a framework, was jQuery 2008. Frameworks are not inherently premature abstractions, but can be used that way.
Earlier quoted context omitted.
It literally doesn't. You can build a fully normal HTML form in react. The only reason to do any of it yourself is because you need something regular forms can't provide and even then you can still use as little or as much custom parts yourself.
It literally does, unless you have the form POST or GET to an API directly + a redirect from the API. You have to override the submit functionality which is built-in by the browser. You have to maintain state of what the user inputs, which the browser handles for you. You have to reset inputs, which the browser handles for you (button type=reset). And a ton of people forget to actually validate on the server because…
I empathize with the author but client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. It's true that they are largely more complex than O.G.…
> client-side technologies like React have a pretty clear advantage that explains why they're popular: for the people that are tasked to make websites (i.e. us, HN readers), they're easier to work with and they save us time. It outweighs all the end-user-facing cons by a lot, because companies need us, and our salaries are expensive. As a developer that started off with client applications going on two decades, this…