Hacker News Reader

Comment by userbinator | Hacker News Reader

I’ve never worked as a professional frontend developer, so even though I’ve been writing HTML/CSS/JS for 15 years for little side projects, all of the projects have been pretty small

I'm pretty much the same, and one thing I've noticed which continues to both amuse and sadden me is the fact that those whose main focus is not web development often make better sites/pages than "professional" developers. I once rewrote, in a few hours, an internal site that had been developed by another team over a few weeks but with many problems (it was an enormous SPA), and made it so much faster and easier to use that once my coworkers found out, they all switched to using mine. That didn't go over well with the team who built the original...

Another experience I've had with a dedicated frontend developer: https://news.ycombinator.com/item?id=18486124

View on HN

I think I know why that might be the case: they used an approach appropriate for large-scale projects in a small-scale project - happens very often really.

None of the max 30-user SPAs I wrote during my time at a certain large pharmaceutical company made sense as SPAs, because the scale at which that becomes beneficial just wasn't there.

As for your other experience: I get where you both are coming from. Thing is, we as front-end developers are kind of forced to use that guy's approach, because over the years stakeholders got used to a level of flexibility that's just not achievable using yours.

I for one would love to use minimal amounts of JS instead of frameworks that make me wait 2 minutes on my sad little work laptop until they compile the project, but that would make any event in which some stakeholder changes their mind a disaster requiring me to re-write the whole application every now and then.

Anyway there's light at the end of this tunnel in the form of compiler-frameworks:

https://svelte.dev/

Writing in this feels just like old school vanilla JS, but with additional language features like reactivity.

I believe a lot of it is also because many genuinely useful features from frameworks have recently been added to the core language. "Vanilla JS" (and "Vanilla CSS") in latest-generation browsers with support for JS modules, JS classes, async/await, fetch, querySelectorAll, Flexbox and Grid Layout is something else than writing "Vanilla JS" five years ago.

The only way your comparison works is if your point is "Framework driven apps are never good". I've lost count of the number of times I've pointed out that a good vanilla JS is always going to be better than a bad framework driven app. One is a good app and the other is a bad app. It's obvious, and therefore not a useful comparison.

The valid, useful test is whether or not a good vanilla JS app can be better than a good framework driven app.

Yes, but the choice of approach isn't outcome-neutral.

There is also the question of whether going-vanilla more often results in good apps.

I'd go so far as to say the "naive approach" for most things, whenever it delivers on all the requirements, is always the best approach.

Be it relational (vs., nosql); grep vs elasticsearch; etc.

The naive approach if you're a developer who knows React is to use React for everything.

> The valid, useful test is whether or not a good vanilla JS app can be better than a good framework driven app.

A much more useful test is to look at the average vanilla and framework app. Obviously the best framework app or vanilla app is gunna be pretty good regardless.

Do frameworks encourage bad/lazy coding? Do they make it very easy to half baked something but very hard to create something polished? Does the constant churn of frameworks mean that a project can never be mature and stable?

Is plain JS too restrictive? Do you have to reimplement react yourself if you want to make a good website?

I think these are the relevant questions.

I'm sorry to say this, but it's not a problem with the newfangled stuff. I think you just don't work with very good frontend devs. Which isn't surprising honestly - it has the lowest barrier for entry of any programming specialization (I started there myself).

I think its a problem with selling. People want to sell. So out with the old, in with the new. Lets revive some of the trends from the 70's. Or lets rewrite all this code to use classes. Sell more books and courses. Hate on all solutions that dont require out products. Are you still writing plain old JS? In order to be pro you need to use these frameworks... Its all marketing. Trying to argue is like standing on a train track and argue a train to stop. The train will just continue. And plenty of people wanting to be on the hype train.

Second problem is that buyers are not result focused. Few companies understand that they pay for these cool frameworks every time a user visit their website. They pay with 15% less conversion, or lower user satisfaction.

Or they have real value by helping developers deliver features that users love while contending with the inherent statefulness of clients.

If you're a front-end only developer not only do you use the same hammer (big framework) for all nails, the use of that hammer is what gives you job security and satisfaction. If companies switched to using old fashioned server-rendered pages with light JS, half of HN would not have anything to do at work.

For the first year, anyway. If the project continues to grow, next year they would be called to deal with the enormous spaghetti mess that has resulted.

It’s as if everyone forgot why we moved presentation logic to the same place and why we favor declarative programming over DOM mutations. When you render is completely orthogonal to that.

right, i only do vanilla: sites are finished fast and they just work. not someone any one would hire. people are really used to frameworks. it would be a step back for them.

>In one place I wanted to change a button’s HTML contents.

if you know what the hidden elm is going to contain you can just add the html to the page as a hidden elm. if it can have 2 states you can also add both nodes as html. just show only one at a time.

the <i> and the <object> are always children of <button> i would target them as such, no need to have a class. unless you use <i> 2x. (one for each state) but i think the icon should be the button bg.

onclick gives you a reference to the button with which you can change it's class. things inside (now styled by the classname of their parent) will change along. (swap bg, hide/show etc)

I can build out a backend with a microframework and sqlite in no time. Why doesn't every company just throw out all the frameworks (or frameworks disguised as libraries) and just do what I did?

Because it doesn't scale for large projects and is impossible to work on with larger teams. Rails may seem bloated to some people, but if you are creating a set of complex business rules that constantly change and cost too much to rewrite with the framework flavor of the day, it makes a lot of sense.

Reply on news.ycombinator.com