Convopage
See the entire conversation
410 replies and sub-replies as of May 25 2017
peacock feathers.
I think it's partly competition on mobile UX, which is just hard to do well with traditional primitives. Then there's overengineering.
And simultaneous underengineering, oddly enough. The tool chains are not exactly mature and churn rapidly enough to make it difficult to.
From the outside it seems like lots of ppl doing 5x the engineering effort (framework) to avoid 3x the effort (iOS, Android, mobile web)
More fun to write a framework than an app :)
Over engineering and personality cults within a bubble of social websites and phone applications has created a doomed development meme
Re-inventing the wheel and throwing bootstrap on it is the new business model. And by business model, I mean exit scam via buyout
Lower entry barriers has allowed half-baked projects to be marketed to the lowest common denominator.
I don't think so. Frontend has massively grown in what is possible and what is demanded ; tools are just keeping up.
Yes but don't worry. I'm working on an intuitive lightweight framework that will make it so much easier.
Somebody else #onhere suggested that Javascript frameworks suffer from the Curse of LISP because JS is secretly a LISP. Not obviously wrong.
We're working our way through the design debt caused by having too few senior folks involved in front-end for too long.
For a long time, back-end was for "serious" development, and front-end was dismissed and done by devs with little experience.
So now we're overcompensating by constructing rococo architectures clientside as a kind of peacock tail fitness signalling?
maybe npm and the like need to have some kind of standardizing review process... the npm install 15 lines of code is ridiculous
Could be, though I think dependency management is unsolved front-end and back-end, and I don't know what the solution looks like.
You might enjoy reading github.com/sindresorhus/a… for a longer rationale of the benefits of small modules
One-line node modules · Issue #10 · sindresorhus/ama
Lot of people don't get the benefits of one line modules, what would you say to those who tend to critic a lot about node modules that have just a line in them?
github.com
That is a good rationale. Thanks for sharing!
Could be overcompensating for the long snub, sure. But also we're blundering through a big design space we neglected.
it can be difficult to tell the difference between a senior dev saying "we tried to solve that problem...
...before and that solution didn't work" and a senior dev saying "lol Javascript is shit why would you even"
Our effort went into cracking back-end complexity, because that's where there was enough experience to make a difference.
But we dropped the ball. Back-end is a relatively controlled environment, whereas front-end is out there in the world and very complex.
Now we have a generation of front-end engineers who have been thinking about hard problems for 10+ years.
So we get React.js, which seems to me a genuine leveling-up. Other things, like Elm, are on their way.
But we also have to deal with instability (and some bad ideas), because we're scrambling to overcome a decade's neglect.
Not exactly. :-)
But I think they are present and contributing to the mix now, where they weren't before.
The back-end architects discovered that front-end basically had none, so they set out to change that.
Lol. Back end architects saved the day? Some of the worst front end code is written by back end devs who consider it toy languages.
I agree with this but some front end frameworks (looking at you angular 2) seem to be designed with back end developers in mind.
Angular reeks of back-end patterns. Ember takes DI seriously. React+Redux tries to be overtly functional. All new-ish to many web-only devs.
I don't find React functional at all. It aligns incredibly well with OOCSS and front end UI components, if you bother building them. ;)
E.g. The little building blocks like the "media object". Many react devs skip making those little pieces and end up w a ton of snowflakes.
I more mean functional in the "input yields output without manipulating state" sense, but yeah: componentization is an underrated skill.
Angular tried to come up with a code free dsl, rather than enabling easier web programming. To hilariously bad results.
Fair to say BE devs tried to solve their challenges with FE, without asking FE devs about the challenges they have had (for longer)?
I didn't mean that as a value judgement, just a statement. Architects discovered the web and did their thing, with both pros and cons.
I like the premise of your statement butIf the result of their thinking is me not being able to turn off "helpful" themed images then no.
It is a fact that a lot of what traditionally used to happen server-side has moved to the client. /1
Tools are being developed to let people do client-side the same kind of stuff they do server-side, infrastructure wise. /2
I agree, but you can't stop people from making tools to their life easier the same way you can't stop people from adopting these framework.
I think the "constant change" is given from the fact that we are in a transitional/evolutionary phase. In few years I think it will settle.
Yes, pretty much. But "rapid change in the web" for me means rapid evolution of the tool-chain to make people lives easier.
I work with javascript a lot and I resisted adopting npm, webpack and all the she-bang but now I am using it and it makes my life easier.
Doesn't mean Im not annoyed that things keep changing or that I like it, believe me 😂 but I find myself in need of some of these frameworks
Mine is in some ways, i.e. dependency management in js is a nightmare comparable to "dll hell" without some of these tools.
Or even modularisation of components etc is really hard to achieve in vanilla javascript. There's a reason why this stuff gets adopted!
Again doesnt mean I like the state of things and it is messy, but depending on what you're doing (important) tools improve quality of output
Glad to be part of the convo. 👍
I think Yarn+Lerna is a thing
This can also be happening due to the rapid change in browsers. Most backend apps don't change much in terms of infrastructure for years. /1
But adapting to changes in FE require tools to make the transition easier. In many cases tools are not able to follow the rhythm though. /2
yeah it is. Been teaching students React for the last couple years — create-react-app and ESLint and Prettier have made it so much better
you just gotta wait for the second generation of tools, which people make after they’re fed up with the first generation’s attempt
My life is!
An increased learning curve makes for happier, productive lives when you're used to it.
Lives of users of well-made apps are. The churn comes from trying to make meeting super-high bar of user expectations less impossible.
You can't speak for everyone. Once you get over the initial "JS fatigue" snark, the tooling is getting more and more convenient.
I started coding (I'm a product designer) around the time Node started to become popular and I'm working on web apps now.
Can't see this happening 10y ago. In my perspective, it's never been simpler, especially talking about the React ecosystem.
AngularJS 1.5 and above has made my life easier
I doubt it settles down, because the scaffold we are building around, the browser , is gonna change big time.
I think JS and frontend was so terrible for so long, that it's inevitable what has happened. But it's such a low barrier to entry too
Yes I think we are witnessing a trend where people try to improve things by building building building tools. Annoying but it'll get better.
The server is also controllable by the developer., the browser not so much.
You did for a while until 2 or 3 one out. Evolution of tools very rapid and choatic early in development of ecosystem.
We used to
the server is, by its nature, controllable by an engineering team. It doesn't shift under you like...
...client platforms do. Like, you can decide to run a 20-year-old Java app because you know its...
...assumptions about runtime env. JS dev is kinda like gamedev: gotta account for many different envs.
Yes we do get 10 plus frameworks a year server side in addition to all kinds of compiler and tooling changes
I think the eco-system is very fragmented and I agree the pipeline appears to be overcomplicated, but this is a transitional phase. /3
Web API ever-expanding so we built tools to manage the complication & tools to manage the tools that manage the complication. Ad infinitum
Considering the constant change of frameworks, what recommendation do you give to someone who wants to learn front end development?
That's a bold answer.
It's got a grain of truth. I'm just not sure if the distribution of accidental vs incidental complexity.
I like that Vue.js is committed to being usable as a library. I've slowly been incorporating it and learning as I go.
Someday the things the fronted toolers work out as libraries will be native or at least broadly accepted. Until then I appreciate gradual
Old school & feeling lazy here, Im still hammering away with just HTML & CSS, okay adopted using SASS but thats as wild as I get after 10yrs
I just bought "HTML & CSS: Design and Build Web Sites" book today. Will be digging into it for a few weeks now. :D
Pick one and stop worrying about everything else. I regularly work with co's who use stable legacy frameworks and this is the case for them
Going through your old tweets. ;-)
Learn plain old JS if you don’t already know it. Learn it *really well*. Then move on to frameworks.
I've been working on it recently and I agree. Happens for the same reasons that J2EE happened.
engineers like clever solutions, instead of solving problems people actually have. Nothing new under the ☀️
Don’t Let Architecture Astronauts Scare You
When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending…
joelonsoftware.com
Nailed it.
Often because of resume-driven development. Rack up points by using new and different technologies.
"Resume driven development" is a great descriptor.
Job security though tech dependency
I think it is some sort of Cambrian Explosion, a huge ecosystem is evolving in high speed and trying a lot on each step for best fit
This seems to be the most accurate answer in the thread. 👌
And headed for entropic drift which means it will only get worse.
I know it is tiring but I'm not that pessimistic. Standards are settling in (flux arch., virtual dom etc.) for main problems.
similar journey happened in #php world (maybe less tiring) and now some of the defacto packages are almost a decade old and highly reliable
It became an application development target REALLY quickly. Lots of folks who weren’t application devs suddenly were. Chaos ensued
Over the last five years, as mobile devices became powerful enough and their browsers standard enough to run application code
A lot of application dev problems were new to front end devs. That makes frameworks / tools that purport to solve hard problems attractive
that has brought with it a lot of additional complexity.
You could say the same thing about desktop application developers w.r.t. assembly…
yeah for sure.
I guess my point is the complexity is a result of building all of the abstractions in a tearing hurry.
To me it feels like things are starting to settle down a bit, and people are focussing on complexity-reduction.
What's insane is that CSS/etc is to a point where you only need a couple hundred lines of js code w/cooperating server. Needless complexity.
Just look what is available as a starting point these days: w3schools.com/w3css/
Frontend allows for much more rapid development. One role can now write a browser app. B4 there was dev lag between backend and frontend.
My feeling is everyone's trying to build 1/1000 scale models of the biggest building they can see rather than, you now, a house
I.e, the tools that the biggest projects for millions of people use everyone wants to use because they see their idols using them.
The tech press, industry, blogs etc have a HUGE bias towards projects worked on by 100s or 1000s of people not 1-3 like 99% of projects
Yeah. I feel what's missing is any industry focus at all on the vast majority of devs who work on a team of 1 doing small budget projects.
It's not like the large projects are getting easier, either. And it's not only web frontend. Both native desktop and mobile are painful.
I.e. I think we're sharing problems between small & large, all kinds of UI, across platforms. Complexity is spiraling out of control.
Agreed, I think "progress" is happening much faster than learning, which is always a bad sign.
Progress always happens faster than learning. Strap in for a wild ride ;)
As someone with one foot in the academic sector and one foot in the tech, not sure that's true for all fields actually :)
Which is to say: most fields use learning to understand what to build next. Tech sector uses technology to find out what to learn next.
All engineering disciplines are driven by "I wonder what will happen if..." - and they're always tempted to step outside the well-known.
It's just that software is *exceedingly* ok with failure, and so often application and experiment is the same. "move fast and break things"
N.B.: I don't think that's a good thing. I also think that commercial pressures and prevailing culture will keep this entrenched for a while
Sure, but in that position you're using what you know to inspire future development. Right now we literally have IoT shit noone wants imo :)
Yep. Commercial pressures. Because you can certainly use it as a selling point, and it's cheap enough to add crappily.
A major IoT related disaster is my most likely bet for the industry to be reigned in.
Yeah altho that big botnet attack a month ago seemed to phase noone? Its like people can't see the 2 hands are connected :)
They'll see it once they can't open their fridge because it was ransomware'd. Or, more likely, when they end up injured due to car IoT
I'm seeing IoT stuff noone asked for being sold wholesale to people who barely have a web presence. It's a strange time.
Almost every piece I read presumes you are part of a large team and have an incredibly specialised job rather than a jack of all trades
Consequently the frontend is pushed/allowed to implement events that supply a lot of the data that they crave.
Front end tech is very bad, so even if every new development is an improvement, it's not good enough to stick. Nothing Lindy Effect-worthy.
Personally I'm just staying away until things settle down for a good long while. I don't envy those that don't have that luxury.
Nobody has made a good web app yet; how would we know what to standardize on?
You can see some of it coalescing: there's basically three major frameworks with a long tail of also-rans. All use the same package manager
Each in a distinct cultural role: Angular, like J2EE was, is the "corporate" choice; React, like Rails, is the "hipster" choice
I haven't worked enough in Ember to assign them a stereotype
Ah let me help you out. Ember is the 'run, screaming, into the arms of something that promises to make the pain go away' choice
Until today+n, when there are new corporate + hipster choices because it ends up being a pissing match.
I think the Gsuite is pretty good. But that's the only example I can think of
Thankfully the fundamentals all work fine and you can pretty much ignore all the reinventions of the make wheel.
Because backend devs are trying to make frontend dev “serious” mobile.twitter.com/thomasfuchs/st…
1997: Let’s make a website!
*fires up vi*
2007: Let’s make a website!
*downloads jQuery*
*fires up vi*
2017: Let’s make a website!
😵
Maybe frontend devs were jealous because they didn't get to play with Maven.
Not for Maven, but I do think a lot of the frontend BS involves jealousy
Could you expand on that
A big difference is that you can easily upgrade Python on your server, but you can't upgrade Javascript in everyones browser.
And people want to code in a newer version of Javascript because it's much nicer to work in. So they must transpile which is a PITA.
Google's V8 made running JS exponentially faster. You can't strap a jet engine on a bicycle and expect great steering.
sadly that doesn't cover having to wait 5 seconds for a daisy-chain of 40 ad-auctions to complete before the text of the page shows up
The complexity is the same than always. Building a complex webapps 10 years ago (say Gmail) involved ending with something as complex...
... As current React stack. It's just that now we have shared frameworks instead of in-house ones
People thinking that they need a webapp framework to build even basic web pages is a problem, though
If Web Assembly takes off hold on to your hat!
The rise of REST, and the responsiveness of SPAs
point of order on "responsiveness"
As a frond-end dev, it doesn’t feel that way, but I do see a lot of specialization has happened, whether towards devops or js frameworks.
I feel it’s mostly the focus on making and releasing new tools constantly instead of doing that *and* giving them sane defaults.
No type of engineering or deveopment is easy... Who said it was?! You can be a Rocket engineer, or you can build Knex rollercoaster. Pick 1
Combination of factors, from poor HR and buzzwords, to lack of software best practices in a hardware-rich world, and multitude of solutions
To poor developers who can't properly use the tools, creating more problems that they solve, leading to a downward spiral
the majority of consumer developers tend to prefer "easy startup + complicated" over "simple for a small amount of up-front work"
JS has no standard library, resulting in a nightmarish network of leftpad-style dependencies and tools to manage them
And without a native module loader (and the concept of asynchronous dependcy loading from HTTP) using libs was never as easy as it should be
That, and while you can use any language you want on the backend, you have to use js on the front end, which has no stdlib
Appears to be a combination of being driven by huge tech companies with large but underutilized teams that then churn on tools development,
With a lack of experience on the value of stable tools and the dangers of complexity. Similar to J2EE where garbage collection made it
Possible to focus on "architecture" instead of the needs of the machine, causing a tool complexity explosion that is now widely despised.
(And yes I am relatively old for this industry and it feels weird to see the same mistakes being repeated again)
Yeah definitely the XML era. It starts with a reasonable idea then grows out of control until you can't remember what you were even doing.
And XML is still fine, but using it for a 5-line INI file is the idiocy. Like using React+Node for what should be a 50-line js file.
Scientists stand on each other shoulders. Programmers stand on each other's feet.
liking your stuff.
You can use a subset of the options and be productive. You don't need adopt them all. Or have constant churn in your chain.
most of the complexity is b/c you need to make decisions about what import system or compiler on top of the framework
The answer to the specific question of “why?” was given by @timbray in 2014:
The GitHub preview for this link just makes it sound even more insane.
Path dependence: Years ago browsers standards support was bad, so frameworks we're required. Today frameworks are assumed w/o question.
From my POV complex tools have been developed for massive scale and suddenly everyone thinks they need them for their tiny hobby project
Before that: J2EE and .Net. Before that: CORBA and so it goes on and on..
I'd put an asterisk on this - some of those tools make sense for messy data, not just big data. Munging the whole data set reproducibly.
Oh no, they make tons of sense for the spooks, too. Just not for your wifi connected kitchen coffee grounds composter site.
It’s fair, but it’s also a phase. Ambitions have outpaced the tooling at the moment. The tooling will catch up. The problem itself is hard.
Some of the tooling problems are self-inflicted— nobody *needs* Babel, but they *like* the language it lets them write in.
The rest is the field reinventing windowing systems, operating systems, & compilers in the browser sandbox, because it needs them.
It’s an ever-constant truth about the profession, I think, by which I mean programming in general. Browsers make it hurt more than usual.
Could you elaborate on this? I'm interested in RDF and would like to know tour perspective.
Don't think it's fair FWIW. Driver of complexity is IMO recognition of difficulty of building dynamic sites w/ good perf and rapid iteration
Overabundance of mediocre, slow JS tools that *should* make life simpler but in reality rapidly complicate otherwise simple webapps.
New devs. Millions of them apparently. Most start out in the front end.
Building complicated applications is complicated. Building simple applications remains simple.
I'd suggest that simple applications don't stay simple for very long. Any measure of success seems to force complexity.
💯 Definetly one of the reasons I'm able to be productive is keeping thing simple, both in feature set and tool chain.
Isn't that what theoretical physicists call entropic drift? The migration from order to disorder?
More like, simple application become complicated because of new information. (Pivot, user feedbacks, etc)
1) Web platform has bad APIs, constrained bandwidth; most room to maneuver in precompilation
2) The way of improving the web IS the web. Pulling in resources from everywhere, not 1 compiler vendor. Easy to laugh at left-pad, but d3?
3) It's partially the nature of URIs, and partially that the web makes distributed efforts possible.
4) Unusual position of browser; end user's platform is also the debugger! So compilation more complex.
5) Cascade of JS frameworks all have equivalents in C++ dev; what's new is speed of adoption, distribution, commingling in 1 project
6) Bigcos promoting a framework have incentives to make it a standard (mindshare, recruiting) but not to make it work well for small shops
It isn’t that bad. It’s more “124 ways to vaccum the floor”, with many kinds of tools being great and often interchangable
Obviously deliberate corporate overengineering to lock devs into own bloated redundant protocols. 'Cause jazzcript is the most powerful now
Some of it is the web coming to terms with being a distributed system.
Some of this is the complexity that used to be dumped into flash.
the difference is today building content websites in react is socially acceptable and building them in flash never was
I think content websites today aren’t content sites of yesteryear.
Why? How have needs changed?
Economics (ads, retention), aesthetic visual design, readability on mobile + desktop, audience sizes, sharability, the use of links
All those things favor less javascript (and faster page loads), not more. Ads induce javascript bloat but that was true ten years ago
And eg:opengraph tags for sharing only work if you render server-side
Google & FB. Rails & django born from real/common need. Angular & react born for much smaller, more difficult need. Also helps them hire.
Also mimicking class based inheritance. See .extend in backbone, createClass in react etc. Language not embraced by popular frameworks.
FB & goog have resources to reinvent everything. Why avoid using existing libs/build on layers? Compete for cleverness to attract hires.
I think it has something to do with the transition from "served web pages" to "full apps"
Writing a program that terminates in C is also way simpler than something that has a GUI and widgets and etc
It depends on where you start. You can start simple and build out:
Step-by-step tutorial to build a modern JavaScript stack... • r/node
47 points and 7 comments so far on reddit
reddit.com
As for why: Corporate interests invest heavily in driving adoption of their open source tools regardless of the problems they actually solve
Which makes sense. The tools are open sourced to derisk the codebase, increase feature support, and reduce maintenance cost.
A comparatively small investment in driving adoption yields massive payoffs.
That initial adoption yields even more evangelists (as adopters seek to derisk THEIR investment). Thus, the hype train.
Just coming to front-end dev from the backend. It feels like the tool chains haven't caught up to app development problems
We were running into problems developing our app in the existing stack (Backbone). Did a whole big thing researching a new stack...
...wound up with Typescript+React+Redux, but still a lot of ?s on our spreadsheet. Lots of conversations like this: [...]
"React has a pretty well-supported solution for rendering"
"Great! How do we do state management?"
🤷
😐
"Redux seems like it will meet our needs wrt state"
"Great! How do we make HTTP calls?"
🤷
😐
"OK, here's a rundown of the ways Redux people do HTTP."
"Most of the don't have debouncing, or even cancellation"
"So...that other one?"
It was like that all the way down. Even just for state, Redux doesn't provide you a lot of guidance on how to structure your store...
...or what to do about the fact that an entity can be in transit or the request can fail. We wound up rolling our own for most of that.
I'm not slamming the Redux devs. They've solved a lot of hard problems. It's just that they also /haven't/ solved a lot of hard problems
Very different experience with our backend stack. Java suited our needs, Dropwizard had most of what we needed, the rest was an easy bolt-on
Basically, it seems like the webapp ecosystem need time to mature and settle around some good practices
</thread>
Not moving beyond HTML and CSS. SVG was designed as a replacement in 2001, what are you using today? SVG makes it easy but you like complex.
Yes. Movement from server to client. Lack of maturity of client side tooling and client side education. Front end developers...
...making same sins of backend developers that were worked through a decade ago.
Too many frameworks that change too often (Angular disaster much?). Too many short lived tooling/services.
In the end we have OSS that is vendor lock in the end. You're buying into ecosystems just like in closed source stacks.
Frameworks are the scout team for what developers will soon demand natively from browsers. jQuery ➡️ querySelector, react ➡️ web components
This pattern is ingrained enough that developers' wants are always outpacing browsers' capabilities
It's similar to how induced demand works with car traffic: expand a highway and people think "I can go so much farther with a 1hr commute!"
Rather than "I can travel the same distance in much less time!"
Ha right but in the end neither is correct because all it does is attract more cars.
And I'm not convinced this will change anytime soon. Still very immature platforms. In transition and it sucks for frontend and backend.
JS has no std lib so everyone uses a different one. Facebook released a kick ass framework that is incomplete. Only solves half the problem
list lib (immutable.js), css modules, datetime, internationalization, local store, session mgmt, animation, ss render, build pipe,...
Response cache, analytics, authorization, bundle splitting, transpiler, source maps, reactive design, component lib, data flow (sagas? Loop?
Unit Test framework, functional testing framework, form validation lib, error handling and reporting, websocket framework,
#apolloclient handles data cache and data flow
Ya there's a ton of other stuff you *might* need depending on your requirements
And by *might* I mean definitely. But you prob don't need websockets at least 😆
I will also say we are coming to a head with technologies trying to bridge the web/native app problem. That's really throwing a wrench.
Words on this dance:
- Websites are too complicated these days.
- That complication is user requirements driven.
"UX drives all of this." | CSS-Tricks
This little Twitter exchange has stuck in my mind quite a bit. 1997: Let’s make a website!*fires up vi*2007: Let’s make a website!*downloads jQuery**fires
css-tricks.com
If you're willing to stick to jquery, life is still simple.
No one will invite you to speak at conferences though.
This comment is a rare example of a troll comment that's, in fact, true.
I'm even thinking of breaking my jquery dependency: it turns out the only things I'm using from are $.ajax and promises.
I can do a standalone implementation of those things in about 200 lines of code. More savings!
Before npm and build tools you pretty much had to use a big framework. There were few to choose from as these things have a lot of momentum.
React was the gateway for me, the model is a huge improvement over what came before. JSX & ES6 are nice so you want the babel toolchain.
then you end up depending on things from npm, which are tiny dependencies that change frequently because they're all new, so it's a mess
It's the Cambrian Explosion of front-end development. All hot and messy. Then, extinction and survival of the fittest.
Or the "emergent design" that arises in the absence of a decent architect. #differentworldviews #modernvspostmodern
is that so? i would think that would apply more to people forgoing frameworks in favor of vanilla js
Because nobody does a serious DDD analysis of the UI so we have lame "architectures" like MVC and MVVM....
It's fair, but I think other ecosystems like .Net have similar levels of complexity that is less visible. LINQ/lodash, WPF/angular, ASP/node
I was chopping images and gluing them together in tables like a psychopath in 1998. it has always been this way :)
imagemaps were simply never allowed to go full-flower
Here are some kinds of platform that are terrifying and have rarely been done well, even in isolation: UI, animated graphics, page layout...
...now imagine having to deliver all those eldritch horrors at once, on a pseudo-platform API that you don't control, in a terrible language
It has never once been done well, it's a miracle it even works, no-one uses even 50% of the features...but everyone chooses a unique subset.
In the immortal words of GIR, youtu.be/hLH8F2xDU90 :)
YAY WE'RE DOOMED
mfw usa's federal government
youtube.com
The worst part is, I'm absolutely certain that if I had been in charge of web platform policy since the late 90s, we'd be even worse off. :)
It's because it now handles business logic and needs to perform well. That's still not easy
GUI programs are complex, browser support(think es6), no standard library for js hence different ways of solving the same problem, and so on
because front-end now covers everything from CSS'ing a mom and pop shop's WordPress site to Electron-ing what was previous a native app.
Compared to 1999 static pages — it is, but compared to other contemporary application platforms (AKA "native"), it's quite okay.
I think the problem is that the browser was fundamentally never designed to be used this way. No module loader much less dep mgmt. Globals.
Bolting these (and worse reactivity) on this base is taking time and birthing painfully.
We all wish the situation were better so we glom onto the next marginal improvement, only to all hit the next unforseen design flaw.
In a perfect world so much of this would be provided by the platform and I think in the end it will.
But for now we lurch from solution to solution as the ecosystem decides slowly what the future will ultimately be.
The cause for sprawl? Many people have many different ideas about the correct approach for building UIs
The reason for moving more interaction client-side was that native mobile app development made users demand richer experiences
People have tried to attack complexity at three levels: declarative UI libraries, new platform-level apis, and new language features
There's really only one useful language-level feature that's come out of this, and that's a proper module system
Everything else — promises, generators, classes, etc — is largely syntactic sugar
A proper module system enables better libraries, consistent tooling, more re-use, shared interfaces, shared abstractions
But! The web platform moves slowly, so we have many people building tooling, all with slightly different philosophies, to polyfill modules
Just now the web platform is shipping these language-level features natively, and so tooling is beginning to standardize
But for five years or so, the teams behind Ember, Angular, React, etc have been inventing this tooling. And they didn't always get it right!
They all fit slightly different philosophies about how to build a complex, highly stateful, and richly interactive UI
But the one thing they all have in common is that they present a more declarative model of building a page
Gone are the days of manually manipulating the DOM, keeping track of what's changed and how to change it
But they used all of those additional, presumptive new language features to get there
So a newcomer's head spins when trying to approach this mess, wondering which parts of the languages they need to learn
And stripping that away, discovering the essential differences and trade offs of these new frameworks
There is hope though — lots of languages go though periods of expansion and standardization. Eventually people learn what works
And they remove cruft from their libraries, and authors combine efforts, and eventually there's idiomatic and approachable convergence
I can't think of any platform that needs to serve more people and more different use cases than the web
I think markets tell middle management that, and middle management tells developers in turn
Personally I worship in the church of server-rendered HTML and progressive enhancement
But I do ask myself often: what's the best way of building a big string?
it's easier to mansplain complicated ux as powerful and put failures on the shoulders of end users then to just make it work well and simply
It is settling... I think the core of the stack will be React + Typescript for a while. Might take a few more revs on the toolchain tho.
Also, it used to be a lot worse. Dependency management, css styling and browser consistency is all way better than it used to be.
The web is maturing abd we’re building bigger things with the knowledge of having built big things before, so we’re planning for end game.
Of course, that makes everyone feel they should plan for that end game, when maybe all we really need is CSS minification.
We just figured out how development is done right 😉
As a 30yo webdev, I decided I needed to move to backend dev. I'm not going to be 45 and want to learn a new JS thing every 4 weeks.
Big co's building tools to solve problems at their scale. Halo effect+OSS distr/transparency means med- and long-tail are exploring them too
+ some apps set expectations that everyone else copies. SPA and all that. Forces devs to contend with distributed systems (client<>server)
2017 - billions of users, million variations of screens, tens of possible interaction points. And everybody wants their unique experience.
Yes, fair. The short answer is premature optimization.
The razzle-dazzle of over-engineered code... glad to see you adding voice to the growing concerns about the FEDev culture... thank you!
It's hard, guys, but how many industries openly share their trade secrets and keep catalogs of best/worst practice?
People like to overcomplicate things. It's frustrating.
Hah I wish! I'm starting to think it's a human condition. Do things the hardest way possible.
It's similar on the design side in terms of tools. We're in a period of tool fragmentation following big changes in digital design/products.
But I can see things starting to become a bit more cohesive. Exciting times are always paired with a bit of frustrating entropy ;)
JavaScript lacked constructs necessary to write applications. Without modules and includes developers were forced to make their own
Add to this mix performance constraints of both bandwidth and rendering and you have a very real and complex set of problems to solve
Now sprinkle on top the fact that no one really likes the language itself so they want to "fix" it as well
Welcome to Coffee Talk. Discuss amongst yourselves.
Precompilation went mainstream. It started with Browserify giving access to ~100k Node packages on npm, then ended with Babel, Webpack, etc.
I'd submit that the perception of "frontend is getting too complicated" correlates well with the growth of npm: modulecounts.com
Arguably started with coffescript
Welcome to thunderdome
25 years of complexity caused by multiple browsers and cultural inertia. Very few platforms can be elegantly improved forever.
Too many ways of achieving the same result.
In a lot of cases it's because complexity moved from the back end to the front... in the worst case scenario it was only partially moved.
So templates generated on the backend are then taken over by angular in front end. Same complexity, in two places.
Worst of both worlds when you don't really commit to a client side app or anthropomorphic but try to generate it two ways.
Add to that, dev toolchains are crap for front end because you develop front end differently. So it all had to be reinvented. It's a WIP.
IMO when we sort out the fe toolchains, much will improve. But that said, folks' expectation that it should be simple is part of the problem
Users keep wanting shinier, faster interfaces for their web apps.
That's what App Store stats say. To new non-tech users, there's no distinction between web and native.
Outside observer myself, but I think I can answer this by asking you to answer a question…
If you could fill in, "I wish developing UI for the web were as easy as developing UI for ______", I think you'll have your answer
"I wish developing UI for the web were as easy as developing UI for the web used to be"
I'm looking at the fact that we went from React.js to React Native and wondering if you're not a little nostalgic?
Web used to be "easy" because you could only have one column of it, iirc
Admittedly, the decision to make everything in CSS a global was likely a huge problem factor
I've never used React anything so I'm not sure what your point is here.
Hmm… fair enough. The general point was that UI development overall has been difficult, not just on the web
The existence of Electron, too, implies that cross-platform app development is hard enough that using JS isn't stupid
To summarize, I hypothesize that almost all UI development has been undervalued since we've begun programming
"Why do you need a GUI? The CLI is so easy to use"
*invokes it with --help, gets 29 screefuls of flags*
Because technology has blossomed in #JavaScript. We are making crazy strides in compilation, build chains, and tooling. Maybe a side-effect?
It's happening because people equate complexity with proficiency, smartness, professionalism.
Turns out on-demand, offline, real-time, intractable in less than 5s on 3G and commodity mobile devices is complex work...
Also turns out frontend developers have trouble identifying whether or not they need to do all that.
haha. well, it's definitely mine now 😅
I think it's a discipline problem. I think most teams would do better to tune the hype out until it becomes more "tractable"
OH MY GOD YES
I've been doing web stuff since 1993 and I'm completely lost these days.
(It's not entirely the tech, it's me, too, but still.)
It is just you, the only thing Pathological these days is Javascript server side #Nodejs
Front end frameworks have increased the number of clean and streamlined APIs server side
I blame Javascript. If "copy and paste" works very well for a language, it will be chaotic, like PHP and Java
Because bad engineering leads to fractal complexity.