41–50 of 91 posts
I've said it before and I'll say it again. The main reason we need bloated convoluted web frameworks with giant learning curves and a jillion gotcha's is because businesses want desktop-like GUI's and HTML/DOM/CSS/JS is ill-suited to emulate such, and perhaps stuck that way because fixing it will likely break backward compatibility. Web is either missing or has screwed up too many common and expected GUI idioms: http…
Earlier quoted context omitted.
You would think that, but this seven line NPM package has 68M downloads a week - https://www.npmjs.com/package/isarray
NPM statistics are easily gamed https://dev.to/andyrichardsonn/how-i-exploited-npm-downloads... I don't doubt there are a lot of insignificant packages being used, again especially by beginners, I just don't buy it's to that scale
There's also the classic left-pad debacle - https://github.com/left-pad/left-pad/issues/4
[1] - https://github.com/motdotla/dotenv/blob/master/package-lock....
[2] - https://github.com/npm/cli/blob/latest/package-lock.json
Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…
Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…
A potential acquisition came our way that seemed to be exactly what we were looking for. Customer traction and revenues, the features exactly what we were looking to overhaul. There was very high internal interest in acquiring the technology and the company.
The need for this set of features was so high and the internal development estimated to be so costly (in developer time and delays in other projects) we were willing to overlook that this app was not built on our primary stack and only a few of our developers were familiar with. The language choice made by the company didn’t cool our appetite. However, technological choices made us pass on the acquisition.
They didn’t use a framework.
This means that our developers would have a very long learning curve. We also saw a lot of code that did what a framework would have taken care off and this means that we would have had to learn, maintain and expand that code instead of working on the revenue generating features.
We found close coupling of code all over the place. This meant we couldn’t quickly extend and modify the features as we wanted without first paying back the technical debt accumulated by the developers.
It wouldn’t have mattered which framework they would have chosen as most of them have good documentation and force some sort of standard development practices. However, we couldn’t take a chance that all the behind the scenes stuff would need a rewrite if we wanted to expand and scale the platform. We passed.
Earlier quoted context omitted.
Yea. I didn’t understand the criteria given: long running sessions and authenticated content. Why do those necessitate a SPA?!
Long running sessions seems pretty straightforward. The cost of an SPA is heavily front-loaded, so the longer you have the app open, the more that cost can be spread. Authenticated content is likely for a mix of reasons. It can't be indexed, so doesn't need to optimize for SEO. Users that log in are higher intention, so they're less likely to bounce if the page loads slowly. It's definitely more complex than just the…
Similarly, page speed should matter regardless and tbh what I've seen in the wild people restricting themselves to serverside renders have far superior load times due to cachability and lightweight page designs.
I think the article hits the nail on the head, were opting for devex over UX. I don't think it's really a problem, I use react in a large org (one of the spa examples funnily enough) and it does enable workflows and org structures that would not work without the site being a spa.
Whether that trade off is worth it I'm not sure. While it enables org structures that work for us Im not convinced the resulting empire building and feature spam was worth it for users.
Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…
The difference is important though. With libraries, you have to connect them to each other. With a framework you don't. But with a framework, if the predefined connection isn't working for your case, you spend way more time to change it. That is, if the framework is good.
Until you’ve hit product market fit, you shouldn’t build anything other than what is unique to your product. If you are spending time on authentication or forms or worker queue architecture, you’re wasting time. Frameworks and plug-ins exist to allow this to be all plug and play, so you can focus on building something potentially useful enough for people to pay for it. Product market fit is generally achieved when yo…
You don't need to try hard to convince yourself that there's no causal link between the two (eg. fast food sells well, but isn't good food, high-end goods usually don't sell well because buyers aren't willing to pay extra for marginal improvements).
And so does your argument. The post OP was the reaction to was talking about quality and how misguided the whole field is in terms of using existing, concrete pieces of software s.a. React. And that is, unfortunately, the reality. Web is awful, especially because of how it's been developed, especially due to things like React. But it also sells well. But this wasn't the point.
> Pay people to fix the tech/replace the janky or slow stuff/automate manual things.
Sometimes? When circumstances allow that? This is not a given. And with the way Web is, and the way it's going, it's only getting worse. HTML is a bloated standard. JavaScript is an idiotic language. The GUI toolkit that browser offer is a combo of bloat and idiocy. The whole idea of making "single page applications" is idiotic because Web was never meant for that. It was meant to be an interface to what today we'd call a distributed document database. But is this going to change because individual programmers or individual companies recognize the problem? Are they going to fix / automate it? -- well, there's no way a single company, not even a mega international corporation at this point, which could do that.
The argument the OP was the counter-argument to was saying that Web needs a different foundation and that no modern frameworks are any good. It didn't go as far (as I did) in claiming that the whole stack is garbage. Still, you are missing the point when you are making an abstract argument about using frameworks. The point was: "we have garbage frameworks in Web, and things are getting worse, let's take action to do things differently".
In the end it is a problem of multiple, near equivalent, solutions with no sharp-enough success criteria. This makes the traditional approach of using "the right tool for the right job" lose its edge.
Why dont we have good enough filters to select technologies and designs? Ultimately it must be that people's expectations are low. Why is it so? One reason might be because the predominant value proposition is still dominated by the novelty introduced by global (mobile) connectivity. That is exemplified by minimalistic interfaces: the value is in the connectivity, not the information post-processing.
Once people get used to that basic fact they will start being more demanding and that might give rise to more differentiated criteria. In a sense right now there is much latent potential with existing tech that does not yet express fully because the conditions are not conducive.
It's fun to look back on the success of SPAs from the perspective of someone who learned to build websites pre-jQuery. jQuery allows for websites to be interactive with minimal latency, but it's pretty low level so it leads to a lot of common problems. Like locking the main thread, undisciplined architectures, and a ton of issues with back/forward navigation. SPA frameworks are developed to solve jQuery problems, but…
For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be. But, it failed due to Adobe's bad market strategy. But Flash, too, was a band-aid on top of broken tech. It was obvious that Web was not meant for what Flash was trying to do, Flash was just better at overcoming the problems than HTML+JavaScript is.
Web frameworks aren't here to add value, they are here to patch bad foundations. To deal with "defects" (or, rather the consequences of unintended use) of HTML and JavaScript. So, they will inevitably be bad, because they are trying to fix the problem they didn't create and that is beyond their power to fix. And as long as Web stays the application platform of choice, Web frameworks will cause a lot of resentment amongst their users.