Hacker News Reader

Comment by sysadm1n | Hacker News Reader

Honestly, I'm turned off by these frameworks. Javascript is an easy language, and these frameworks raise the bar to entry. Many will say they make things 'easier' but that's not my personal experience. Some context: I wrote a lot of JS in the early/late 2000s (Anyone remember WebFX by Erik Arvidsson?). His follow-up gig became WebOS[0]

Back then it was called DHTML or Dynamic HTML and then evolved into the HTML5 standard later on. The syntax of React & Vue is just too weird for me. Frankly I've reached a framework fatigue after learning jQuery inside out which was a hard-won battle, and then having to learn React/Vue/Svelte just to stay 'in the game' is too much for me. Excuse me if I'm biased here.

[0] https://newmedia.fandom.com/wiki/Web_Operating_System

View on HN

I hear you...another level is that building javascript files has gotten so obfuscated with build processes such as webpack, babel, and typescript, that it adds a layer of confusion just to output code that you know is valid code, but all these darn build processes may give you problems under the hood....then you gotta research all that nonsense and find that some packages weren't updated.

THAT is the fatigue part to me. I don't really mind learning new frameworks, cuz let's be honest, most of them are all doing CRUD operations and repainting the browser with new html. However, under the hood stuff that potentially arises with misaligned, packages, or configs...ughhhhh

Webpack specialist became a position recently. I miss these good times when you could simply %.o: %.c $(CC) -c $(CFLAGS) $(CPPFLAGS) -o $@ $< and feel great for the rest of the day.

Hahah, I'm not surprised. Them config files have created a niche FE DevOps Specialist role.

To be fair, while the hours of painful medium articles and gists research, the knowledge gained has given me a better understanding of Webpack, and I do feel more confident when taking on various tutorials which all have different approaches to fit the config to my needs. But still, as a newcomer to JS or someone in OP's position, the build game is certainly a lot more complicated than your command!

....btw, I have no idea what your command does/says :D. Linux (Ubuntu) CLI syntax has been something I've tried to improve on over the years.

Yep, the blogspam only adds to the complexity because you can not be certain of an author's level of knowledge until you become an old sailor yourself.

This command is a Makefile rule for building .o out of .c source files. It is var-heavy, but results in something like:

  gcc -c -std=c99 -Wall -I/path/to/headers -o file.o file.c

I have no idea what my usual webpack config results into and how to debug that mess.

I find this interesting because the string you just provided you feel is something so ubiquitous that everyone knows what you're talking about.

It may as well be a foreign language to me, but webpack? Webpack is easy... To me.

I think the parent commenter’s script was posted with tongue in cheek.

I don’t think so — there was never a time when C/C++ build specialist was a position.

And yes, it used to be easier. We didn’t have the speed and convenience of deploying code to the web, but we delivered software that worked, and with nicely-written end user documentation.

Have you ever tried compiling 20 million lines of code? Probably gonna want a build specialist to distribute that over as much cpu power your org has available. Unless thats something you want to do in addition to everything else

Roles that specifically deal with build tooling/improvements are totally a thing in various places.

That's looking at history through rosy glasses. Now edit the contents of a transitively included header file, run make and feel unhappy for the rest of the day while debugging why your executable did not get rebuilt.

Every environment of its time goes through a phase of build-specialist position, required for big projects. Webpack must be one of the worst so far though, it's in this uncanny valley of being unopinionated yet still requiring special operators and plugins for everything. It feels like a black box where you just can't be creative and compose things yourself, you always have to copy a template and find the magic justMakeItWork-option. No surprise really, since it's in a rather difficult position, integrating 3 major legacy technologies (css/html/js) that were not meant for it to begin with, add pre-processors like sass, typescript and static asset generation to the mix and you have more than 6 stacks to spaghetti together.

Spotted a non front end developer.

I'm being honest here -- there are things you need to learn. You may not like them at a beginner or someone new to the stack, but they are here as industry standards for good reasons (which I won't go into here).

By the way, JavaScript is not necessary a language as "easy" as you think is. I have seen plenty of bad code written by professional software engineers. Seriously, you need to put a lot of effort into becoming a good front end developer.

Or you can avoid frontend work

