In Clojure I came in contact with REPL-Driven Development which coming from a C/C++/C#/Java background was absolutely foreign to me (apart perhaps from working in an SQL shell).
Similarly with JavaScript, at least on desktop browsers, through the Web Developers Tools console one can interact live, directly with the browser and the page or even just simply locally throw together an index.html to play around with some ideas.
Sure, you can go to the TypeScript Playground to play with some TypeScript but that doesn't have access to the browser; sure one can use services like CodePen or CodeSandbox but one typically has to figure out the idiosyncratic details of their UI and platform.
Yes, it's not that difficult to "just" download create-react-app (if you're comfortable with npm), though but, gee …
Dave Thomas
@pragdave
Installing react, react-dom, and reason-scripts...
+ react-dom@16.6.1 + react@16.6.1 + reason-scripts@1.0.0 added 1694 packages from 659 contributors and audited 32802 packages in 79.021s found 0 vulnerabilities
Point is, having an incredibly low barrier to experimentation is invaluable (I assume that's why framework websites often have playgrounds associated with them).
Sure, tooling is bound to aggregate around products as they move closer to production but it can be really useful to have an extremely low barrier to just getting started.
They all suck. While they all suck, everyone needs a framework. What everyone doesn’t need is a general-purpose framework. Nobody has a general problem. Everyone has a very specific problem they’re trying to solve, and the general-purpose framework, while it can solve it, it usually solves it in a way that you get so many other things that you don’t need that ends up being done on every request.
People were worried about vendor lock-in with application servers, now they are worried about vendor lock-in with cloud service providers , meanwhile mindset lock-in is in full swing with frameworks. I can't even imagine how irritating it must be for authors of the "other" frameworks, to constantly have to explain themselves in terms of React — when React isn't even of the web — in fact it was created to de-emphasize the web.
Perhaps it's developers who need to be "framework-agnositic". The problem is that adopting any particular framework (of any kind) represents a significant investment of time and effort, naturally pre-disposing one to fall victim to the golden hammer rather than pick the right tool for the job. The typical "enterprise response" is to settle on one "batteries included" solution and standardize on it — however that often leads to added baggage which can typically be absorbed in the enterprise space but often not so much on the public internet.
Know what else is composable? Components.
Mmm — that is highly context dependent.
The wider and more complex the interface of a component (in the general sense) is, the less composable it is - a component is an object after all.
Well there is something incredibly powerful about the framework provided primitives and the end user creations being the same.
This adheres to our general principle - we do not provide built-in mechanisms, we provide primitives with which mechanisms can be built.
(primitives in Erlang: spawn, send, receive, make_ref, etc. — the (composable) mechansims are built with functions, tuples and lists.)
So perhaps some framework "primitives" are just poorly chosen?
From that perspective React would already be a mechanism on which other custom mechanisms are built.
If you've used <For> you know how to use <PaginatedList>.
Components (in the React or JSX sense) can require and support a vastly varying set of props (and children) depending on their role.
For example <div> plays are very different role from <CountContext.Provider value={value}>{children}</CountContext.Provider> and require a very different understanding to be used effectively. From that perspective the composability of "Components" is purely a result of by design being constructed to collaborate within and through the component tree via an implicit interface. That's OOD 101. Design Patterns: elements of reusable object-oriented software; 1995, p.18:
Program to an interface, not an implementation.
And implementing framework specific types is par of the course with frameworks.
I am talking about ones that make heavy use of compilation to do work ahead of time.
In some sense compilation is a responsible means of providing "developer experience" because it can create value without deferring the cost further downstream. Often "run time is cheaper than developer time" is the justification for deferring cost further downstream but certain forms of compilation can help to mitigate that.
Progressive enhancement is a consideration like Accessibility.
Recognize that the web simply doesn't have the same slack that desktop and native have had in the past to cover potential inadequacies of the development process. Some practices that worked there simply cannot be tolerated on the web and shouldn't be expected to work.
Respect the user's resources and don't take them for granted: connection quality, bandwidth and speed; compute power and battery charge.
i.e. don't design an application that will only work under optimal conditions; deliver functionality with the minimum amount of HTML/CSS and JavaScript to engage the user as quickly as possible, then carefully and judiciously download and cache additional capabilities.
And part of that is Multi-Page App Frameworks are dominating innovation in this space given Single Page Apps are less optimizable in this way.
Putting a different spin on this: SPAs introduced monoliths to web applications.
The history of SPAs seems to go back to about 2003; meanwhile in 2005 microservices became a thing, largely leaning on the idea of a bounded context from Eric Evans's Domain-Driven Design in 2003.
Then Micro Frontends made an appearance in 2016 - which in my judgement completely failed to take the nature and constraints of the web into account - especially when claiming the "benefit" of micro frontends being able to each use their own distinct/separate UI framework.
Perhaps MPAs will become the real "micro frontends" — each page having highly focused capability which can be downloaded relatively quickly while sharing resources with other pages from the site via Service Worker, Indexed DB, and BroadcastChannel (SharedWorker would be nice).
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In Clojure I came in contact with REPL-Driven Development which coming from a C/C++/C#/Java background was absolutely foreign to me (apart perhaps from working in an SQL shell).
Similarly with JavaScript, at least on desktop browsers, through the Web Developers Tools console one can interact live, directly with the browser and the page or even just simply locally throw together an
index.htmlto play around with some ideas.Sure, you can go to the TypeScript Playground to play with some TypeScript but that doesn't have access to the browser; sure one can use services like CodePen or CodeSandbox but one typically has to figure out the idiosyncratic details of their UI and platform.
Yes, it's not that difficult to "just" download
create-react-app(if you're comfortable withnpm), though but, gee …(I typically just use Preact).
Point is, having an incredibly low barrier to experimentation is invaluable (I assume that's why framework websites often have playgrounds associated with them).
Sure, tooling is bound to aggregate around products as they move closer to production but it can be really useful to have an extremely low barrier to just getting started.
I think Ramus Lerdorf summarized it well:
People were worried about vendor lock-in with application servers, now they are worried about vendor lock-in with cloud service providers , meanwhile mindset lock-in is in full swing with frameworks. I can't even imagine how irritating it must be for authors of the "other" frameworks, to constantly have to explain themselves in terms of React — when React isn't even of the web — in fact it was created to de-emphasize the web.
Perhaps it's developers who need to be "framework-agnositic". The problem is that adopting any particular framework (of any kind) represents a significant investment of time and effort, naturally pre-disposing one to fall victim to the golden hammer rather than pick the right tool for the job. The typical "enterprise response" is to settle on one "batteries included" solution and standardize on it — however that often leads to added baggage which can typically be absorbed in the enterprise space but often not so much on the public internet.
Mmm — that is highly context dependent.
The wider and more complex the interface of a component (in the general sense) is, the less composable it is - a component is an object after all.
Joe Armstrong:
(primitives in Erlang: spawn, send, receive, make_ref, etc. — the (composable) mechansims are built with functions, tuples and lists.)
So perhaps some framework "primitives" are just poorly chosen?
From that perspective React would already be a mechanism on which other custom mechanisms are built.
Components (in the React or JSX sense) can require and support a vastly varying set of
props(andchildren) depending on their role.For example
<div>plays are very different role from<CountContext.Provider value={value}>{children}</CountContext.Provider>and require a very different understanding to be used effectively. From that perspective the composability of "Components" is purely a result of by design being constructed to collaborate within and through the component tree via an implicit interface. That's OOD 101.Design Patterns: elements of reusable object-oriented software; 1995, p.18:
And implementing framework specific types is par of the course with frameworks.
In some sense compilation is a responsible means of providing "developer experience" because it can create value without deferring the cost further downstream. Often "run time is cheaper than developer time" is the justification for deferring cost further downstream but certain forms of compilation can help to mitigate that.
I think to some degree that is only part of it; Everyone has JavaScript Right?
i.e. don't design an application that will only work under optimal conditions; deliver functionality with the minimum amount of HTML/CSS and JavaScript to engage the user as quickly as possible, then carefully and judiciously download and cache additional capabilities.
Putting a different spin on this: SPAs introduced monoliths to web applications.
The history of SPAs seems to go back to about 2003; meanwhile in 2005 microservices became a thing, largely leaning on the idea of a bounded context from Eric Evans's Domain-Driven Design in 2003.
In 2015 I vividly remember running into blog posts like Mixing MPA and SPA: worst of both worlds.
Then Micro Frontends made an appearance in 2016 - which in my judgement completely failed to take the nature and constraints of the web into account - especially when claiming the "benefit" of micro frontends being able to each use their own distinct/separate UI framework.
Perhaps MPAs will become the real "micro frontends" — each page having highly focused capability which can be downloaded relatively quickly while sharing resources with other pages from the site via Service Worker, Indexed DB, and BroadcastChannel (SharedWorker would be nice).