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.
This is funny because waiting for typescript to build is probably double or even triple waiting for my .NET project to compile at this point. I swear it gets slower every update.
Any app that grows to a certain size will slow down to a crawl on incremental builds.
https://raw.githubusercontent.com/evanw/esbuild/master/image...
But I will try!
Naturally I am not doing SPAs in this case, just vanilla JS and web components.
The FE/BE split builds are only in SPA projects, with BE being mostly about WebAPIs.
This is a shocking argument coming from any front end dev. Since when is static type checking, working on serious big repositories that take time to compile, have proper architecture with hundreds if not thousands of programmers working on it comparable to 3 frontend folks working on a web application? There is so much wrong with this argument and haven't scratched the surface.
These days front end engineering can be every bit as rigorous and complex as back end engineering. The constraints are a bit different, and the environments are very different, but the scale and complexity of engineering is not.
The vast majority of front-end development outside of that world is misguidedly trying to mimic that complexity on their static business informational page they maintain with a duct taped mess of bad practices everywhere.
Now if you take a look at development outside of front-end and go to some large non-tech, mid-sized, or small business you'll probably also find poor practices (from my experience), but nothing like the mess I see in these same organizations trying front-end development now.
People on HN talk about React and friends because they’re building client-side apps that deserve full frameworks. But it’s absolutely not representative of most web development.
Compare the simplicity of jQuery vs a modern tool chain. Like creating a form. It gets pretty insane with React. And jQuery would be dead simple.
You have to stay on the bandwagon because it’s where the community is now. There’s certainly a lot more fun to be had remaking everything in React though.
I'm mainly a backend developer so can't comment on how this tradeoff works out when you have the resources for artistic UI/UX folks and reduced development pace.
A good example is React Native which is less about React but more about a js interop layer with Cocoa that happens to use React for the rendering.
My side project is a web app that lets you create music visualizer videos. There’s a ton of UI, state, complex interaction between parts, etc. If I weren’t using React, I’d be using something — but it would surely be another full-on framework, not a simple library like jQuery.
Certainly, as I am finding out. Can you suggest some solid, robust frontend framework that doesn't break in 3 months when I update the dependencies?
Give Svelte a try online, their tutorial page is pretty slick: https://svelte.dev/tutorial/basics
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.
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.
This is precisely my fear [1]. I need something robust and will continue to work for a good foreseeable future.
Do you recommend Angular for frontend? I've just tried React and Svelte, but I am told to stay away from Angular as a giant beast.
It's fantastic for large applications. I've used it in a large product with hundreds of pages and forms and dialogs, and it would have been a nightmare without the sort of structure that Angular provides. It reminds me of Rails a little bit, in that it's opinionated about how things should work and you might feel some friction if you try to do something unusual.
I honestly don't agree for Ember at least. Enterprise development is prone to having apps untouched for years and once an Ember application gets that out of date, the route to getting it in date again is... difficult. Have seen with with applications on 1betaX versions, 1.13, 2.14 and no route forward without significant rework, which means they're largely incompatible with the ecosystem now.
The package-lock.json file and the `npm ci` command should take care of any issues like that nowadays. Yarn has also always had its lock file. I wonder what was the root cause here? Did your repo have some deps coming from some other registry than npmjs.com?
I’ve never even considered going to YouTube, of all places, for JavaScript documentation. What’s next, people reacting to JavaScript programming?
> 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.
Took me 2 hours to just to find out that some module wasn't compatible with Node version 15.
That said, node versioning has caused me a lot of stress over the last few years. Not sure if that's to do with the use of LTS specifically though.
I forgot about Unity. Yes, Unity is another offender here. One of the many reasons I quit working with it.
> "another offender"
Be careful, it's a nasty fall off that high horse.
and re. these earlier remarks:
> Windows and Mac OS
Windows and Mac OS most definitely have experimental/preview releases and standard releases. Microsoft offer extended support options, and ultra-marathon ESU contract support for products as far back as Windows Server 2008.
Same goes for most commercial RDBMS. Heck, even Oracle has a preview release.
> anything outside of Linux or Node
Linux stopped using alternating version numbers in 2004, so I'm afraid your information there has passed even Microsoft's extended support period. For the curious, though, GNOME still uses the even/odd versioning as a lifecycle indicator, but has plans to abandon it this year. I hope Node will do the same, because of all the numbering styles this is certainly the most confusing.
As for Java, only a dyed-in-the-wool government bureaucrat could possibly love Java's approach to ecosystem engagement. "Let's have seven years of committee meetings and experimental feature flags for the new GC". Ugh.
Standing back, this just sounds like a grumble about terminology, because almost _everyone_ has some kind of leading-edge release and some kind of stable release, the only difference is the naming, and that doesn't seem to me the basis of a substantial complaint. If the core issue is inconsistencies about which one is installed by default, then that is a complaint I'd suggest best leveled at package managers, because there is no universe available in which every software project is going to somehow magically converge on a single lifecycle policy.
It's exactly the lack of label on non-LTS versions I'm talking about. It has a real impact on people, looking at which version to install, and having no guidance that "this version not labeled in any special way, yeah, probably don't use that". And no, digging into the developer mailing list to figure out what the versioning malarkey a particular project is using is not a documentation of it.
What's more, this gripe alone won't solve anything, since no-one is going to conform to anyone's expectations but their own in regards to release policy.
There is some hope though, recent standards like web components and ES imports help a bit.
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
Next time I build a team, I might consciously choose a mix of stable experienced senior devs, and perhaps a couple of young ignorant-but-brave junior devs. Horses for courses.
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.
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.
You don't even need jQuery these days. All the important functionality is now in the DOM by default.
React reference documentation?
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