> I don't want to learn nor use a million different tools.
As much rhetoric as there is about this being the frontend, the backend is worse. "Backend" is just defined as "anything that isn't the frontend" so the word casts a wide net. There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools.
That said, it's always good to have a variety of knowledge and experience. The backend is nice because it doesn't rely on visual output as much and so you can code more without context switching between the editor and the browser. And it's incredibly easy to get pigeonholed into writing frontend code only. So many companies seem to be unable to let go of the fact that you have some specialization.
It’s not necessarily worse but it could be as tangled and bad because of other reasons. The rapid pace in the evolution of Js frameworks created a lot more problems than on the back end IMO
Remember that JS is used in the backend too (Node.JS / Deno). But I agree, the situation there at least is moving slowly compared to the frontend world.
> marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide.
I’ve worked in frontend for five years and this has never been a thing that happened. If a framework is important to your marketing, that would be because your customers have to use it to interface with your product. The same would be true if your customers had to interact with your backend; they would want an API in popular languages, trendy languages and frameworks too.
I work in one of the big old industries and we commission web shops to build first versions of web apps that internal IT then takes over for maintenance and future iterations.
We have standardized on Angular on the frontend and require providers to use it. The backend tech is less critical, it can be one of Java, JS, or Python and the important point is a JSON/REST interface with Swagger documentation.
I thought the same a few years ago, when I moved to backend development. I don't feel like the backend was that different, in terms of setting up infrastructure.
In hindsight, I just didn't enjoy writing code for money. When I left my last programming job, I started programming for fun again. It wasn't a deliberate effort, but something that happened on its own.
If you program for fun, you don't have to learn anything. You don't have to use webpack or SCSS if you don't want to. You don't need to write tests. "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
My advice to anyone that starts off loving code: focus on maximizing your revenue, minimizing your cost, and be careful with your commitments. One day you will hate working with these damn machines, and it isn't the machine but everything else.
My target goal is to retire soon-ish, and I'll dick around with my own stupid programming language around board games: http://www.adama-lang.org/
I don't intend to rally stake-holders about it.
I fully expect to tinker on this for a decade without any love, and that's just fine with me.
I don't intend to defend my decisions, or justify why this thing exists.
The few backend devs I've talked to have agreed that the world spins a bit slower in the back-end side of things, without having weekly "chapter meetings" to discuss how the code we wrote last week is now obsolete. Backend devs are also much more versed in writing decent, performant code, to my experience - whereas the majority of front-end devs I've worked with have no idea why you should try to avoid writing loops in loops. But of course, everything can be bad, and it also varies from org to org, so here's to hoping my first back-end role won't suck because otherwise I'd be pretty sad.
When React and Angular became popular I realized with great sadness that I was no longer a full stack dev and that I would never ever be one again. There's a whole group of us at work. The young devs laugh at our front-end abilities but they also look up to us because of our ability to elegantly hide our loops within loops within loops, with Linq.
My last frontend job was a few years ago, but I'm still writing VueJS apps the same way I used to. I don't feel like anything has really changed since then. I just got better at using the same tools.
The only meaningful change from my perspective is that browsers can do more things.
Backend is nice because you have greater control over the environment, and because testing data flows is easier than testing user interfaces. However, I was not a big fan of devops and cloud stuff, which felt too abstract to me.
My work feels like 5% analysis, 5% writing algorithms, 20% writing boilerplate code, 70% integration with some complex ill-documented monstrosity and debugging.
You can still deploy stuff on a plain application server or whatever. The tools I've worked with haven't really required touching any kind of cluster management or other overhyped (albeit in some cases necessary) and complicated backend stuff if you didn't want to. (My backend experience is with Java and Python, though. I don't know how things are with other backend languages.)
When I started looking into putting together a simple but modern frontend in my own time after having done only backend for years, it seemed like there's quite a lot of tooling and associated complexity that you kind of have to deal with just to get your frontend deployed, whether you need a complex architecture or not.
> "bugger off" is a valid response to stakeholders.
Sometimes "bugger off" is a valid response to stakeholders, even in a professional context: you just have to know how to say it.
I really started to feel like, after three and a half years, I was succeeding the other day when one of my product managers told a stakeholder to bugger off and they did without even challenging it.
I think you've touched on something essential here. It may explain the continuous appeal of open source.
Maybe it also explains how even though work is perpetually exhausting, somehow I still find energy to work on side projects, just so I can feel some uninhibited creativity.
I'm also reminded of a cynical quote from my dad. When I was young I asked him "Was work fun?" to which he responded "If work was fun they wouldn't pay you."
I work for a company that mainly does custom enterprise intranet webapps. We mainly use PHP (7+), jQuery, jQuery UI, SSR templates and a really old orm (with custom patches). With all the shit these components usually get, it's been the most comfortable experience with web development I have ever had
What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.
The tech stack in front-end changes constantly because things change : new constrain (mobile), new possibilities (webrtc, WebWorkers), new expectations (people sometimes don't just want a document), new Frameworks that attempt to solve previous problems better (react), and new trends (material UI) that require not just a css change.
It's not perfect, but given how much the ground shifts below your feets constantly while you maintain your web app, I don't find the experience that bad.
Make an static html document if you need a document. Make backend code with a sprinkle of vanilla js if you make simple interactions. Use react if you need your app to evolve fast, do tons of things, and stay organised.
That's what I do for my project, ciboulette.net .
The marketing website is static and js free. The UI to pass an order is an express server, html pages with a sprinkle of js. The administration UI is react + meteorjs.
And it's fine, not perfect, but I don't feel like it's too much.
There isn't massive churn. As far as I can see, most of the JS ecosystem has been continually improving.
React has been around since 2013 [0], Webpack has been around since 2014 [1], etc.
If you're stuck in 2015, you're 5 years of updates and improvements behind.
The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much".
I mentioned this in another comment above but for anyone feeling this way which I think is entirely reasonable and healthy even there are two options I would point them towards both at totally different ends of the spectrum.
The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end.
It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently.
The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”.
It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that.
You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box.
Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud).
The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way.
Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team.
Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.
You're making it sound like Hotwire is some novel thing the RoR guys have come up with. It's actually a copy of Phoenix LiveView, and not the only one either.
I'm in the same boat as OP, although a little older. I started my HTML journey around 2000 and have been working as a "front-end" since graduating in 2007.
I think the complexity in front end has been driven primarily by two things:
1. business demands pushing a lot of innovation in FE. Ultimately this is a good thing but it means more complexity, nowadays i mostly write non-JS JS, that is code that needs to be compiled into "real" JS. So the scope of complexity of non JS is almost unlimited and now webassembly :) - wont be long until i'm asked to edit Rust files that compile into jS haha
2. Node JS pushing us FE guys onto the server side and CLI side of things. Suddenly we are expecting to be masters of UI dev with sense of design and UX and also coding for the server and now also writing tests!!!. - I have exactly zero interest in writing tests.
---
Unfortunately 95% of jobs now at least "expect" you to be comfortable in all these areas. Ultimately we are to blame as we are the ones who are pushing the boundaries of innovation, creating new tools and libraries to make our jobs easier/more complex(?) which feeds into creating more and more unrealistic expectations from us.
I am at the point now reaching my 40s looking for some other field to move into....As I don't think i can do this work much longer unless there is a trend of specialistation that will emerge soon.
Edit: Also one other thing to note, a lot of the new guys entering this field in the last 5-10 years are VERY dogmatic and don't really share the principle of if it works it works. They tend to be very much opinionated on having to do things in a certain way. This is why you get a lot of people who have trouble thinking outside of a "React" box (or whatever) and don't seem to understand most of these libs are progressive and there is nothing wrong with combining different approaches to meet your needs. It's like jQuery or imperative JS is a dirty word nowadays. Or that theres nothing wrong with building a static html file with a little js and css without the need for npm packages or some generator/build process.
I think you should answer yourself what you don't like about writing tests in FE. I personally like writing them (at least for my personal project), but I think tools are still evolving in FE testing. E.g. I have recently found out about Playwright and it is step forward compared to Puppeteer: automatic waits and codegen tool is what makes Playwright the joy to work with.
I'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
My comment was actually around Node JS. Writing unit and integration test for async server code and god forbid some kind of critical or secure code is not something I'm comfortable doing.
As far as FE testing I don't have any issue with that as long as the value and trade-offs are well understood and not just writing tests for the sake of it.
Oh. Sorry I must have misread your comment then :-) For Node BE code I either end-up writing pseudo e2e tests (e.g. using supertest like here https://github.com/daliusd/cardamon/blob/master/app.test.js) and/or testing individual components by separating them out from express stuff.
Wow, I’ve taken the exact same path. Started in 2006, learned everything I could, and lost joy gradually over the past few years.
I’ve left my last front end job behind a couple years ago and launched my startup. Now front-end is just a tiny part of what I do.
I'm trying to learn some frontend as a backend developer(primarily .NET Core but I enjoy others like Elixir/Phoenix in my own time as well) to help other developer in our team, but no matter how many times I tried, I just can't get it. The barrier of entry is so insanely high right now, I just cannot force myself to get into it. It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently. Not only that, but Javascript(or mostly Typescript now) is to me so unreadable when combined with parts of html sprinkled everywhere, that you really need to focus a lot just to understand what's in front of you, what it does, but I guess that part is just a matter of getting used to the language.
I don’t know if this is even an option for you but you might want to take a look at Angular especially if you already have an OO language background on the backend.
Basically everything is standardised, you are mostly just writing classes the way you would for a desktop application, the majority of what makes the web frustrating to work with is abstracted away in a series of sensible patterns and overall the tooling is really great.
> take a look at Angular especially if you already have an OO language background on the backend.
Observables, pipes, operators, litany of custom attributes in the markup, the TS source code looks like Java. I'm literally starring now the 4th day at bunch of TS and HTML files only to duplicate a simple UI feature. Once done, writing tests for this mess. All this to create a web app which loads 5-10 seconds with 2 levels of loading spinners. I feel sorry for anyone whose job will be using the application. I actively procrastinate to delay touching it.
I mentioned this more in my other commend on this thread but I should mention that I think the bar for when people reach for an SPA framework like Angular is probably a lot lower than is reasonable. Angular in particular is designed for enterprise style applications and that is about it. Everything you need for that doesn’t come for free in terms of complexity obviously.
The other thing I mentioned elsewhere at the total other end of the spectrum was Hotwire. That is genuinely as close to 2006 web development as I can think of in terms of simplicity and is probably enough for the majority of applications up to and including an email client in the browser which is what they originally built it for.
I did work with Angular a bit. It is admittedly better in my opinion in that context - it gives you kind of guard rails. But then an actual Angular developer came into the project and threw everything around to the point I wasn't recognizing the project anymore. I have to admit he was insanely productive with it as he actually had years of experience just in Angular.
I have to admit, I mostly make 'backend uis' recently and for me Blazor(server for now) fills that niche insanely well, I've never been so productive when doing frontend work, it has its pitfalls as well, our code is probably not the cleanest, but the fact that I can include a project with all my models, services and just use that, makes it so satisfying to work with... I only ever had one similar feeling so far, when trying Phoenix.
> It's not only million different tools, it also to me seems like every React codebase has a huge learning curve on its own because everyone does it differently.
I've been writing React code on and off since 2014 and I can relate to the pain: component creation and API changes in React (especially hooks) have meant quite a different way to do things, and in my experience this resulted in making things harder to understand across the board.
Life was simpler when `React.createClass()` was the only way to create components :)
Hooks and functional components are indeed a different way to look at it, but I sure am happy that they went that way. I doubt that we will see a paradigm shift like that in React again, at least in this decade. And they've been very good at maintaining backwards compatibility.
Personally I find VueJS a joy to work with on the FE. It eschews some of the complexities that come with React and gives you a comprehensive and simple state based component rendering framework.
Vue's cli tool means that you don't have to worry about installing all the dependencies, just answer the setup questions about how you like to work and it installs everything for you: Typescipt, sass, babel, eslint.. all of it installed for you.
I absolutely do not yearn for the SSR template days. Sure when you're composing green field it's straight forward, but when you're coming into a complex project 3 years later, figuring out where on earth the JS is that's impacting this particular screen (or causing this particular bug) can be an absolutely nightmare. I'll be sticking with Vue and Typescript and not reverting to jQuery, thank you very much.
Although I can relate, I find the reasoning in the post a bit odd. For example:
> Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.
If it's a personal project (it doesn't sound like the author is talking about work-related projects), what's stopping the author with writing just good old HTML, CSS and JavaScript?
I said I could relate because a couple of years ago I was in a similar position, but a comment on Hacker News in a thread about JavaScript fatigue says that it doesn't have to be that way (apologies, it's been too long and I was a lurker back then and don't have it bookmarked). That was a liberating moment for me and I now just do whatever it's best on a case-by-case basis.
It's even easier to go with good old JavaScript now than back in 2007 because of all the tooling. We have profilers right in the browsers now. How cool is that!
Another goodie is how modern browsers support modern JavaScript. Basically everything I needed transpiler few years ago just works: const, lambdas, classes, even imports. Supporting only modern browsers when you start sounds like a good idea and if you ever need old browsers, you can always transpile to ES5 later.
Also don't forget that while CSS is still lame, it got few goodies as well, like CSS variables.
The only thing that I personally miss is how to set up Chrome to be a proper IDE. I know that I can edit files from the disk, it has autocomplete, but this whole UI is kind of weird. May be I just need some tutorial.
Honestly SCSS is what I middleware-in first even in toy-sandbox projects. Writing CSS without humane //-commenting syntax and hierarchical definitions is so annoying.
install install install
Everyone is okay with installs (yarn helps with caching downloads, which npm failed to do). The hard part is configure configure configure and then deal with the fact that every few months your config gets deprecated, keys renamed, docs not in sync, and most SO answers talk about one of the older, unspecified versions.
You can finally write what is essentially just HTML and JavaScript!
To be fair, it is html+js that is: hot-reloadable, so you don’t have to click here and there again and again; modular so you don’t have to write a mile long htmls with 80-column indents; you can import other’s work and reuse it; not care about missing features in a “cross-platform” “browser”; not depend on cdn latency and availability; have a proper debugger.
That said, personally I don’t understand this react/redux madness. I understand how it works and how to do things in it, but the general idea misses me. It is all hand-wavy funkchyonal rhetoric with learning curves and budgets that are beyond all reason. Seems like a young religion.
In defense of component frameworks, try making a proper input field that accepts “1 000 00”, formats it into “10,000.00” at focus-out without interfering with a user while they are editing it, yields 10000 into your model in real-time, and present a hint when they try to enter “qwe”, without breaking your data model with NaN. Then we’ll talk about raw html+js or jquery.
I started out my career in a similar fashion as the author (dabbled with HTML/CSS/PHP).
One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books"
With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them.
I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer.
I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers.
From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development.
Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build.
As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
I've been doing front-end work recently and absolutely hate it. It constantly feels like I'm developing on quicksand where I can't trust the layers below me.
But I think web development has actually improved a lot. Frankly 10 years ago it was even worse.
Had we chucked Javascript in the bin a decade or two ago and built something new from scratch we'd probably be better off for it.
I think our worst enemy now is backward compatibility. I wish we could use other technologies/langs to target FE development without transpoling to js. I hope that webassembly will deliver.
I do agree indeed! It has its quirks, but all-in-all easy to use and get stuff done. Not to mention no need to set-up a compiler or anything. It just works.
This was my main reason to switch to mainly front-end: to get away from clunky, badly written C# and Java back-end programming. 2/3 of a code file are just the coder wrangling the OOP typesystem instead of just coding the functionality that is needed.
I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.
Strict type checking does make your code bulletproof. Unfortunately, TypeScript doesn't provide anything close to that. It's easier to mask errors with TypeScript than auto-detect them. Its strict typing should be considered hints for the programmer.
Real strict type checking (as in, eg, Haskell ) does indeed make your code resistant to a certain type of bug. But the kind of type checking Typescript gives you is mostly useful as autocomplete.
(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
At runtime, you can pass primitives to a function that expects a very specific DOM object (say), and it'll just plough on ahead like JavaScript does, until you get an exception that nothing catches because FooFunction doesn't raise any exceptions, and everything breaks.
Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).
> No other language has async built in at such a fundamental level.
I'm not sure that that is true. Rust and Python both have built-in async; while they both have their own takes on what that means, I wouldn't say JavaScript's “syntactic sugar on top of promises, which are object sugar on top of callbacks” is any more of a fundamental level.
Rust does have syntactic support for async but that's not the only thing you need to use async. You also need an async executor runtime, for example tokio. This can cause all sorts of headaches in practice when you want to use libraries which rely on incompatible async runtimes.
You only need an async executor to deal with threading issues; you can completely side-step it if everything's single-threaded (coöperative multi-tasking) or thread-agnostic (Send + Sync). And an executor like smol has no compatibility issues with anything; you just run it.
Python has an async executor, yes, but only to let you do things you can't do with coöperative multi-tasking.
JavaScript has an executor, too. The only difference is that you can't turn it off. It's actually less capable than (most of the) Rust implementations, because JavaScript's single-threaded. (Python's an in-between case, thanks to the Global Interpreter Lock; good JavaScript engines should be able to match Python's concurrency capabilities.)
Executors are only important for things like timers. JavaScript's promises rarely make use of them, except when they schedule their callbacks based on something external to the JavaScript (your “primitive” promises on top of which everything is built). Both Python and Rust work the same way.
The only difference with JavaScript is that it Just Works™ (or, rather, just works; because it does) – but that comes at the cost of sticking JavaScript with a permanently single-threaded runtime.
I think there's been a much bigger change in (particularly front end) web development over the last decade, and that's that the underlying technology is now a lot less experimental.
Wind back to 2010, and websockets was new and fun, webRTC was coming up, there were loads of interesting possibilities about how the web could be used, HTML5 was new/coming, compilers (sass, gulp, etc.) were perceived as a benefit as they took away from common repetitive tasks, KnockoutJS and Ember were trying new approaches (that eventually turned into Angular/React/Vue).
It felt like the possibilities were endless, and the future was ours for the taking.
Now, it feels like we (as the global web community) have entered a period of stability - all of the decisions have been made.
- Frameworks win (and broadly speaking, React, Angular and Vue are all very similar to use, give or take a bit).
- You need to write tests, because front end applications contain more behaviour (which used to belong to the backend)
- Build tools win for a host of reasons (babel allowing future JS features early, type checking, etc.). (As an aside - the logical conclusion of lots of nice build tools is... lots of nice build tools (and therefore boilerplate))
- Experimental technologies (webrtc and web sockets, among others) are "gimmicky" or "niche" - useful in small amounts
- Designs are all the same (hyperbolically speaking) - want a product page? give it a horizontal three-column layout showing a free tier and two pricing options. Use Bootstrap, or roll something out that approximates it.
For me, there used to be an excitement that there could be a new core frontend web technology every few months - that excitement doesn't exist now.
But... that doesn't mean that it's not fun to work in web development anymore. It is the people that have changed and become more limiting, not the technology and possibilities (which have only grown over the last 20 years). And by people, I mean you (you're not 14 anymore), me, clients, managers, users - everyone.
And with expectations come new jobs, no matter how well automation delivers. Robots and software aren't gonna make us jobless because expectations will fill up and overflow any volume of possibilities.
Then we're into the "AI" conversation, where I think the general public think we're a lot closer to AI than we really are... Just because we have 90% reliable speech recognition and it can convert that to a basic google request, and parse some likely results, does not make Siri/Alexa/etc "intelligent".
There's a bit of hyperbole in the article, but it strikes a nerve.
I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.
AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.
Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?
And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.
And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
On the bright side, with native web components and web assembly gaining traction things may be looking up in the future, as a lot of these ideas get rolled into the browser natively.
lol. web components are a waste of time unless someone wants to write a widget with ShadowDOM. Its clear. Svelte has won and is the last thing web can give us. Lets all go home
A static site may use JS, but doesn't require server-side logic (PHP, databases, or any other type of dynamic content). In this case OP implies that it doesn't even require a build (because you may create a static site through a build process -like Jekyll does, for example-).
You can still do this with Vue 3! The CodePen embeds they use in their "Getting Started" docs are all still just loading in an external library and making use of it with vanilla JS.
Sure you can, but then the moment you want to use an external library with it, it's basically a coin flip whether they ship it in the correct format for that. If they don't, you have to import it - but you can only import from modules. So you modify your page to load your code as a module instead, but now you can't access the global state. So you refractor everything and realize, that your page takes a minute to load because each of those modules contains like a 100 dependencies and half of them overlap.
TL;DR: it's there, but it's really only usable in like 5% of scenarios
Well since there's a plural in "CLIs", that goes into the "wrangling" category for me. If the dev/dep process involves more than one bespoke tool (looking at you js/Node monstrosities) and learning the arcana of their interactions, I'm out.
Well, I guess you‘re out of programming as a whole then, no? Most languages and dev process involve a lot of configuration or „bespoke tools“ and learning the arcane of their interactions.
Java? Gradle. JUnit. Maven. JavaDoc. etc.
C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager
Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...
Deployment? Docker. Jenkins. Travis. Kubernetes.
Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.
Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.
I understand what you mean but disagree. I merely appreciate tools that make some effort to standardise their UX. Of course configuration is going to be a major part of the system; however that doesn't mean I must use fragmented tools to manage them.
For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.
And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)
It's not always that easy. Most of the pain around webpack configs comes from dealing with them later, not when starting the project. It might've been written by someone before you and modified by multiple people. Now you have to figure out how to add something new, intended for a different pipeline, into your existing pipeline, which has years of changes you probably don't understand in it.
C/C++ != "most backend languages". Python, Ruby, Go and, Rust are much more commonly used on the backend and none of them have build systems as ugly as C nor as over-engineered and messy as JS.
> Python, Ruby, Go and, Rust are much more commonly used on the backend
Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.
However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.
I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.
I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.
If you like functional JS then you should be using React. This is exactly why it's still the most popular JS framework. If you want a simpler build system then you should try esbuild. It's a single Go binary.
OOP is very easy to misuse where it hurts the most - on architectural level. It's very possible to write bad, unreadable FP code, but worst case isn't as bad or far reaching as with OOP.
In the case of React, I find functional programming excellent when it comes to mapping views from state. For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.
> For state management, functional programming just seems like a massive time sink and a convoluted way of achieving the same things that OOP just gives you.
Through my couple of decades as a programmer, I've gone through various specializations. Spent a good 10 years going very deep in web frontend.
I moved on years ago because, like the author, it was not fun or interesting anymore. I don't feel as strongly about it as the author seems to, though. It's all part of the journey.
Probably at some point, I will move on to a new technical domain than the one that's consuming my life right now, and that's fine.
Fortunately a lot of these frameworks provide tools that set up your project for you. I totally agree that having to configure your own webpack from scratch is hell, and not what I signed up for, but there are tools that can help us make use of the tools we need to do our jobs.
And on the backend, not everything is trivial either. Do you enjoy configuring Spring? What cloud stack do you deploy to? Or do you need a UI framework? And all the complaints I hear about npm these days, I also heard about maven 15 years ago.
The only way to avoid it is to write everything yourself, and not make use of frameworks that do most of the heavy lifting for you. Write simpler applications, I guess, or at least in a simpler environment. With complexity come the tools to manage that complexity.
> ...The language doesn't matter much to me, I know enough of them to know that they are all very similar and thus easy enough to learn. If you know of a good opportunity, let me know.
One advice: be careful when you make claims like this, even if you are an extremely competent programmer, because it sounded extremely aggorant.
Picking up a new tech (framework, language, etc) during the job vs having years of experience building things with the tech makes a huge difference in terms of productivity.
Being language(or framework)-agonostic is cool. But saying languages are very similiar indicates that you probably know none of them in depth. Every language (or framework, etc) is its own microcosmo. (i.e. at the compiler level, design-pattern's level, etc).
I'm asking you this as I believe it will help me in the future. Is having the knowledge about the tool better that having the skills to solve a set of problems? If I really want a position within a specific company (for whatever reason) but they use a language with which I haven't worked before but am willing to learn (and definitely have the learning skills for that!), would I be in a disadvantage with respect to another candidate, one that has extensive knowledge about the language (and ecosystem), even if I would have experience in the "field of the app being built"?
The answer to your question is a big stonking depends. There are some skills and knowledge that are transferable across languages and ecosystems. Some companies are happy to find good talent that are willing to learn and will teach them the specifics of their language and ecosystem. Other companies are unwilling to take on people who don't have 5 years experience in their stack. I once had a company reject me outright because the majority of my experience is with React and they use Vue. Both are Javascript libraries and more similar than they are different. Sometimes the argument in those cases is they need someone who can get the work done yesterday, other times its mere tribalism.
Your best bet is to build a couple of side projects with the language you're interested in and use it as proof that you've passed superficial interest and are willing to learn. After that its down to finding a company or a team that are willing to give you a shot. They are out there.
To second another comment. You have the domain knowledge so that is a valuable place to start. Build the applications in that domain you have experience in, on different tech stacks as side projects to demonstrate the competency. Ultimately, that's all experience is on your CV and the technical interview will be their opportunity to plumb the depths of your knowledge.
Everything else, and I don't know how to stress this enough, is interview technique.
It's a fair comment but you have to admit that the javascript world presents a set of problems that go way beyond the language itself. The problems are different in backend development and in a way they feel a bit more contained.
In the java world I feel I know exactly what to do even though it bores me to tears. In Go I know where to look, same can be said for python and dotnet.
As much as I love the really interesting things I can do in the JS ecosystem I find debugging large projects excruciating. I didn't find the comment particularly arrogant and it rang true to my experience.
Didn't mean to be arrogant at all. I simply said it because I have created things in a variety of languages, and to tell whoever was reading and looking for a BE engineer that I have no problem learning new languages that I may not know. Now obviously since I haven't been exclusively a BE engineer, I'm not an expert in BE, but I'm more than happy to be given the chance to become one, which is essentially the whole point of the article.
I can relate, and agree front-end frameworks and tooling feel overly complicated.
The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production.
I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me.
Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it.
410 comments
[ 4.2 ms ] story [ 314 ms ] threadAs much rhetoric as there is about this being the frontend, the backend is worse. "Backend" is just defined as "anything that isn't the frontend" so the word casts a wide net. There's everything from logging and metrics to databases to pipelines and task managers to physical hardware and networking tools.
That said, it's always good to have a variety of knowledge and experience. The backend is nice because it doesn't rely on visual output as much and so you can code more without context switching between the editor and the browser. And it's incredibly easy to get pigeonholed into writing frontend code only. So many companies seem to be unable to let go of the fact that you have some specialization.
Sure, but nobody in marketing is bothering you to use Javascript-framework-du-jour on the backend so they can put it on their sales slide.
You can write the backend in totally boring technology and no one will ever know or care.
I’ve worked in frontend for five years and this has never been a thing that happened. If a framework is important to your marketing, that would be because your customers have to use it to interface with your product. The same would be true if your customers had to interact with your backend; they would want an API in popular languages, trendy languages and frameworks too.
We have standardized on Angular on the frontend and require providers to use it. The backend tech is less critical, it can be one of Java, JS, or Python and the important point is a JSON/REST interface with Swagger documentation.
In hindsight, I just didn't enjoy writing code for money. When I left my last programming job, I started programming for fun again. It wasn't a deliberate effort, but something that happened on its own.
If you program for fun, you don't have to learn anything. You don't have to use webpack or SCSS if you don't want to. You don't need to write tests. "oops" is a valid commit message and "bugger off" is a valid response to stakeholders.
I'm thinking about making a T-shirt with this phrase. Because it's important.
My target goal is to retire soon-ish, and I'll dick around with my own stupid programming language around board games: http://www.adama-lang.org/
I don't intend to rally stake-holders about it.
I fully expect to tinker on this for a decade without any love, and that's just fine with me.
I don't intend to defend my decisions, or justify why this thing exists.
[1] https://www.robinsloan.com/notes/home-cooked-app/
I haven't seen a performant LOB app in years.
The only meaningful change from my perspective is that browsers can do more things.
Backend is nice because you have greater control over the environment, and because testing data flows is easier than testing user interfaces. However, I was not a big fan of devops and cloud stuff, which felt too abstract to me.
Much of it is basic CRUD, built on top of a tower of complexity, crammed into a container and served by whatever cloud provider.
I spend most of my time plugging and praying/crying.
When I started looking into putting together a simple but modern frontend in my own time after having done only backend for years, it seemed like there's quite a lot of tooling and associated complexity that you kind of have to deal with just to get your frontend deployed, whether you need a complex architecture or not.
Sometimes "bugger off" is a valid response to stakeholders, even in a professional context: you just have to know how to say it.
I really started to feel like, after three and a half years, I was succeeding the other day when one of my product managers told a stakeholder to bugger off and they did without even challenging it.
This is the almost inevitable path of those who started their career thinking: how lucky am I that my hobby coincides with a well paying job.
I think you've touched on something essential here. It may explain the continuous appeal of open source.
Maybe it also explains how even though work is perpetually exhausting, somehow I still find energy to work on side projects, just so I can feel some uninhibited creativity.
I'm also reminded of a cynical quote from my dad. When I was young I asked him "Was work fun?" to which he responded "If work was fun they wouldn't pay you."
What is wrong with web dev? Why is it perceived not ok to be "stuck in 2015"? I've never seen so much churn and turnover in any other single layer of a tech stack.
React has been around since 2013 [0], Webpack has been around since 2014 [1], etc.
If you're stuck in 2015, you're 5 years of updates and improvements behind.
The author, by his own account, does not want to keep up with the evolution of the ecosystem: "I suppose with the increase of complexity in what we want to achieve on the web the stack to achieve it with has had to also increase in complexity. For me, personally, it's too much".
[0] https://en.wikipedia.org/wiki/React_(JavaScript_library)
[1] https://en.wikipedia.org/wiki/Webpack
The first one is for people who are mostly comfortable with backend development and want to have as little to do with the mess that is the churn of front end as possible. However for those people I would strongly recommend taking a serious look at Hotwire.dev which is a new approach from the same team behind Ruby on Rails and their vision of trying to bring that same level of simplicity to the front end.
It does a great job on that angle in particular and for most applications is likely to be entirely appropriate for your needs. They built it specifically while developing a modern web based email client so it scales up to fairly decent levels of complexity while still maintaining probably 85% of the performance of the standard SPA approach. But if you specifically want simplicity this is the best option out there I know of currently.
The other end of the spectrum is Angular which is all in on the SPA approach and everything that involves however it has a number of key differences between other frameworks that I think make it the “front end framework of choice for enterprise applications”.
It’s extremely stable both in terms of bugs, performance and API. Every code change for example that lands in main is tested against almost 3000 different applications full test suites inside of Google and I believe (not entirely sure if this is correct or not) but also a number of other enterprises in addition to that.
You are mostly going to be writing code as though you were just writing a regular application because it was specifically designed to sit on top of the web rather than trying to expose all the moving targets of the web platform and its various APIs directly to developers. I can not stress how much this can reduce headaches out of the box.
Basically the way I look at angular is Google said here is an approach that we have found works really well for writing apps that scale in terms of performance and code based. You won’t be able to outgrow this no matter how big you get and it’s what we use to run almost all of our customer facing revenue generating parts of the business (ads and cloud).
The approach is about as well tested as well you could possibly find. In addition to that if you follow our opinionated approach and APIs we are going to allow you to have a great developer experience. One main example of this is Angular has a rolling release cycle now where the tooling is able to upgrade your code base for you with each new release meaning you have no excuse for staying on the happy path. But on the whole the idea of front end churn is a thing of the past this way.
Additionally, behind the API that you are going to be exposed to Google are throwing a lot of “computer science” fire power at problems like performance and general engineering best practices etc but basically you can just outsource most of that part of the problem to the Angular team.
Disclaimer: it’s not magic, it’s still possible to write bad apps and even recently on here you will have heard people talk about Google cloud as a good example but it seemed like a lot of the reasons for that based on the inside baseball comments I read here had more to do with culture, product velocity and the sheer number of teams who weren’t working in coordination with each other. I still stand by the idea that the idea however that the sheer insane amounts of money Google has betting on Angular means that it is only going to get better and better over time at those issues.
I think the complexity in front end has been driven primarily by two things:
1. business demands pushing a lot of innovation in FE. Ultimately this is a good thing but it means more complexity, nowadays i mostly write non-JS JS, that is code that needs to be compiled into "real" JS. So the scope of complexity of non JS is almost unlimited and now webassembly :) - wont be long until i'm asked to edit Rust files that compile into jS haha
2. Node JS pushing us FE guys onto the server side and CLI side of things. Suddenly we are expecting to be masters of UI dev with sense of design and UX and also coding for the server and now also writing tests!!!. - I have exactly zero interest in writing tests.
---
Unfortunately 95% of jobs now at least "expect" you to be comfortable in all these areas. Ultimately we are to blame as we are the ones who are pushing the boundaries of innovation, creating new tools and libraries to make our jobs easier/more complex(?) which feeds into creating more and more unrealistic expectations from us.
I am at the point now reaching my 40s looking for some other field to move into....As I don't think i can do this work much longer unless there is a trend of specialistation that will emerge soon.
Edit: Also one other thing to note, a lot of the new guys entering this field in the last 5-10 years are VERY dogmatic and don't really share the principle of if it works it works. They tend to be very much opinionated on having to do things in a certain way. This is why you get a lot of people who have trouble thinking outside of a "React" box (or whatever) and don't seem to understand most of these libs are progressive and there is nothing wrong with combining different approaches to meet your needs. It's like jQuery or imperative JS is a dirty word nowadays. Or that theres nothing wrong with building a static html file with a little js and css without the need for npm packages or some generator/build process.
I'm still looking how to improve FE testing but it is something what absolutely makes my life easier.
As far as FE testing I don't have any issue with that as long as the value and trade-offs are well understood and not just writing tests for the sake of it.
Good luck OP!
Basically everything is standardised, you are mostly just writing classes the way you would for a desktop application, the majority of what makes the web frustrating to work with is abstracted away in a series of sensible patterns and overall the tooling is really great.
Observables, pipes, operators, litany of custom attributes in the markup, the TS source code looks like Java. I'm literally starring now the 4th day at bunch of TS and HTML files only to duplicate a simple UI feature. Once done, writing tests for this mess. All this to create a web app which loads 5-10 seconds with 2 levels of loading spinners. I feel sorry for anyone whose job will be using the application. I actively procrastinate to delay touching it.
The other thing I mentioned elsewhere at the total other end of the spectrum was Hotwire. That is genuinely as close to 2006 web development as I can think of in terms of simplicity and is probably enough for the majority of applications up to and including an email client in the browser which is what they originally built it for.
I've been writing React code on and off since 2014 and I can relate to the pain: component creation and API changes in React (especially hooks) have meant quite a different way to do things, and in my experience this resulted in making things harder to understand across the board.
Life was simpler when `React.createClass()` was the only way to create components :)
Vue's cli tool means that you don't have to worry about installing all the dependencies, just answer the setup questions about how you like to work and it installs everything for you: Typescipt, sass, babel, eslint.. all of it installed for you.
I absolutely do not yearn for the SSR template days. Sure when you're composing green field it's straight forward, but when you're coming into a complex project 3 years later, figuring out where on earth the JS is that's impacting this particular screen (or causing this particular bug) can be an absolutely nightmare. I'll be sticking with Vue and Typescript and not reverting to jQuery, thank you very much.
And there’s zero reason to use SCSS.
> Starting a new project? Make sure to write your project idea down because by the time you are finished setting up the vast boilerplate you have probably forgotten it.
If it's a personal project (it doesn't sound like the author is talking about work-related projects), what's stopping the author with writing just good old HTML, CSS and JavaScript?
I said I could relate because a couple of years ago I was in a similar position, but a comment on Hacker News in a thread about JavaScript fatigue says that it doesn't have to be that way (apologies, it's been too long and I was a lurker back then and don't have it bookmarked). That was a liberating moment for me and I now just do whatever it's best on a case-by-case basis.
Also don't forget that while CSS is still lame, it got few goodies as well, like CSS variables.
The only thing that I personally miss is how to set up Chrome to be a proper IDE. I know that I can edit files from the disk, it has autocomplete, but this whole UI is kind of weird. May be I just need some tutorial.
install install install
Everyone is okay with installs (yarn helps with caching downloads, which npm failed to do). The hard part is configure configure configure and then deal with the fact that every few months your config gets deprecated, keys renamed, docs not in sync, and most SO answers talk about one of the older, unspecified versions.
To be fair, it is html+js that is: hot-reloadable, so you don’t have to click here and there again and again; modular so you don’t have to write a mile long htmls with 80-column indents; you can import other’s work and reuse it; not care about missing features in a “cross-platform” “browser”; not depend on cdn latency and availability; have a proper debugger.
That said, personally I don’t understand this react/redux madness. I understand how it works and how to do things in it, but the general idea misses me. It is all hand-wavy funkchyonal rhetoric with learning curves and budgets that are beyond all reason. Seems like a young religion.
In defense of component frameworks, try making a proper input field that accepts “1 000 00”, formats it into “10,000.00” at focus-out without interfering with a user while they are editing it, yields 10000 into your model in real-time, and present a hint when they try to enter “qwe”, without breaking your data model with NaN. Then we’ll talk about raw html+js or jquery.
Quick Google search and 15 seconds later: http://www.decorplanit.com/plugin/ (one of many, I picked one that closest resembled your reqs)
I find your lack of faith in jQuery disturbing.
One reason for the growing complexity in UI tooling is that many websites we build today compared to 10 years ago are not "stupid little web pages containing youtube embeds and guest books"
With that being said, many people are still building simple websites, and React/TypeScript/Webpack/Babel/CSS-in-JS/et al. probably isn't solving any "real problems" for them.
I've had to learn and adapt during my whole career, but I'm also more productive today than I've ever been, thanks to the tools that are available to me as a front-end developer.
I still reach out for Vanilla HTML/CSS/JS now and again, but I mostly deal with large and complex UI's that need to be shared across multiple projects and hundres of developers.
From a historical perpsective: jQuery solved a very real problem at it's time: simplifying and doing consistent/reliable cross browser JS development. Backbone.js later came along to solve the problem that JavaScript apps were now so large and complex that simply dropping a few JavaScript/jQuery files was not a scalable way to build. As applications became even more complex, React.js made it easier to deal with UI/state changes in large code-bases. All of these abstractions grew out of necessity.
But I think web development has actually improved a lot. Frankly 10 years ago it was even worse.
Had we chucked Javascript in the bin a decade or two ago and built something new from scratch we'd probably be better off for it.
It’s lightweight and very flexible.
No other language has async built in at such a fundamental level.
It’s incredibly easy to throw anonymous functions around.
It’s destructuring is incredibly powerful.
JavaScript code is concise.
Recent versions such as es6 have made it better.
JS for me was a very nice change from the heavyweight OOP languages but now what the usual stack implies is just as bloated and obtuse.
Luckily for backend it's super easy to set up typescript as the default are good enough for weekend projects/prototypes:
``` mkdir my-project cd my-project npm init -f npm i -D typescript ts-node @types/node npx tsc init touch index.ts npx ts-node index.ts ```
I do like Typescript if you just use it minimally: you can type (I prefer interfaces usually) argument types and rely on the compiler to infer types.
But then the OOP fundamentalists got their hands on it and now they want strict type checking and believe that it makes their code bulletproof https://indepth.dev/posts/1402/bulletproof-angular
(and, if I'm not mistaken, at run time, you can still add or remove properties from an object and re-introduce bugs. Which can happen with 3rd party libraries, for example.)
Oh, and did I mention that virtually every browser API these days is potentially optional, with the undefined primitive replacing bits and pieces of them at seemingly random, depending on browser version and configuration, and the presence or absence of certain extensions…? I like the idea of TypeScript, I really do, but don't even try to use it for FFI (where “foreign” is anything outside your TypeScript module).
I'm not sure that that is true. Rust and Python both have built-in async; while they both have their own takes on what that means, I wouldn't say JavaScript's “syntactic sugar on top of promises, which are object sugar on top of callbacks” is any more of a fundamental level.
Python has an async executor, yes, but only to let you do things you can't do with coöperative multi-tasking.
JavaScript has an executor, too. The only difference is that you can't turn it off. It's actually less capable than (most of the) Rust implementations, because JavaScript's single-threaded. (Python's an in-between case, thanks to the Global Interpreter Lock; good JavaScript engines should be able to match Python's concurrency capabilities.)
Executors are only important for things like timers. JavaScript's promises rarely make use of them, except when they schedule their callbacks based on something external to the JavaScript (your “primitive” promises on top of which everything is built). Both Python and Rust work the same way.
The only difference with JavaScript is that it Just Works™ (or, rather, just works; because it does) – but that comes at the cost of sticking JavaScript with a permanently single-threaded runtime.
Wind back to 2010, and websockets was new and fun, webRTC was coming up, there were loads of interesting possibilities about how the web could be used, HTML5 was new/coming, compilers (sass, gulp, etc.) were perceived as a benefit as they took away from common repetitive tasks, KnockoutJS and Ember were trying new approaches (that eventually turned into Angular/React/Vue).
It felt like the possibilities were endless, and the future was ours for the taking.
Now, it feels like we (as the global web community) have entered a period of stability - all of the decisions have been made.
- Frameworks win (and broadly speaking, React, Angular and Vue are all very similar to use, give or take a bit). - You need to write tests, because front end applications contain more behaviour (which used to belong to the backend) - Build tools win for a host of reasons (babel allowing future JS features early, type checking, etc.). (As an aside - the logical conclusion of lots of nice build tools is... lots of nice build tools (and therefore boilerplate)) - Experimental technologies (webrtc and web sockets, among others) are "gimmicky" or "niche" - useful in small amounts - Designs are all the same (hyperbolically speaking) - want a product page? give it a horizontal three-column layout showing a free tier and two pricing options. Use Bootstrap, or roll something out that approximates it.
For me, there used to be an excitement that there could be a new core frontend web technology every few months - that excitement doesn't exist now.
But... that doesn't mean that it's not fun to work in web development anymore. It is the people that have changed and become more limiting, not the technology and possibilities (which have only grown over the last 20 years). And by people, I mean you (you're not 14 anymore), me, clients, managers, users - everyone.
With stability come expectations!
Then we're into the "AI" conversation, where I think the general public think we're a lot closer to AI than we really are... Just because we have 90% reliable speech recognition and it can convert that to a basic google request, and parse some likely results, does not make Siri/Alexa/etc "intelligent".
I originally came from Java and was so fed up with the hulking class lib and the arcane build systems sprinkled with Ant snippets and XML galore, so JS felt like a fresh breeze.
AngularJS was a bit convoluted and the syntax was not nice. But OK, data binding was nice. Bit like dependency injection on the Java side made the code much harder to reason about but helped build certain classes of applications.
Angular 4 was just WTF. Somewhat cleaner module system but now with a clunky OOP language instead of the elegant functional expressions that JS had and Java finally adopted. For which reason exactly?
And I tried Vue which is a much lighter framework but like Angular, the build system is just retarded. Instead of many dozens of JARs with dozens of sub-dependencies, modern JS goes for the kill and literally imports several hundred of npm package with thousands of dependencies.
And in the end, I end up having to use "browserify" to have JS running in a browser. It's a clowns world in IT, but modern JS really takes the cake. I'm back in backend, solving real problems instead of wrangling my build chain.
Shadow DOM having better performance is a myth.
Google it.
https://codepen.io/team/Vue/pen/KKpRVvJ
TL;DR: it's there, but it's really only usable in like 5% of scenarios
Java? Gradle. JUnit. Maven. JavaDoc. etc.
C/CPP? Make. CMake. Various dependency management tools. Maybe your OS native dependency manager
Your OS? Brew / Yay / pacman / app-get / vim config / IDE configuration / environment tools / ...
Deployment? Docker. Jenkins. Travis. Kubernetes.
Coming back to „js monstrosities“, if you ever had the fun to poke around in the literal arcane magicks that are C++ dependency management systems and giant CMAKE files, you‘d love node. In fact, most cli tools are just for templating projects or generating boilerplate for components. They aren‘t arcane or complicated at all.
Configuration is half of programming or dev ops. If you don‘t like it, maybe it just isn‘t for you.
For instance, I avoid touching those Java tools you mention (or Javascript), preferring leiningen et al. from the Clojure ecosystem. If I don't want to deal with CMAKE or whatever the hell php or perl or erlang or go use, I can use my distro's package manager (coincidentally, yay) to abstract them away. If something goes wrong (which rarely happens these days!) it's even money that the problem comes from some Node/JS intermediate abomination which doesn't even show you the curtesy of being tractable in its scope or mode of operation.
And your last line is uncalled for. I'm happy you like the current state of affairs, but my very subjective view is that I'm not affected by the JS-land Stockholm syndrome. Doesn't mean I don't enjoy dealing with the domain problems :)
Webpack is difficult to figure out at first, but if you have an existing config it should be a lot easier.
Uhhh. They are popular nowadays, but the sheer volume of old CRUD backends in Java or C++ still outweighs these systems. If not, they are at least equal I'd wager.
However, they may be overengineered or not. We don't know, because they had enough time to mature and decide on industry standards. In fact, the newer JS buildsystems are, the less surface level APIs they expose. Take the newer CRA versions for example. Like cargo or pip, most of the complicated things are abstracted away.
I also don't think they are over engineered. When building software for browsers, you need to adress many different things at once. Most build systems compile some form of templating, CSS syntax and JavaScript flavours. They need to target different browsers and their versions for example. Furthermore, you can't build JS and output it into an universally understood binary format. You have to care for different browsers, their level of ECMAScript they support, if or if not they support specific CSS syntax, bundle size, how images are imported, how SVSs are imported, more assets management and so on. For most backend things, you just pack things into one huge binary and its fine.
I'm not saying modern JS bundlers and build systems are the best we can do. I'm just saying what's there works for the majority, and we're getting there eventually.
It's the exact same thing to me as what this article is complaining about. Everyone jumping on the latest and greatest bandwagon.
Angular is easy, and OOP is very easy to work with for business needs.
Also the only time I used FP it was a seemingly awful implementation.
Perhaps I'll mess around with F# or something some time to see how I feel about it more.
Huh? function(state(A)) = state(B), always.
I moved on years ago because, like the author, it was not fun or interesting anymore. I don't feel as strongly about it as the author seems to, though. It's all part of the journey.
Probably at some point, I will move on to a new technical domain than the one that's consuming my life right now, and that's fine.
And on the backend, not everything is trivial either. Do you enjoy configuring Spring? What cloud stack do you deploy to? Or do you need a UI framework? And all the complaints I hear about npm these days, I also heard about maven 15 years ago.
The only way to avoid it is to write everything yourself, and not make use of frameworks that do most of the heavy lifting for you. Write simpler applications, I guess, or at least in a simpler environment. With complexity come the tools to manage that complexity.
One advice: be careful when you make claims like this, even if you are an extremely competent programmer, because it sounded extremely aggorant.
Picking up a new tech (framework, language, etc) during the job vs having years of experience building things with the tech makes a huge difference in terms of productivity.
Being language(or framework)-agonostic is cool. But saying languages are very similiar indicates that you probably know none of them in depth. Every language (or framework, etc) is its own microcosmo. (i.e. at the compiler level, design-pattern's level, etc).
Your best bet is to build a couple of side projects with the language you're interested in and use it as proof that you've passed superficial interest and are willing to learn. After that its down to finding a company or a team that are willing to give you a shot. They are out there.
Everything else, and I don't know how to stress this enough, is interview technique.
In the java world I feel I know exactly what to do even though it bores me to tears. In Go I know where to look, same can be said for python and dotnet.
As much as I love the really interesting things I can do in the JS ecosystem I find debugging large projects excruciating. I didn't find the comment particularly arrogant and it rang true to my experience.
The good news is that there is another way. It's completely feasible to develop without any tooling but a static web server and a browser nowadays. Just bundle for production.
I've developed [1] (a +10k LoC chat app) and [2] (a small web app) using just a 600 LoC template library [3] (which I should really extract), and I vastly prefer it over more traditional setups. Being so close to the browser makes it so easy to see what is going on. I've never spent hours or days debugging the infrastructure code because there is barely any, which is usually what ruins the fun for me.
Everybody is different, but for me the accidental complexity of the commonplace front-end stack (webpack, react, typescript, ...) isn't worth what you get out of it.
1: https://github.com/vector-im/hydrogen-web 2: https://github.com/matrix-org/matrix.to 3: https://github.com/vector-im/hydrogen-web/blob/master/src/pl...