Interesting. I want to know for anyone: do you think frameworks are boilerplate and vice versa?
The case for frameworks
71–80 of 91 posts
Re: The case for frameworks
#72Until 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…
Yes yes yes. Great comment, just here to say amen.
Re: The case for frameworks
#73I am deeply sympathetic to Alex Russell's position on frameworks, but the reality is that he's never going to move the needle by badgering developers to prioritize performance over developer experience. The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience. As someone who wants to advocate for standards instead of…
> The ecosystem won't move on from React to more performant and standards-based alternatives until those alternatives provide a competitive developer experience.
Meanwhile frameworks and libs (even those who originally were very supportive of the idea of web components) have moved past WCs and are exploring approaches that WCs will never ever be able to provide such as granular reactivity, seamless frontend-backend integration, or even eschewing components as a rendering primitive entirely.
> React is going to keep winning until the standards furnish comparable ergonomics.
In all honesty, Scoped CSS + Nested CSS proposals coupled with https://open-ui.org would've solved 99% of what web components are trying to be.
Meanwhile we're about 20 years away from WCs as a finished thing: https://w3c.github.io/webcomponents-cg/2022.html
Re: The case for frameworks
#74The debate seems only to get even more convoluted with the browser slowly opening up to things beyond javascript and interactions with servers getting richer too (eg htmx, websockets) 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 filter…
Not sure I understand how htmx fits into that. It is in essence a JavaScript project: one that lets you do JavaScript things from html. And to do that it's written in JavaScript. I think it's very wrong to think of it as some kind of real aspect of the html.
Re: The case for frameworks
#75Until 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…
I think there's a problem of what we actually mean when we call something a "framework." Is an ORM a "framework" for interfacing with persistent data stores (usually SQL databases)? Common parlance says it is--and I tend to agree--but, it's also "just" a library to get in between your app and your data, which feels different than, say, a web framework that dictates how your whole project is structured, what auth methods are "supported", what interfaces your handler code is allowed to implement, etc.
But, I also I think your sentiment is somewhere between a generally wise piece of advice/wisdom and a vacuously true statement of fact. The latter because of course you should not reinvent the wheel if there's a perfectly fine wheel already out there.
Frankly, a lot of these things we call frameworks are actually fairly low quality. And I say that with the humility of knowing I couldn't do any better, but that doesn't make it less true. One of my "favorites" to shit on is the Java ecosystem. In particular, JDBC/Hibernate for ORM/SQL stuff, and JacksonXML for (de)serialization. Both are absolutely awful for various reasons, but my go-to example is that JDBC literally doesn't have an API for getting a nullable integer column value out of a ResultSet; instead, you have to get a non-nullable int primitive which will be `0` if the database value was `NULL`, THEN you have to call a second method to ask "Was the previously returned value from this ResultSet actually a NULL instead of whatever I got?". This manifests in Hibernate as requiring an easy-to-forget-or-misuse annotation on your DTO class.
My point is that some of these frameworks are a total nightmare for reliability and robustness, and I'm not convinced that just reflexively opting in to all of the "de facto" frameworks at the beginning of a software project is always the right move.
Re: The case for frameworks
#76Earlier quoted context omitted.
Let's look at it from a different perspective. Web wasn't meant to be an application platform. It accidentally became one, due to events that had nothing to do with technological merit, but were social in nature. 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 t…
> For instance, technologically, Flash is a much better platform for applications than HTML+JavaScript combo will ever be Flash was very nice for some use-cases, but it leaked memory. It is not a good fit for long-running apps (probably why Flex/Adobe Air failed, too).
IIRC it also wasn't good for screen readers and accessibility.
Re: The case for frameworks
#77I'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…
I've been saying a similar thing for years too. Anyone want to team up to make attempt #27 at this problem?
Excellent, I'm not alone in feeling something is missing from the industry.
I'm in the early stages of a proof-of-concept using MS-WinForms to write a GUI browser. Nothing special about WinForms, I'm just somewhat more familiar it and C#, and there's a lot of web help for MS tooling. The demo wouldn't be feature rich; just enough to get a feel for possibilities.
But in parallel, we can kick around what the "ideal" markup language could look like here:
https://www.reddit.com/r/CRUDology/comments/112ly2i/gui_mark...
Re: The case for frameworks
#78There's certainly value in frameworks, but like with so many things we build today, most of them are build for a scale that most people don't need. I'm sure React is great, Angular as well, and VueJS, but they have grown to be all encompassing, so a developer is never stuck and need to rewrite everything. Many frameworks starts up being small, so people can understand them and easily learn. Then as time goes by the f…
> It would take more time learning how you start a React or Angular project… That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. Really, the argument could end here. Yes, there is overhead in using it, things can get out of hand, but they do not have to. If they do get out of hand, would vanilla web technology have prevented that?
> That time has has already been spent, because you hired React developers. They will be fastest by pulling in React.
I'm not entirely convinced that this is true, either. At least not in some general, a priori, way.
Doing stuff "the right way" with React or any other framework probably still involves a fair amount of ceremony, boilerplate, and testing. Would your hypothetical React dev be faster with React than some other framework? Probably--if that other framework is similar in scope and complexity. But, otherwise, I just wouldn't assume that an expert in FrameworkX will always do better using FrameworkX without regard to the specifics of the project.
Re: The case for frameworks
#79Earlier quoted context omitted.
> It would take more time learning how you start a React or Angular project… That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. Really, the argument could end here. Yes, there is overhead in using it, things can get out of hand, but they do not have to. If they do get out of hand, would vanilla web technology have prevented that?
> That time has has already been spent, because you hired React developers. They will be fastest by pulling in React. I'm not entirely convinced that this is true, either. At least not in some general, a priori, way. Doing stuff "the right way" with React or any other framework probably still involves a fair amount of ceremony, boilerplate, and testing. Would your hypothetical React dev be faster with React than some…
It is true in context. They will be faster than if they did not use a framework for anything that has even a tiny amount of repetition or interaction. That is why we have frameworks in the first place. There is no right way. React itself is not much of a framework anyway. It is a fairly small library for reactive UI. You do not need to be an expert to be productive in it.
Re: The case for frameworks
#80I think the original point of the discussion is somewhat lost, which is not frameworks, it's shipping too much JS to the client which in particular hurts on Android. Whilst I strongly agree SPAs are overused, let's take a moment to consider this sorry state of affairs. It's 2023 and when you ship some 50-200KB of executable code, you're in the red. This is like 1/7th of a damn floppy disk, which I've lived through. M…
>Compare this to a traditional, well-optimized MPA. You navigate to another route.
I think the issue here is that on an MPA you may get a white page for a while, or a page with missing pieces in unexpected ways, even if the overall loading is faster it looks more broken.