- cross-posted to:
- techtakes@awful.systems
- hackernews@lemmy.smeargle.fans
- cross-posted to:
- techtakes@awful.systems
- hackernews@lemmy.smeargle.fans
Too good NOT to share.
My brothers and sisters in Christ I want you to know that I care about your souls enough to share these truths with you:
- You don’t need JavaScript to make a web page.
- You don’t need JavaScript to write styles.
- You don’t need JavaScript to make an animation.
- You don’t need JavaScript just to show content.
You must log in or register to comment.
When web development started to move away from jQuery towards Angular, React, Ember, Vue and all that shit I made the conscious decision to stay away from front end development. Well, I already made the decision after struggling aligning elements in all web browsers with CSS.
I’m glad I made that decision.
Simplicity is unsophisticated and lacking in many parts. The simplest solution to a problem is always the best solution. Choose simplicity. I’m begging you. Your future is begging you.
This goes with all of programming. It’s rare someone makes a clever solution that doesn’t immediately turn into “technical debt”.
Hey, I was in a similar situation at that inflection point but veered into PHP application development and couldn’t quite get away from the front end. Let me tell you: CSS Flexbox and Grid are amazing. AlpineJS is “just the good parts” of jQuery. You can go back now. Check out 11ty.
Front end is basically anarchy, anyway. Give me my Django back end development and leave me alone.
But nah. These goobers got high off npm modules and did shots of JSX in the bathroom at lunch time.
Fucking LoL!
Anyone here have thoughts about doing basic interactive stuff with at most vanilla JS?
I think basic or even complex stuff is fine in vanilla js.
The problems show up as you scale the team and code base. You can do a large project in vanilla js but you’re going to have to solve a lot of the same problems frameworks/libraries have already solved. Maybe it’s worth it, maybe it’s not.
On the other hand:
Most Frontends are not super interactive google tables like applications and never will be and frameworks won’t magically make your code maintainable or enable you to work with 50 other guys on that page that interacts with a simple CRUD-API, yet people choose a complex framework meant for huge projects and pile even more dependencies on to of it for that kind of stuff. it’s like using a fleet of 18 wheel trucks for grocery shopping, when a basket and a bicycle are really all you’ll need for that.
i’d guess most websites would be fine and feel “modern” with html, css and a small library for ajax stuff, because doing that by hand is repetetive and error prone.
Vanilla JS is perfectly fine to do basic interactive stuff. Data Binding is a bit trickier but can be achieved neatly with Web Components. I like it.
Yea, I’m unclear on how you can take web components and still have widespread browser support (not knowing enough about their ins and outs).
Plain template elements are widely supported and have been for ~10 years (which ideologically matters to me along the same lines as the top post’s article) … perhaps a little bit of hacking together can get you close with just that?
Every browser released since 2020 supports this (custom elements that is), so I don’t see an issue with browser support.
You mean the Html template Element? I’ve never really got that to work, but I also never seriously tried.
Every browser released since 2020 supports this
It’s a little paranoid of me, but I like the idea that a basic web app I make can be thrown onto any old out of date machine, where ~2015 or younger seems about right for me ATM.
You mean the Html template Element? I’ve never really got that to work, but I also never seriously tried.
Yea. From memory, it’s just an unrendered chunk of HTML that you can select and clone with a bit of JS. I always figured there’d be a pattern that isn’t too much of a cludge and gets you some useful amount of the way to components for basic “vanilla-js” pages, just never gave it a shot either.
No we don’t need it. But is it better if we use it? Like, you don’t need OOP for implementing literally anything either.
When you hold a hammer everything looks like a nail. Just because it’s useful in some cases doesn’t mean it’s always the best solution.
The article mostly rants about front end devs using unnecessarily complex solutions for simple problems. Like using React for generating static web sites.
I get what he means and in most points I agree (I’ve worked primarily as a front end dev so far in my career), but as you get more familiar with these frameworks they tend to be so much faster to iterate on compared to a more “cleaner” setup. I’ve seen plenty of situations where using such frameworks were clearly overkill, but were still much faster to setup and were ready to be expanded on if needed in the future. Everything about the package ecosystem on web dev he’s 100% on point though. Things like the left pad situation are insane.
I feel like this is more like a hammer vs bare hand situation. If the point is there is a place and time for everything (except VBA) then I agree.
extending the list
- You don’t need JavaScript to build web pages
- You don’t need JavaScript to publish web pages
I concur.
Nested CSS obscures complexity
An interesting point. Something I will take with me for observation and consideration.
Maybe sometimes it’s worth despite it and other times not.
The author has an article on the problems with nesting.
which is me. I’m the author.
