101–110 of 398 posts
Because browsers don't support server-side declarative views natively yet. FE development wouldn't even be a thing if web servers could respond with something like const [count, setCount] = useState(0); You clicked {count} times setCount(count + 1)}> Click me
Back when we all did MVC we had FE and BE devs anyways.
Because browsers don't support server-side declarative views natively yet. FE development wouldn't even be a thing if web servers could respond with something like const [count, setCount] = useState(0); You clicked {count} times setCount(count + 1)}> Click me
HTML and CSS weren’t designed to be general-purpose GUI description languages. HTTP wasn’t designed to be a client-server GUI application protocol. JavaScript wasn’t designed to be a serious application programming language. And the continued evolution of those technologies hasn’t focused enough on substantially changing that state of affairs. For example, a lot of basic UI controls still have to be custom-implemente…
Maybe not, but they are now, and are incredibly diverse in what that can achieve.
> HTTP wasn’t designed to be a client-server GUI application protocol.
Again, maybe not, but it is now with Websockets, http2 and webRTC.
> JavaScript wasn’t designed to be a serious application programming language.
Also maybe not initially but it is now incredible capable and amazingly only 50-100% slower than C! We now have WASM that let you reuse a vast amount of code from desktop too.
> basic UI controls still have to be custom-implemented and custom-styled by each app
Even with native gui toolkits developers are having to constantly build custom widgets for their specific use case. HTML gives us a baseline of widgets what work everywhere from desktop to mobile on all OSs. Would I like more? Yes, but what HTML gives us is the ability to build our own really easily, in an accessible way.
> CSS layout and styling is still a byzantine minefield.
I disagree, flexbox and grid layout are incredible and solve all the issues with the older box and float model.
> The ecosystem of tooling and libraries and frameworks remains highly fragmented.
True, and it can be a barrier to entry for someone new. However newer tooling such as Vite and ESBuild are incredible, fixing menu of the warts of the older tools.
But it would also say the the the amount of tooling options available is a testament to the success of the web platform.
> staggering amount of manpower is being wasted away in bespoke frontend development.
Most people don't want the web painted in the same shade of magnolia. Plus all those supposed "wasted" hours pay hundreds of thousands peoples salaries, supporting family and contribute to a vibrant economy.
The web platform is one of the greatest inventions of all time, and so incredible successful. It's so diverse in its capabilities and surprisingly performant at that. Honestly it's far better than people often give it credit form.
1. the mainstream adoption of AJAX
2. node + node development community (top 5% of node/npm contributors - also Google see 4.)
3. agencies trying to sell over-engineered BS to their clients
4. Chrome/Google
5. influx of non-CS/nerds into FED (commoditization of knowledge, process and perceptions.)
Because the browser nowadays is an "operating system" that needs to be capable of handling all manner of dynamic software: maps, video, image editors, games, etc. I haven't done Windows development, but I assume browser-based development complexity will continue trending towards essentially the same complexity as developing e.g. a Windows program.
i think the web platform is a very open platform. Sure, there are highly complex toolchains for the web, but you are not obligated to use them. If you want to, you can use vanilla JS (if at all), raw WebGL and even Wasm.
Then again, a lot of the complexity is mostly optional these days. But knowing how to avoid it is tricky, given the amount of tutorials online that will happily convince you to use webpack, redux and whatever else that was made for bigger problems as if they should be used everywhere.
I don't envy young programmers these days, the amount of stuff to wade through is just mindblowing.
It's artificially inflated and I'm seeing this in almost all areas, not just frontend. Some of the projects I've seen could have been reduced in size multiple times with no effect on the outcome whatsoever. In one instance I rewrote a GUI app and made it 15 times smaller (!), that's my absolute record to date. Been wondering for years, so you need to actually be inventive to add unnecessary complexity, it's not that…
I see it as Scientist/Technician vs Prophet/Priest.
These two pairs are solutions to a problem: the world isn't doing what I say. They can both work, or at least do better than random. The difference is that the former can explain why, and the latter can't.
The cool thing about not explaining? It makes the Prophet the only person who can evaluate the work. They have vision into the solution, and it appears only to them.
The bad thing about Prophets? If you've quantified the solution, then it can be falsified and replicated.
Wait a second . . how hard can it be to quantify a solution? It's actually really hard - particularly in things like natural language (tech comms) and visual arts (yes, front end is viz art, FIGHT ME :D). Some industries have blown up their prophets to such towering heights that they will set fire to clients and money and any other quantitative measure of value . . all in search of that One Truth (content re-use and so-called "single sourcing", I am looking at you, but I'm not even going to tease the elephant in the room that is AS9100)
People in insecure positions will always seek to turn their Technician position into a Priest position, even if they need to find some Prophet to cling to. And eventually, they might get a chance to be a Prophet too. It's like an MLM for your mind.
[1] "Structured content is the future!" Oh, is it now? How's that been working out for you last checks watch twenty years? "Hierarchical organizations are required for finding stuff!" Do you know, I think I remember the Internet Outline google publishes ever second /s. Ah, "useful".
Another reason is that the languages and tooling to do these things are always easy to start and painful to master, leading to too many sort-of capable people dreaming about how to do it better.
• Internal/enterprise apps. Instead of writing a full web app write a desktop app using one of the many new frameworks for it and connect directly to your database. Use views, row level security and other RDBMS features to implement declarative ACL logic, and stored procedures as a thin RPC layer when necessary. Benefits: eliminate the whole web tier, no SQL injection (users log into the db as themselves), no load balancers (client side can fail over between replicas), use non-JS languages over the whole stack without transpilation, give users ultra-low latency UI without lots of work, feed output of your SQL library direct to the UI toolkit, no browser compatibility bugs.
• Eliminate mobile/web duplication. Use Jetpack Compose/Kotlin Multiplatform/Flutter/etc to bring your mobile app to desktop and keep all the frontend codebases synced.
If we assume by frontend you mean exclusively web apps, complexity seems to have come from several places:
1. A desire to use something better than JS (typescript, coffeescript, kotlin, whatever).
2. HTML5/JS's failure to provide a components model leading to it being layered on top with npm, webpack, react, etc.
3. A desire to eliminate state-management related bugs via FP techniques.
4. A much wider recognition that latency is important, causing practices that were once routine to be now officially frowned upon and creating piles of complexity through optimizations.
5. Assumption/desire that websites will work on mobile/tablets, even if a native app exists, causing a lot of work for responsive design.
6. Lack of anyone other than Google incentivized to really improve the platform, causing an explosion of tiny GitHub projects that each seek to solve a micro-problem which then get cobbled together into ad-hoc per app "frameworks". Compare to the Apple stack, the Microsoft stack, the Android stack, the Java standard library etc where a lot more stuff comes out of the box and they try to solve app development end to end.
The question of whether this complexity is necessary is always relative. Many apps have a captive user base who are much more sensitive to feature throughput than looks or how quickly the app loads. Things like server side rendering+rehydration are just a distraction there but they often come along for the ride due to the industries preference for using FAANG freeware over buying platforms that could then be more tuned for the customer need.