Some of the very best websites I've had the pleasure of visiting and interacting with use vanilla (like https://ciechanow.ski/ for example). Using React for every frontend solution is like using K8s for every cloud solution. Great if you know it, but a huge complexity headache for literally everyone else.

React is orders of magnitudes simpler than K8s. You can write your own React in a day probably.

Javascript is an easy language only for trivial use cases. Once you start having to deal with real-time async state across multiple components, it becomes very much not so easy.

These frameworks aren't meant to do what basic DHTML did back in the day. Those use cases are still served just fine by basic scripting or serverside interactivity.

What these frameworks allow are entirely new classes of featureful client-side applications (think Google Workspace, Maps, Earth, dashboards, games, sketching programs, photo editors, etc.) that would be HELL to write in vanilla JS.

If you're not building something like that, nobody is forcing you to use those frameworks. But at a certain level of complexity, those frameworks are worth their tradeoffs. Beyond that, at an even higher level of complexity, they become necessary... or you end up writing your own framework.

The reason these see such adoption isn't because devs are getting easier, but web apps are getting orders of magnitude more complex than back in the day.

I don't think the bar to entry to has necessarily gotten much higher; rather, the skill ceiling has increased a thousandfold... you can still be a basic JS dev to add a basic form validation and submission or whatever, and you don't need React for that. These days vanilla is plenty powerful for simpler use cases. But you can't easily scale that up to the level of modern web app interactivity. Or if you can, well, build it and show people and see if you succeed in convincing them "this is better than Vue/Svelte/React/Angular". People are always saying that, but I've yet to see a complex web app NOT written in some sort of abstracted framework. If you manage to do it, it would be very impressive and way more convincing than just saying "frameworks are unnecessary" -- because as far I can tell, along with thousands of others of web devs, they are not.

> Back then it was called DHTML or Dynamic HTML

Well that was rather during the 90s, no? Like a decade before HTML5.

That was what it was called when I first started using JS in the late 90s with IE3 or 4 IIRC.

Same here as a backend engineer.

I went into js/ts because I wanted to create something that I can interact with graphically, I don't really care about DOM.

Worked out for me mostly:

https://aperocky.com/cellular-automata

https://prehistoric.tech

These are built with typescript and compiled to js, with HTTP/CSS being static. And basically no framework usage. All of the complexity are essentially the simulation themselves.

I second this. I started writing HTML/Javascript since before CSS existed. Nowadays I mainly do backend, but keep doing JS/CSS/HTML for some small pages.

I recently started to work in React for some work stuff, and I just hate it. Actually, both the "class oriented" and the newer "hook oriented" versions just suck. They amount of abstraction crap that get over a website is amazing. And Redux with the dispatch state change ... Angular is a bit more sane but still similarly bloated.

That is just because you worked for long time with backend. Angular looks better for you - because it was developed to be easy adoptable by backend devs. But React is great, it just use different paradigm than is used for backend development. PS.I have also stared from those web early times.

I can relate to that. I got "lucky" that I had to learn React in a few weeks, and while I grumbled a lot in the beginning, I came to love it (not js packages ecosystem though, that simply sucks). Huge thanks to my coworkers at the time who took me through the speed course!

You need to look at ES6 as a completely new language, almost completely unrelated to JS. Once you learn it, React is easy - and genius in its simplicity. I can't imagine building even a medium sized webapp without some way of building UI declaratively. Maintaining a classical jQuery / native JS webapp is a nightmare, while these frameworks break up the problem into manageable pieces.

Highly recommend biting the bullet and learning one of them, it really is worth it (not necessarily React, there are lots of others too).

You'd dig Joystick: https://github.com/cheatcode/joystick.

I designed it to be a natural transition from learning the fundamentals of HTML, CSS, and JavaScript into full-blown, component-driven UI development. Dirt simple API, no syntax tricks, no specialized knowledge. Just plain ol' HTML, CSS, and JavaScript organized into a system that's more productive than standalone files.

It works on its own in the browser or as a part of a full-stack framework.

You are not alone. I've done exactly what you have and have faced 7 months of job searching headwinds this year just because (at least it feels like this to me) my employer didn't put me in front of enough React code (because they put me in front of other legacy code that needed more attention!!).