Part of it I think is that we're still in a period of growing-pains. The web is transitioning from a document platform to an app platform, and until it fully catches up to that mandate, we have to bridge the gap with layers upon layers of frameworks. I think we're entering the downslope of that process, but it isn't finished.
That said, I do wonder why there isn't so much as a proposal for native HTML templating (the <template> tag doesn't count). This has been industry-standard practice for 5 years now and would benefit immensely from a native implementation. It seems like it's well past time to get that ball rolling.
There were XHTML with XLSTs. It was widely rejected, most people didn't even see the point.
function myComponent(props) {
return `
<div>
${props.name}
</div>
`
}
...
document.body.innerHTML = myComponent({ name: "Bob" });
I'm of the opinion that sticking with React when Lithtml exists is just fear of writing vanilla classes.
About ease of use in programs, if you were using XSLT, you had to output XML which then had to be put through an XSLT processor. If you are outputting XML to another program or database or whatever anyway, that would be possible. But if you are only outputting XML so it can be transformed to XHTML by an XSLT processor, for which you had to write something in XSLT, you could just spare all the hassle and directly output HTML anyway.
FF and IE had XSLT processors in 2006 and I suppose they still do (although could be wrong about the still do), there were at any rate XSLT processors in browsers back til the early years of this century, although hey, not in every browser. Opera was definitely dead set against ever implementing one.
You did not have to output XML, you could output XML, text, or html, depending on the output format the processor would handle how your output format should work (as it was a declarative language) thus if you output html the processor would handle turning XML like br elements into html br elements, not that that is any great thing, but it is a fact you could output other things than XML
The saddest part is that the shortcoming that the initial framework tries to solve is, most of the times, insignificant compared to the complexity that the framework is adding.
The truth is that we are all just "play-testers". We keep mocking new browser features, put them in the real world, test them, and then browsers can easily decide what features really provide value and should be implemented.
The real problem is that this is a never-ending cycle. We started to like this creation of new features so much that we never really focus on what we have and try to make the most out of it. We keep adding bloat to fix imaginary problems, when we already have all the tools that we need. I am not referring to new functionality, such as Web Payments or OffscreenCanvas, but to frameworks that try to mimic what the browsers are doing and just do it in a slightly better way.
That's where I disagree. I think the web was fundamentally unsuited to the "application" use-case and has been making its way in that direction for 5-10 years now. I think once we reach that destination, the churn will drop off dramatically. The platform will become enough, for the most part, and we may shrug off the need for comprehensive "frameworks" altogether in favor of simple libraries, like most other language ecosystems.
It clearly hasn't though, as demonstrated by this very OP ;)
Everything people are complaining about here, in addition to the problem being addressed by Concurrency Mode, are things that writers of native apps don't have to fight with:
- Lack of concurrency
- Complex, layered build systems
- Several layers of syntax transformation as an industry baseline
- Lack of a consistent story for modules
- Overall jank-proneness
- Platform bloat like that in Electron
But then why re-solve all these problems if you can just build a native app? Because native platforms over the decades have repeatedly tried and failed to a) be truly cross-platform and b) have truly flexible, well-documented layout systems. The web gives us those. We just have to go back in and add the things it lacks.
When all of these problems have been solved and a new framework is still coming out every week, then we can talk about frivolous effort being expended. Until then these are real, worthwhile problems being worked on.
Really? I think its pretty obvious that the complexity of websites (or really, web apps) is increasing every day. For the most part, web sites are not just static content any more. More devices, more users, more features for even the most basic types of sites lead to increased complexity of building something that meets those demands.
>We have build thousands of front-end frameworks and all of them try to solve the same issues that should have been solved by the browsers themselves a long time ago.
Sure, but they haven't been solved so do we just say to users "Nope, sorry, Chrome never implemented this so it's not possible"?
I can't help but think that this type of argument is based on an idealized version of the web where every website can be reduced a personal blog like the "good old days". The web has evolved, and so have users and what they expect from it.
I mean sure, if you are literally creating a personal blog - don't use React. But otherwise, I don't really get this POV.
I would instead argue that websites today tend to have far more features and functionality than their counterparts of 15 years ago.
People are doing things with websites they never did before. Office applictions, games, native-like UIs, real-time messaging, analytics and dashboarding, programming.
Good or bad, websites today have different interactions, behaviors, and development costs than 10 years ago. It sneaks up on you but if you see screenshots or use an old website you will immediately notice the difference.
> but while doing so we are creating hundreds of problems that never existed before.
Such is innovation.
> Tens of years of "evolution" and we just keep making everything slower and more complex for no reason, apart from being bored or wanting to be trendy.
Try making a website good enough that people will actually pay for it.
You may find your opinion changes.
Don't get me wrong, I actually used and love(d) React, but it feels like in the majority of cases the library is misued and people just create normal sites (that could have existed 15 years ago, but a loat bloatier) instead of creating the apps you were referring to.
I love HN as well, but this is a niche site for niche purpose.
So React shouldn't get new, powerful features because some people might (ab)use them for simple websites that don't need it? That's bollocks and I'm sure you can see that. If you are generally annoyed about this, go rant on Twitter - no reason to do it here.
Either
A) You are ignoring that modern web apps are very complex w/ dashboards and complex flows that can't be modelled with a simple URL scheme.
B) You are saying "Actually I don't have a problem with React, my issue is with people using it everywhere for simple things". Which is silly because
1. That's not relevant to the article. Go talk about that issue somewhere else.
2. This feature is clearly only meant for more complex React applications, so you don't need to worry about it "over-complicating" simple React apps.
3. This feature would be just as hard to implement in a traditional web-app. JQuery based web-apps aren't simple, they are imperative hellholes.
4. React makes "simple" web-apps simpler. Even for websites that don't need React, using it can make the dev process easier.
...the problem here is developers consistently try and shape the round hole to fit their square peg. Web apps are not the appropriate product for this design problem - the solutions are desktop applications.
It's very unfortunate that the ecosystem is so hostile to traditional desktop apps and solutions, but that gets back to OP's point - these frameworks are solving problems we've manufactured.
So if by ecosystem you mean money, yeah, but I only make web apps nowadays unless someone comes with a big bucket of money for the desktop app beforehand - which I never see happening for some reason.
But if your product is not just about information retrieval or collection, rather based on things like complex user interaction, persistent local data storage, integration with devices on the users machine or complex interactions that need to override mouse/keystroke behavior... then I'd question whether or not it should be a webapp.
Discord is a really good example of this to me. They have a web client, sure, but the app itself makes sense on the desktop. There's nothing wrong with using web technologies to build the app, but the mental model of how browsers send/receive data from a server somewhere seems fundamentally incompatible with how such an app should work.
What I meant by hostile is that publishing apps sucks for a lot of reasons, from lack of user demand to platform issues, poor sandboxing, distribution issues, etc. It's a shame, because that's how we wind up with such crazy complexity in web apps, when we could just stick to native OS APIs and call it a day.
So the solution would be to exclusively some "web technologies" (HTTPS, WS) to deliver content and messages to the application? I guess by creating a bunch of clients, managing request states and working around the intricacies involved there (or in the libraries you used).
So after that's done then lets add some kind of auto-updating mechanism. After a while you get it working, awesome. Lets hope users constantly keep it updated! Spoiler: they will not.
And then, when you think you're all finished, someone from product comes in and says "hey we want to A/B test this feature on these specific clients, when it's a Tuesday and they are connecting from India. Oh and these requirements will change every 24 hours". Great.
"If only there was some set of technologies that made all of these problems convenient and effective", you think to yourself as you check Slack.
Regardless of where the problem came from, we still have to solve it.
Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network).
They're worried about shaving kilobytes here and there - concurrent mode helps to dynamically render/load items in an order that makes sense for people on slow networks where it wouldn't even matter for people on fast networks.
Mainly because I've only ever worked in comparatively small companies (fewer than 30 engineers) and every step of the way React has uncannily been solving the problems I've been facing (in fact, my decision to try React came at the end of months of trying alternative solutions to view layers until deciding to bite the bullet and try that weird JSX thing).
For me it comes down to a simple question: Is what you're doing sufficiently app-y to justify an up front framework cost of around 70kb (React + your ecosystem libraries of choice)?
If the answer is "no", there's a follow-up question of "is that likely to change within a year?"
It's relatively frustrating that React is one of the largest React-like frameworks (e.g. compared to Preact and Vue), but they've mostly been focused on different problems for the last few years. I'd expect React to get smaller and faster once there's less of a focus on fundamentally changing and simplifying the way we approach certain types of problems (e.g. the ones that Suspense solves).
Er this ended up being longer than expected, sorry about that!
Namely, developing something once and having it work ideally everywhere on the planet (slow network vs. fast network).
Providing users with the best experience possible in their browser regardless of the limitations of their computer and network is a problem every front end developer should be trying to solve.
Very few of us work at the scale of Facebook, but that particular problem isn't a scaling issue.
Suggesting we can ignore the problem of a bad experience for users on slow networks just because we operate at a smaller scale is plain wrong, and anyone making web tech with that attitude is failing the people who have to use the code they write.
You mean like being able to have juniors up and running and writing legible and maintainable (if at the cost of being opinionated) code?
Complexity of building dynamic documents is actually going down. If you are to build a typical web site from 200x using modern browsers, you wont need jquery or anything like that. Networking, security - everything became 100 times easier and faster.
But if you want to build a desktop application using DOM as a rendering layer, then it is a different story.
If I can't just include a file things are going to get more complex.
State machines are a method to solve a problem that could be expressed in other ways to make it fit the language better.
But the tooling and npm packages are all optional. You can import React from a CDN and use stuff like htm [1] or domz [2] instead of a JSX compilation step.
Or you can use Vue instead of React (their tutorial starts by using Vue via CDN).
If you're able to only support 95% of the browsers, you can use most modern ES6 features, including ES Modules and async/await.
If you still need the tooling, there are options like Parcel [3] or Poi.js [4] that require zero configuration. You don't really need the complexity of Webpack.
--
[1] https://www.npmjs.com/package/htm
[2] https://www.npmjs.com/package/domz
When I tried to include other packages they were only available through npm (some had cdn versions but most did not). You don't get access to the entire ecosystem without the tooling.
If I want to implement a rich text editor in my website, it will be as easy as 'npm install ...' and an import statement in the relevant file.
Is there an advantage to make a state machine to solve this?
At the extremes, you either end up with thousands of lines of spaghetti code or an over-engineered mess serving up a html page with a single image on it.
Web frameworks are just a tool that needs applied to the right job.
I miss the old internet some days.
Yeah, web is not only about documents these days (how it was originally intended) but it is also about running and hosting real-time applications.
But I hear you, people indeed use wrong technology to solve their problems. I agree that there is no need to use any React and Angular to display a document.
Oof I do not miss that! You are 100% correct that tool selection is a major decision in how well a product, app, or website responds. Perhaps we need more of that then?
I found it extremely easy to jump back into and high productive. I feel like the next generation will rediscover the simple nature of include a file.
I know all those frameworks exist to solve a specific problem, but while doing so we are creating hundreds of problems that never existed before.