201–210 of 292 posts
Using React with an API back-end is only 1 of many choices. There's tools like Hotwire[0] and htmx[1] (both are back-end agnostic) that will let you create good old boring web apps with any back-end language where you don't need to write a ton of JS. You can sprinkle in front-end quality of life enhancements as needed to make nice feeling web apps with reasonably minimal complexity. [0]: https://hotwired.dev/ [1]: ht…
Background: Primarily a backend developer. I had used java swing and struts long ago. Played around with vanilla react and next.js (through vercel). I had a look at the various samples provided by vercel. But I struggle with the syntax and hence finding it very difficult to write something from scratch. How do you guys write a new application in next.js?. Do you hand code it?. Also, is CSM a must ? Most of the examples in vercel are simple applications. How does one design a slightly advanced user interface from scratch?
Earlier quoted context omitted.
Great questions! >Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does. I think under the hood, the people who actually write the DOM apis would know ho…
I appreciate the ambition to reduce the complexity and tooling overheads. Unfortunately, I doubt we could define a sufficiently general API for the kind of functionality you’re talking about. There is too much variety in the applications we now build with web technologies. Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a sub…
We will always need JS frameworks. It's where some of our best ideas have come from. I just think it's time that some of the most successful ideas make it into the standards.
I call this the "path to enlightenment." You have discovered that the most popular toolchain is overkill for 95% of the things its used for. The problem is that's true literally across the board. You move to the backend and you have to deal with people who fell in love with microservices and weird databases that they didn't need. You move to ops and you have to deal with k8s when a single container would do. If you t…
>Why does this happen? I wrote about a hypothesis here: https://medium.com/@scott.stevenson/how-to-finally-make-some... Most of us are scared by the ambiguity of actual creative work, so unless we are under the threat of deadline, we seek out "structured games" to play so that we can put off the anxiety of freeform work. These games are: (1) Tool Game: Researching and setting up tools (2) Learning Game: Books, podcas…
A couple people have asked what complexities I’m referring to and mainly what I mean is just how much bloat goes into making anything, and at a higher level the general course of action seems to be to just keep adding to the system until you get what you want out of it instead of trying to fix or improve underlying problems with the web. I know we can’t just pause the internet while everyone comes to a consensus on h…
Not really related to the above but I learned React when I started my current job and I hated and did not understand it when I first started https://cmdcolin.github.io/posts/2020-07-04. Now it has changed my thinking entirely, and I think react is very powerful. Not without awkwardness and whatnot, but it's better than spaghetti jQuery era
Earlier quoted context omitted.
Great questions! >Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does. I think under the hood, the people who actually write the DOM apis would know ho…
I appreciate the ambition to reduce the complexity and tooling overheads. Unfortunately, I doubt we could define a sufficiently general API for the kind of functionality you’re talking about. There is too much variety in the applications we now build with web technologies. Maybe we could do it for simple CRUD application UIs that are built using lightly styled forms and tables. To be fair, that might already be a sub…
That would be a very admirable and IMO sufficient goal. Being able to do "modern forms" with "native" capabilities seems fairly reasonable.
The word processor, fps, data heavy requirements are IMO being taken care of by WebAssembly, which is a more appropriate technology for those sorts of things than the DOM is anyway.
Can I ask what exactly you're tired of in the frontend world? Is it constantly having to relearn new ways of doing the same thing, without any tangible benefit? If so, yeah, that really sucks, but I guess that's the unavoidable growing pains of a rapidly-expanding industry with different companies all inventing their own wheels. Have you ever thought about working in a slower-pace field (whether it's a different vert…
Earlier quoted context omitted.
Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? Would you choose a React-like model, or maybe something more Svelte-like? Or something different from either of those two that I'm not aware of? And the follow up question, which is pointed, is: if your proposed solution would look similar to current JS solution X, why would it be better than X? Is the go…
Great questions! >Which of the current JS frontend framework paradigms do you think should be standardised and shipped in browsers? The basic concept of "binding" data to a DOM element and having the DOM element update when you update the data instead of having to manually update it. That's something every modern frontend framework does. I think under the hood, the people who actually write the DOM apis would know ho…
> they didn't have to do stuff like chase down NPM problems or debug Webpack.
The ship has well and truly sailed on that one. Building a reactivity framework into the browser isn't going to solve dependency management or transpiling.
But I wonder if ESM is going to change this game a bit. Now that dependencies are statically analysable in the page source, a CloudFlare or similar could sit between the "source" and the browser and do intelligent caching and bundling transparently.
React tooling is only getting easier, esp. considering anyone coming from the age of Webpack. The recent wave of framework innovation has been about DX by bundling things together into one cohesive experience. Also, nobody is required to keep up with the bleeding edge unless you're a framework author trying to breakout. If you don't like the marginal benefits provided by some performance story in React, then don't do…
That this realistic comment is showing downvotes is worrisome about the general aptitude of HN wrt front-end dev. Good ol' Gell Mann Amnesia...