I’ve been doing web FE in various capacities for about a decade. First jQuery, then backbone, then Angular, then ClojureScript with React, now React and Apollo.
While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes.
Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React addressed state complexity, and GraphQL finally forced backend engineering to coordinate with frontend engineering (i.e., making full-stack engineering efficient).
People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity.
What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real.
Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.
> GraphQL finally forced backend engineering to coordinate with frontend engineering
I'm curious what do you mean here? The way I see it is the exact opposite - front-end making new kind of queries without having to coordinate with backend. With positive effects (faster results) and negative ones (so this new query takes a minute to resolve and it's in production - fix it now!)
> People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity.
This is sometimes true, but not always.
For example, it's also sometimes true that teams switch to technology X because X has become popular, and without necessarily understanding the benefits and drawbacks. In some cases a choice is made to switch to X because whatever the team is currently using is "dead"/has gone unsupported.
I think these reasons, along with others such as significant breaking changes between major versions that we've seen with some frameworks and libraries, better hint at sources of frustration over "churn" in JavaScript.
While I think it's important to fight against the "FE is easy; BE is real programming" stigma, I think you're going bit too much in the other direction. You're painting FE almost as the most difficult thing that exists. However, it's not like GUI applications is a new thing. GUI applications which talks to the Internet is not exactly groundbreaking either.
> Updating a user’s role on the BE is a single SQL operation
Exactly! Updating a user's role on the BE is actually a really difficult task: You need to persist the data in a safe way and ensure that it's consistent with other concurrent actions that happens. These hard problems have been worked on for 50 years and what we've ended up with is a set of solid tools (SQL databases that provides transactions). It's thanks to these tools that BE becomes easy. These tools have also been built on top of each other. A new tool often "extends" an older tool instead of "replacing" it.
It comparison, look at some of the "progress" in the tooling in the front-end world: One of the biggest recent change in state management is React Hooks. This is a concept which has zero precedence in any language or literature. It's something they invented out of thin air and behaves like nothing else out there. The documentation has a big list of gotchas you need to watch out for. Does it has its advantages? Sure, it's nice for many things. But of course there's going to be rough edges when introducing such novel concepts.
Cocoa has been successfully using view controllers for state management for 20 years (or more?). They've made some tweaks over the years (e.g. segues), but it's mainly stayed the same. Is state management perfect in Cocoa? No. Do you hear Cocoa developers complain about state management? Yes. Do they spend every year talking about the "new best way to handle state"? Nope.
I understand that it's not completely comparable (different platforms etc), but of course state management becomes a recurring problem when you end up switching out the state management library every second year (Redux anyone?).
My personal criticism of the web FE community is not that the tools haven’t solved problems, it’s that these problems have been solved before and that is not acknowledged.
For example, a single-page app is the exact same thing as a native frontend. It’s a stateful, long-running process that communicates with a backend. This is not a new paradigm, but it is treated as one in the web community.
Another example is declarative UI. Microsoft had XAML and data binding well before Backbone, Angular, and React.
I personally love where web UI is at today, but I get the sense that we think it’s full of these unique problems when it’s really not.
Agreed. It becomes really messy moving all that state around.
Still in its infancy but we’ve settled on a model where we use Hasura to sync the whole datastore to the frontend as a mobx graph. It’s relatively easy to then drive the frontend off layers of computations on that graph. We’ve also put a transaction layer on mutations of the models so they’re automatically batched and sent as a single request / dB transactions.
It’s liberating to get to a place where I can just update models in the frontend and have that reflected everywhere because, as you point out, there’s enough to coordinate in all the bits you have to mutate.
Edit: we borrowed the idea from how linear.app does it
This is the biggest problem I have with being paid for front end development. In the corporate world the only focus is on the tools and how to write code. Thoughts of product development and product quality are almost exclusively absent.
That is so incredibly frustrating. As a paid professional you would hope your people know how to write code (do their jobs) and churn out original solutions to new problems. Instead it feels like being in a preschool learning to read and being ecstatic that anything gets released.
It's pretty clear that we're in a period of relative stability. React and TypeScript have been the tools of choice for 2-3 years now. Webpack is the clear choice in bundler. Most people seem to be using the modern language features.
You can see that the number of extremely satisfied or dissatisfied people has gone down, people have moved towards the middle as the big tools have matured.
It's nice. I feel like I actually get the JS landscape right now (I'm a Vue person but still).
I'm sure in 2 more years everything will blow up again though!
I would like to think that the next big change will be the slow but steady replacement of JS/TS by one or more much better languages. Even with the current relative calm in front end web development, JS is still a terrible language for almost everything that matters. TS is a noble effort to put lipstick on a pig that achieves some useful benefits, but only at the expense of adding even more complexity, a sometimes clumsy syntax because of the JS legacy, and an illusion of being safer than it actually is again because the decision to favour JS compatibility means you can break the type system.
Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
Every time Javascript is discussed, the discussion turns negative. Fact of life is that the browser is THE cross platform app, and people have differing opinions on how things should be done.
As someone who is relatively outside of the JavaScript ecosystem, I had the following realization yesterday when I was reviewing this: JavaScript has what I would consider two distinct flavors of "back-end" frameworks.
It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendered content as HTML, API responses as JSON or other forms, etc.
And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework.
Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript?
Every year I see these reports come out and every year I'm more jealous of JavaScript/front end developers. I know the landscape is complicated and hard to keep up with, but damn it's just so cool the possibilities you guys have.
I am comfortable with c/c++/python/sql/java in an enterprise context. Might some folks help me get back into the JS world? Do I need to sit down with a JavaScript 1.0 book and go from there?
Vue is the 3rd in framework ranks... and like the 16th ranked?
"Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice.
It seems like the overall trend is that people are getting more and more unsatisfied with the current landscape now that a little bit of the sugar high from first wave of shiny new tech is starting to fade away.
The jump from "whatever js was in 2014" -> angularjs junk -> react/vue/angular was pretty big.
But now the glamour is gone and we're moving into the phase of actually having to maintain some of the things we built and the wear from bad decisions is starting to show.
-----
Svelte also seems like the cool new kid on the block. Svelte surprises me in how much people fawn over it. I really don't understand the hype since I don't think it's a huge jump forward, and there's also a lot of "misunderstandings" about it in comparison to other frameworks.
Like one thing I've seen a lot is people mention how it requires less code, but it's not that much smaller. It just looks smaller for small test cases where there are like 8 lines of code or because svelte makes stylistic choices that have tradeoffs that aren't immediately obvious. If you take a loot at react/vue, they're not that much bigger for realistic component size.
Anyways, front-end framework discussion is long and muddled and confusing. I wanted to make a point of how svelte people often confuse the engineering/implementation vs the philosophical approach in frameworks. Things like svelte's bundle size being smaller is because other frameworks don't put as much emphasis on it. I was going to say that react is bloated and that preact is much smaller, but looking it up it seems like somehow react is 2.6kb, preact is 4kb, and svelte is 1.5kb. Angular is 62kb. Which proves two points, react/vue can be smaller if it wants, the approach it takes doesn't limit it and that things move so fast that somehow preact makes bigger bundles than react.
If I were trying to compare technologies I might focus on metrics like release strategy, documentation quality, scale of existing products using it, and maintainer activity.
This survey comes out every year and tells me who is winning the social media popularity contest. Technologies labeled as "Avoid" have over 50% respondents saying they don't even use the technology. Avoid it why? Because I won't be trendy at the javascript meetup? Does anyone actually use this data to drive decisions?
Cliche rant coming up: as a backend engineer, recently started working on frontend. Is this how yall do things? Everything so far feels less mature, thinly pieced together, barely holding up, fast moving, unnecessarily bloated, and no care for longevity, robustness and discipline. Seems like every thing is on Youtube, no real good books (yeah, go ahead and search for "React JS" books on Amazon and see if you find something solid that is well praised). It's these 8 hour fucking Youtube videos that I need to watch and probably not remember anything. I watched one of those and its horrifying what kind of stuff these people are teaching. I am obviously generalizing, sure there are some really smart people involved in Frontend tech, but boy if you take a sweeping look from ten thousand feet, it ain't pretty.
Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this?
I've worked in front end and backend systems. I've worked with extremely high scale web services at FAANG. I've made videogames, and done data processing pipelines.
In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
I think the important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.
Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k.
That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions.
Javascript tooling is crazy. A couple years ago I tried to build an older Ionic app that nobody had touched for six months, and the build had just bitrotted. Something somewhere in the dependencies hadn't been screwed down tightly enough, and everything was broken.
I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west.
There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting.
I disagree strongly about browsers; having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.
The situation with Clojure/ClojureScript is a lot more stable. Most libraries are pretty rigorous about backwards-compatibility. When someone comes up with a better approach, they release it as a new library under a different name instead of making breaking changes to the old one. You will probably still need to pull in some npm packages, but you can cherry pick those and keep it to a manageable number.
Unfortunately yes. In all my four decades in tech, code bitrots in the the web front-end environment faster than any other I've yet seen. The Javascript language in particular (and its ecosystem) remains a baroque Gormenghast of curiosities built on an ancient sewer where nightmare beasts still roam, and everyone's holed up in the throne room hoping a few trusted paladins will somehow decontaminate the rest.
> How do we get out of this?
Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like.
When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.
I work front and back end, I've seen frontend done the "simple" way but not often. The syndrome I'm observing is that guys are chasing the next thing so they can bump up to a better paying job, and nobody is ever worried about maintaining their flaming pile of garbage long-term. When new guys come in to find someone else's trash code, they always need to rewrite it in the new thing. It's really no that hard to use modern tools tastefully and with restraint, but it's so rare to see.
I consider myself to traditionally be a backend engineer, though this has more been something I fell into rather than chose.
I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS.
Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air.
If you do decide to have a look I found the examples [1] and getting started guide [2] very informative.
I think it's about individual maturity than tech-stack. Frontenders are likely to be younger than backenders, and some of the traits you observed are a result of that.
How is JS and it’s ecosystem any less mature than Go or Rust? There’s a plethora of mature frameworks, build tooling and patterns on the frontend as well as a lot of cutting edge competition that creates a lot of noise.
The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.
Do you remember when you could rent a physical machine somewhere and have something running in 5 minutes? We moved to something more verbose to support the new volume of the internet.
The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android.
You can get out of this by using jQuery. It still works.
I can't make any promises, but many js engineers have found that clojurescript together with a framework like re-frame seems to offer a different mental model they find useful
I think at its core, the issue is that the code has to run in many different types of hostile environments. At least now we can sort of assume what features of the language are available, but you still have no control over the browser, OS, memory, or bandwidth available. There's no getting out of it :)
Sure, there are a lot of warts. But it feels less mature because it is less mature. Consider that you’re coming from a domain that’s three decades old into one that really only started gaining steam in the 2010s.
Svelte is pretty cool. I‘ve only used it for a small app so far but it was very easy and quick to work with. I don‘t know how well it will scale for larger and more complex apps though.
It makes a little more sense when you consider the wider graphql ecosystem, like Apollo or Relay, which normalize all data received and keep your UI up to date automatically. In that light, graphql-the-ecosystem has solved a big part of frontend state management. With graphql and react hooks, I have found no need for redux anymore for typical CRUD needs.
I hate TypeScript so much. It feels so antithetical to the web, produces so much redundant bloat to solve a problem that maybe appears for some of the apps with huge codebases, and fails horribly with its obscure error messages.
Many many moons ago I wrote C and C++, typed languages right? I don’t remember typing my code being so abstract and complicated.
Take php 7+, has good typing features and is way, way easier to understand.
All I want is native js interfaces, namespaces and basic types, then F### typescript :)
Seriously somtimes as nerds we like something because its complicated and presses our dopamine buttons when we figure it out, but then what is the practical outcome?
Problem is there seems to be no middle point? I can’t write vanilla js now on new project, typing structures like json messages is bare minimum.
The problem with Ts is even if you don’t want to use it "like an expert" there is no beginner use, you will very quickly run into complicated abstractions and all kind of typescript errors due to fluidity of js language.
So I think native js typings is our only hope but when you see how crappy some vanilla js syntax is, what they did with classes, I’m not holding my hopes up.
As BE, I was surprised how many FE developers use PWA. I need to take a look at this technology.
By the way, I am happy that the usage of typescript increases over time.
A large mistake in React's history is definitely it's history with redux and any API like it. You can see that it's very quickly being shed away from React in these charts which I'm very happy about. Redux is like a global variable and it's painful and clumsy.
If the healthcare sector would apply the same ideas and principles of the front-end industry, it'd look like this: oh,look, it's a pen! Why don't we combine it with a scalpel and an angle grinder for our next surgery?
Front-end is an absolute shit show with all the html/css/js mixture.
[+] [-] wildermuthn|5 years ago|reply
While I get the criticism about what might seem like an anarchic state of JavaScript, at each transition point there have been clear, demonstrable, and worthwhile changes.
Backbone addressed jQuery spaghetti code. Angular addressed backbone boilerplate. React addressed state complexity, and GraphQL finally forced backend engineering to coordinate with frontend engineering (i.e., making full-stack engineering efficient).
People don’t switch tooling and frameworks for fun (well, not primarily), but because the pain of learning something new is worth the benefit of reducing unnecessary complexity.
What I don’t think non-FE engineers often appreciate is just how essentially complex user-dictated mutable state is. Even with immutable data structures (which I love), you can’t get around the fact that a web-app is, by its very nature, a canvas that changes according to human activity. The difference between FE and BE is the difference between painting with fingers and flipping a switch with fingers. Updating a user’s role on the BE is a single SQL operation, but for the FE, it might mean countless changes to the user experience. It’s the difference between storing data and using data. And if there’s anything to conclude from the overwhelming amount of work done on FE tooling, it’s not that people love to try new things (although we do), it’s that the struggle is real.
Side-note: BE gets a taste of FE complexity when dealing with syncing live mutable data among multiple clients. That’s a beast, and the point where everyone realizes that full-stack is the only sensible way to work.
[+] [-] viraptor|5 years ago|reply
I'm curious what do you mean here? The way I see it is the exact opposite - front-end making new kind of queries without having to coordinate with backend. With positive effects (faster results) and negative ones (so this new query takes a minute to resolve and it's in production - fix it now!)
[+] [-] bartread|5 years ago|reply
This is sometimes true, but not always.
For example, it's also sometimes true that teams switch to technology X because X has become popular, and without necessarily understanding the benefits and drawbacks. In some cases a choice is made to switch to X because whatever the team is currently using is "dead"/has gone unsupported.
I think these reasons, along with others such as significant breaking changes between major versions that we've seen with some frameworks and libraries, better hint at sources of frustration over "churn" in JavaScript.
[+] [-] judofyr|5 years ago|reply
> Updating a user’s role on the BE is a single SQL operation
Exactly! Updating a user's role on the BE is actually a really difficult task: You need to persist the data in a safe way and ensure that it's consistent with other concurrent actions that happens. These hard problems have been worked on for 50 years and what we've ended up with is a set of solid tools (SQL databases that provides transactions). It's thanks to these tools that BE becomes easy. These tools have also been built on top of each other. A new tool often "extends" an older tool instead of "replacing" it.
It comparison, look at some of the "progress" in the tooling in the front-end world: One of the biggest recent change in state management is React Hooks. This is a concept which has zero precedence in any language or literature. It's something they invented out of thin air and behaves like nothing else out there. The documentation has a big list of gotchas you need to watch out for. Does it has its advantages? Sure, it's nice for many things. But of course there's going to be rough edges when introducing such novel concepts.
Cocoa has been successfully using view controllers for state management for 20 years (or more?). They've made some tweaks over the years (e.g. segues), but it's mainly stayed the same. Is state management perfect in Cocoa? No. Do you hear Cocoa developers complain about state management? Yes. Do they spend every year talking about the "new best way to handle state"? Nope.
I understand that it's not completely comparable (different platforms etc), but of course state management becomes a recurring problem when you end up switching out the state management library every second year (Redux anyone?).
[+] [-] amw-zero|5 years ago|reply
For example, a single-page app is the exact same thing as a native frontend. It’s a stateful, long-running process that communicates with a backend. This is not a new paradigm, but it is treated as one in the web community.
Another example is declarative UI. Microsoft had XAML and data binding well before Backbone, Angular, and React.
I personally love where web UI is at today, but I get the sense that we think it’s full of these unique problems when it’s really not.
[+] [-] aidos|5 years ago|reply
Still in its infancy but we’ve settled on a model where we use Hasura to sync the whole datastore to the frontend as a mobx graph. It’s relatively easy to then drive the frontend off layers of computations on that graph. We’ve also put a transaction layer on mutations of the models so they’re automatically batched and sent as a single request / dB transactions.
It’s liberating to get to a place where I can just update models in the frontend and have that reflected everywhere because, as you point out, there’s enough to coordinate in all the bits you have to mutate.
Edit: we borrowed the idea from how linear.app does it
[+] [-] samblr|5 years ago|reply
"Next.js is amongst the top backend framework" - Anybody can tell its popular for frontend!
[+] [-] austincheney|5 years ago|reply
That is so incredibly frustrating. As a paid professional you would hope your people know how to write code (do their jobs) and churn out original solutions to new problems. Instead it feels like being in a preschool learning to read and being ecstatic that anything gets released.
[+] [-] habosa|5 years ago|reply
You can see that the number of extremely satisfied or dissatisfied people has gone down, people have moved towards the middle as the big tools have matured.
It's nice. I feel like I actually get the JS landscape right now (I'm a Vue person but still).
I'm sure in 2 more years everything will blow up again though!
[+] [-] ballenf|5 years ago|reply
[+] [-] Silhouette|5 years ago|reply
Momentum is a huge factor in programming language popularity, which unfortunately tends to hold back real progress, sometimes for decades. That's why we still write front end code in JS, and why we still write systems code in C. But with the progress of WASM, I think there is a genuine opportunity to create something so much better than JS (or anything that compiles to JS) that it might eventually take over, even if it takes more like 2 decades than 2 years to achieve success.
[+] [-] milkers|5 years ago|reply
- Typescript keeps strengthening its position as industry standard.
- Svelte is hyped, but is it battle tested enough?
- Testing Library is quite new in the town but already the runner up testing tool.
- In terms of data management, GraphQL holds its position on the top while good-ol Redux kept losing interest.
What are yours?
[+] [-] turtlebits|5 years ago|reply
[+] [-] bhauer|5 years ago|reply
It has frameworks like Express and Koa, which I would consider traditional back-end frameworks. These are designed around handling HTTP requests and providing dynamic responses in myriad forms: rendered content as HTML, API responses as JSON or other forms, etc.
And then there are what I would call back-ported front-end frameworks, or semi-static site hosts. These are Next.js and Nuxt. As far as I can tell, these can be used to build traditional server-side application logic but they seem intended to host "pages." For example, in looking over Next, I see it does have the ability to expose API routes, but this seems very much a second-class citizen. The Next documentation [1] says "Next.js has support for API Routes, which let you easily create an API endpoint as a Node.js serverless function." This seems to be provided as an escape hatch, but it doesn't appear to be the core focus of the framework.
Is this distinction real or am I sadly misinformed of the, ahem, state of JavaScript?
[1] https://nextjs.org/learn/basics/api-routes
[+] [-] theshadowknows|5 years ago|reply
I am comfortable with c/c++/python/sql/java in an enterprise context. Might some folks help me get back into the JS world? Do I need to sit down with a JavaScript 1.0 book and go from there?
[+] [-] ehutch79|5 years ago|reply
"Testing Library" is the top testing library apparently? Had to check that this was an actual library, I'm sure many people just left it as a 'whatever' choice.
Someones data is dirty dirty dirty
[+] [-] preommr|5 years ago|reply
The jump from "whatever js was in 2014" -> angularjs junk -> react/vue/angular was pretty big.
But now the glamour is gone and we're moving into the phase of actually having to maintain some of the things we built and the wear from bad decisions is starting to show.
-----
Svelte also seems like the cool new kid on the block. Svelte surprises me in how much people fawn over it. I really don't understand the hype since I don't think it's a huge jump forward, and there's also a lot of "misunderstandings" about it in comparison to other frameworks.
Like one thing I've seen a lot is people mention how it requires less code, but it's not that much smaller. It just looks smaller for small test cases where there are like 8 lines of code or because svelte makes stylistic choices that have tradeoffs that aren't immediately obvious. If you take a loot at react/vue, they're not that much bigger for realistic component size.
Anyways, front-end framework discussion is long and muddled and confusing. I wanted to make a point of how svelte people often confuse the engineering/implementation vs the philosophical approach in frameworks. Things like svelte's bundle size being smaller is because other frameworks don't put as much emphasis on it. I was going to say that react is bloated and that preact is much smaller, but looking it up it seems like somehow react is 2.6kb, preact is 4kb, and svelte is 1.5kb. Angular is 62kb. Which proves two points, react/vue can be smaller if it wants, the approach it takes doesn't limit it and that things move so fast that somehow preact makes bigger bundles than react.
[+] [-] somehnrdr14726|5 years ago|reply
This survey comes out every year and tells me who is winning the social media popularity contest. Technologies labeled as "Avoid" have over 50% respondents saying they don't even use the technology. Avoid it why? Because I won't be trendy at the javascript meetup? Does anyone actually use this data to drive decisions?
[+] [-] systemvoltage|5 years ago|reply
Well, first reaction for most people would be I am offended by this. But, I am speaking from the heart. This is exactly how I bloody feel, change my mind. The entire frontend ecosystem including browsers and the horrible mess that html/css/js is needs to be redone properly from scratch. Unfortunately, we can't because we've dug ourselves deep into this hole. How do we get out of this?
/rant
[+] [-] Pfhreak|5 years ago|reply
In general, I find that people will look at the domain outside of their area of expertise and say, "Holy shit, how do you work like this?" All the front end devs are like, "You have to wait how many minutes for compile times?" for instance.
I think the important thing to remember is that engineers are doing complex engineering at every layer of the stack. And that because of environment and targets they are building for, they've made some tradeoffs around their development.
[+] [-] mobilio|5 years ago|reply
But JS is outstanding on this mess: https://httparchive.org/reports/state-of-javascript
Please note that this is transfer size. So if some script like jQuery 1.X is 90kb minified, but compressed is like 30k.
That's why we shouldn't asking ourselves why some users using a 3rd party tools to disable trackers, ads (like PiHole) or even disable JS using browser extensions.
And now good news... this time Google. Google are making Core Web Vitals: https://web.dev/vitals/ trying to evaluate sites using CrUX RUM. And soon they will this will be included in ranking algorithm: https://developers.google.com/search/blog/2020/11/timing-for...
This announce make most of webmasters freaking out about web speed finally.
[+] [-] jamesgeck0|5 years ago|reply
I feel like the Yarn 2 package manager is a good move towards in making frontend development more stable (The "Plug'n'Play" feature allows you to store your dependencies in your repo as zip files, just in case), but a lot of libraries are still the wild west.
There are "boring" frameworks like Ember and Angular that move slowly and limit breakage, but they're pretty unpopular with many developers, despite being great for building products in an enterprise setting.
I disagree strongly about browsers; having an extremely stable platform that never breaks backwards compatibility is exactly what the web needs to be. Frontend development tooling would be so much better if it was more like browsers.
[+] [-] john-shaffer|5 years ago|reply
[+] [-] mr_toad|5 years ago|reply
I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
[+] [-] inopinatus|5 years ago|reply
> How do we get out of this?
Personally, I try to use as little JS as possible. CSS is in better shape and handles a ton of page-level behaviours, HTTP/2 has done wonders for round-trip responsiveness, such that server-rendered HTML still holds the productivity crown for building out MVPs and SaaS application interfaces and the like.
When I absolutely must write JS, I'll tend towards typescript these days, and minimise dependencies to the point where I hopefully have no node_modules/ or bundler at all.
[+] [-] kag0|5 years ago|reply
There is some hope though, recent standards like web components and ES imports help a bit.
[+] [-] potta_coffee|5 years ago|reply
[+] [-] _3sno|5 years ago|reply
I admit I feel I share some of your frustrations. In the past I have written production frontends in Angular and experimented with Vue and React. Out of all of them I found React to be the most enjoyable, but even then I still struggled with project setup and found the tooling confusing. I even quite like TS as a language, but I feel it's still quite limited by the fact it transpiles to JS.
Recently, I discovered yew [0]. It is a Rust framework for building frontends using wasm. I really appreciate the robustness that Rust brings such as ownership checks and ADTs. I don't think it's for everyone, but it may be worth looking at if you perhaps find modern frontend development confusing frustrating. I've found it to be quite the breath of fresh air.
If you do decide to have a look I found the examples [1] and getting started guide [2] very informative.
[0] https://github.com/yewstack/yew
[1] https://github.com/yewstack/yew/tree/master/examples
[2] https://yew.rs/docs/en/getting-started/project-setup
[+] [-] factorialboy|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] halfmatthalfcat|5 years ago|reply
The point is though that there’s just a lot going on in JS world. Doesn’t mean it’s any less than any other language and it’s ecosystem.
[+] [-] gerdesj|5 years ago|reply
[+] [-] olingern|5 years ago|reply
The same has happened on the front-end. I consider some front-ends, like Twitter’s, applications just as I do iOS or Android.
You can get out of this by using jQuery. It still works.
[+] [-] ghufran_syed|5 years ago|reply
https://day8.github.io/re-frame/
[+] [-] mattwad|5 years ago|reply
[+] [-] dboreham|5 years ago|reply
[+] [-] jakelazaroff|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] geonic|5 years ago|reply
[+] [-] kemitchell|5 years ago|reply
[+] [-] trylist|5 years ago|reply
[+] [-] hamandcheese|5 years ago|reply
[+] [-] nathias|5 years ago|reply
[+] [-] AltruisticGapHN|5 years ago|reply
Take php 7+, has good typing features and is way, way easier to understand.
All I want is native js interfaces, namespaces and basic types, then F### typescript :)
Seriously somtimes as nerds we like something because its complicated and presses our dopamine buttons when we figure it out, but then what is the practical outcome?
Problem is there seems to be no middle point? I can’t write vanilla js now on new project, typing structures like json messages is bare minimum.
The problem with Ts is even if you don’t want to use it "like an expert" there is no beginner use, you will very quickly run into complicated abstractions and all kind of typescript errors due to fluidity of js language.
So I think native js typings is our only hope but when you see how crappy some vanilla js syntax is, what they did with classes, I’m not holding my hopes up.
[+] [-] mcdoker18|5 years ago|reply
[+] [-] miohtama|5 years ago|reply
[+] [-] unknown|5 years ago|reply
[deleted]
[+] [-] rhacker|5 years ago|reply
[+] [-] cosmodisk|5 years ago|reply
Front-end is an absolute shit show with all the html/css/js mixture.
[+] [-] Aldipower|5 years ago|reply
[deleted]