Red flags words in web tech/tools to me:
- modern
- revolutionary
- love ("really really like" is ok)
- can't go back to / can't live without
- is the future
- just (describe which is not)
The front end community wants to wash its hands of the decade we lost
81–87 of 87 posts
Re: The front end community wants to wash its hands of the decade we lost
#82Earlier quoted context omitted.
There are a couple of full-blown text editors written in vanilla js so it's very capable of doing highly interactive.
Of course it's _possible_. If you go deep enough, React is just vanilla JS after all. The question is how fast a team can build and maintain something with each method.
This is what I do. Make the core pattern solid (barely touch this), and extended functionalities in vanilla way; i.e. just write another function receive context and return expected things. You can use solid/uhtml/preact/lit "the view part" they all have it separated from component model. It's 6-8kB (.min). Everything else is just application logic. react-dom is 130kB now and even slower than the rest.
Re: The front end community wants to wash its hands of the decade we lost
#83Earlier quoted context omitted.
I agree, if you are that virulent about what is wrong, maybe you want to give a clue as to what you think is right. Or do you just think everything is wrong?
OP here; at a tactical level, prefer HTML/CSS and MPA architecture until you have firm evidence of long sessions and many interactions per session that justify JS, and when you add JS to smooth a common interaction based on data, build from progressive enhancement unless it's impossible (e.g., a text or image editor). More pithily, maybe PHP was good, actually? Popping up a level, this isn't about tools, it's about c…
another thought:
The root issues here are down to complexity and eng/management capacity to master it. What gets teams in trouble is picking stacks that have mountains of implicit complexity without attendant controls.
i agree that some (or maybe all) frameworks go needlessly complex with their dependencies. little libraries that contain one function that should really be folded into the other libraries that are using that function.
but isn't part of the problem the the inherent higher complexity of modern interfaces? the days where a site as simple as hackernews are appealing to the average person browsing the web are gone. i am afraid that in order to compete for visitors or customers, we have pushed ourselves into a corner. doesn't any new website need to function and look as modern as every other if it wants to have a chance?
a large engineering team with a sufficient budget and time may accomplish that without a framework, and so you are exactly right, the strings to accomplish it need to be pulled at the very top. but what hope do we have when the primary directive that comes from the top is to keep the cost down?
especially new projects suffer from this. i can only afford to spend engineering resources after a project has become profitable. but in order to get there, i need to cut corners where i can. that usually means using frameworks to get up and running fast. and once we make a profit we can spend money to improve things. but by then it's to late to switch to a non-framework approach unless the resources are enough to start over.
the complexity caused by frameworks is costing us money. but it's money that is now available because the project is making a profit.
wouldn't your approach require higher expenses upfront, at a time when i don't even know if it is worth the effort?
Re: The front end community wants to wash its hands of the decade we lost
#84Earlier quoted context omitted.
> It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better. People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'…
Client side development isn’t trivial on any platform. Comparing a Go project with a client application just reveals that client apps rot faster because the devices that run them and the software on them are moving targets, esp mobile devices.
Nothing fundamentally changed in the last few years AFAIK. I see no reason why it should rot faster. I've written things over ten years ago that work just fine today.
Client-side JavaScript is actually very compatible; see for example .at() to fix the [] subscripting behaviour (the reason [] wasn't changed was due to compatibility concerns; arr[-1] gets treated as arr["-1"], and changing it may break a script or two).
Re: The front end community wants to wash its hands of the decade we lost
#85Earlier quoted context omitted.
> It’s not perfect. I think we’ll find a better approach eventually, which is why I’m fine with the churn. The churn is part of the search for something better. People have been building UIs for quite a while now; from before a large percentage of people reading this were born. It's not exactly a new thing. I have generally found building UIs a bit painful in any language, so sure, let's go find a better solution, I'…
Well, a lot of the “modern” frontend frameworks/libs are having the same symptoms that you describe as the entire world has changed, because it’s actually IS… Good luck working on a two years old Android project where Android Studio won’t even open it.
That sounds like a problem with Android or Android Studio. Two years really isn't that long of a time, and I don't really see anything in the world that really fundamentally changed in that time.
Re: The front end community wants to wash its hands of the decade we lost
#86Earlier quoted context omitted.
I worked with React.js for more than 5 years in a big projects and I finally burnout of it, I agree with all you said, React added a extremely complexity for simple thing, added a lot of side affects that sometimes are hard to debug and fix, fix re-render will be your daily work more that create features and in the end you get a slow application in mobile devices due the size/re-render etc. In the end I decided to re…
From engineering perspective react-dom is being 130kB (.min) while the other is 6-8kB AND faster in benchmark, yet the industry decided this is acceptable, I know that our engineering principle is rotten.
Indeed. This is something the the staunch React folks are missing: with vanilla, I can cut out a LOT of excessive payload.
Re: The front end community wants to wash its hands of the decade we lost
#87Earlier quoted context omitted.
It's been while since I've heard frontend devs even speak about actual frontend. Layouts, fonts, accessibility, that sort of thing.
When I interview front-end devs, I still focus on core fundamentals and I want to see if they can build simple interactions and layouts in HTML, CSS, and simple JS via jsfiddle. My assumption is that if they can do vanilla well enough, having them do React is easy enough. The reverse is often not the case.
That's very wise.