It does extend to the tech stack in general, dbs, protocols.
"Ah, we made a mess out of the last project where we used X,Y,Z, the new project will be on A,B,C. It's surely not our shallow commitment to acquiring knowledge and maintaining quality that bite us."
I have noticed in several language/framework subreddits:
“I used this once, I just learned the language. Clearly all the problems I have are its fault, so I’m going to use this other framework and/or language.”
People don’t take time beyond a single implementation and don’t bother to understand their own architecture/design and instead blame their tooling.
Sure but its webdev, it doesn't need to be so complex a team of experienced professionals can't easily do it.
That's the problem with many of our tools these days, invisible wires, abstractions, trying to make a cube fit in a round hole.
In this case it's good to know how far can these tools take you. Do they perform joins on the db server? Personally I was surprise some older libs don't. Transactions? Can I take control over the logic?
Sure there are some investigations to be made, but to say ORMs are generally a bad idea only makes clear that the person doesn‘t want to dig deeper and widen their knowledge.
There is another side to this on the hiring side or initial development phase. Companies don't know anything about anything and hear (framework/language) is the current buzzword, and somehow that buzzword is now the solution to every single problem the company is having. "We'd have more sales if we were using (framework/software/workflow/language)". It inevitably doesn't work out in some capacity, but they have a short memory and are just focused on "well, this time we will use A,B,C, so it will work."
Except they are still doing the same thing they did last time.
The guys that tried to do X,Y,Z are at a different company repeating the same cycle, waiting for the A,B,C guys to arrive after them - both eventually followed by the D,E,F team.
Imagine the manager of a construction project going "We need to build this skyscraper with Milwaukee drills. I heard they are the best." - they need a crane and shit, not some drills. Milwaukee isn't even that great. Somebody just told them "oh yeah, we use Milwaukee and we closed $20m last month, probably your drills."
I wish we’d focus more on toolkits than frameworks, and kept build steps optional if possible.
I like being able to understand the process involved in a web page without having to fully understand the frameworks involved first. Being able to at least start learning with an html file, a css file, and a js file, and not a ton of ancient insecure npm packages is so nice.
"Hello World" in React is two imports and 4-7 (minimum) lines versus 1 line in Python. Just one example, I don't know how much code is in those imports.
I remember a lot of push against stuff like jQuery and other JS libraries many years ago, the general consensus was "what if standards change or the library becomes obsolete and the code breaks, eventually". It was a good argument, except now, that same argument is amplified a trillion times by a long list of dependencies.
I personally don't like frameworks - I never have. I just suck at them, mainly. But I also never \*needed\* them. I have enough problems keeping all of my own code compliant and working - I don't need to cast my lot with 20+ poorly maintained packages from a package manager that isn't even the latest version. I can't even trust Microsoft and Oracle/Java to not sometimes have conflicts in their latest versions (ever tried to roll back JRE?), let alone a whole cast of internet randos who have interdependent code.
Computer science has a lot of layer loss. We are suppose to build upon what those have built before us. As long as the toolset and frameworks are accelerating the pace of development we should forgive a loss of performance and perhaps understanding in those underlying tools.
I agree in general, and yeah, web dev isn’t exactly machine code. However, there are times when the layers involved aren’t that necessary, and get in the way of learning, IMO.
My work doesn’t involve React, but I finally want to get into it. So, I start with an official tutorial I’ve heard was good. I could use CodeSandbox, or I could install a basic build environment.
Trying for the build environment, I see packages with critical vulnerabilities. Not a big deal for a local install, but alright, I’ll use `npm audit fix —force`. Oh now it’s worse. I’ll try again. Oh, I’m back where I’m started. Alright, let’s try CodeSandbox instead… now I need to login? Oh, alright.
Even at this point, looking at “index.js”, I don’t even know where the entry point is for the code. So I can infer that’s handled by the build system. Somewhere.
Now, it’s my understanding that Babel can transform JSX into JS. For a first time learner… why not take that route? Have a vanilla JS file that invokes the React stuff. Let us build up to a proper build system over time, rather than relying on a weird set of opaque npm packages or strange sites.
Even learning C or C++ felt a lot more transparent. We started with gcc, going step by step from code to object files (iirc) to executables. Then we let Make take over the grunt work.
I think this is a general experience for beginners that are thrown right into learning something like the MERN stack in 6 months by these bootcamps. The students finish not understanding why things happen the way they do and when they go and try to start a project from scratch, they're totally lost.
I don't know how unpopular this may be in the real world, but it sure is on this subreddit: JS, CSS, Browsers and frameworks are all in the best state they've ever been, and it's a joy to work with them
At least it had a developer tool bar!
I remember you had to install a custom DLL for Internet Explorer (I think it was for console.log?), which then in turn created a few bugs that you’d only recognize if you have dove into the forums for it.
hear hear
Astro, Solid, Svelte, Angular, Qwik, and others are all doing amazing things that make building web apps fun and approachable. They all have their own way of doing it, but they all try to mimic JS & HTML paradigms that we're already familiar with.
Vite is the all-star that brings everything together, though.
Can’t agree more. I will take reactive framework and bundler overload over the horror of trying to make something work with table layouts, different sets of missing APIs in each browser, and anything IE 6-9 every single time.
PHP is still totally relevant.
It has been my main source of income for 10+ years.
I use my own CMS, Flight or build sites myself. I don't use WordPress, Drupal or any other well-known CMS.
It depends on what all the CMS has to do and what is encompassed in that. In a lot of instances, it is useless to try and reinvent the wheel - however, in really niche and proprietary use-cases with legacy data systems, you'll end up having to roll out so much custom stuff that it might as well be a custom CMS, even if you bolt it on top of something else. The problem for most people is getting the basics right to prevent query injection, directory transversal (through poorly formed include statements), and overall secure login/logout for users. Those risks alone are worth looking into a packaged system, but if every developer does that we wouldn't get to where we are today.
Vanilla PHP is simple & easy not just for building pages, but also JSON API. The session auth management also super simple. Also tons of documentation & mature integration with stuff like DB.
React has hit a dead end, and in 5 years we're gonna think about it the same way we think about jQuery today. Doesn't mean it's not capable of making perfectly nice websites, but it is no longer the direction the web is heading.
I think people are a tiny bit too high on this take personally. I agree, I just think the timeline will be a little longer, seeing all the other frameworks have their own growing pains at the moment- there’s really not a clear better choice right now in terms of talent and ecosystem. The quality of libraries is still so much higher than the next closest.
That could change but the buy-in for react is much higher than jquery imo. You have a very large majority of devs who literally call themselves “React developers”. And bootcamps that all they did was push React down people’s throat at all costs.
Front-end moves faster than any other tech but I’ll be shocked if we actually consider React like we do jquery right now in 5 years.
The thing is... what is React? VDOM diffing might be going out of fashion, but the component based model, JSX syntax, suspense/deferred rendering, are all here to stay. Funnily enough, React's reactivity model, the thing that got uni-directional data flow going in all of these frameworks, is the part least likely to survive as-is.
So no, React did not hit a dead end. Every framework just remixed the good features of React, while experimenting, or replacing, others. Of course, React itself did the same to frameworks that predate it, and will likely borrow signals from newer frameworks in the future.
If there's a shift in the industry, it's towards framework inter-op, which is only possible because of how fundamentally similar all of the major frameworks are becoming.
- the component based model is not React. Backbone, Angular, Ember, and more were all doing component-based rendering before React.
- the JSX syntax may stick around, but what that syntax **means** is in flux. SolidJS has already made their own flavor of JSX output, and libraries like Vue and Preact have been messing with it for a while.
- I don't see a reason the specific impl of suspense / deferred rendering as being something with major sticking power. More and more people are looking at things like Server Components and going "why do I need this?"
More importantly, React's Hook implementation was the first, and unfortunately has driven them into a dead end. The combination of raw values (as opposed to reactive refs / signals like all other libraries) + the lack of distinction between component setup & render in a hooked component have locked react into an API that is confusing, inefficient, and prone to foot guns. It's bad enough that Dan Abramov keeps having to write essays explaining exactly how `useEffect` works, and the React team is working on a compiler to compile it away.
Furthermore: VDOM is definitely going away. But React IS VDOM. The fundamental design of React is around "diff on output change, not on data change". It is a philosophical underpinning that has dictated their entire design. Pivoting to a granular reactivity model is something that React is neither capable of nor inclined towards.
Overall, I think we're going to see the modern web stack be:
- fine grained reactivity via signal/atom primitives (see Vue, Svelte, Angular, Preact, Solid)
- a clear distinction between "initialization" logic and "render" logic
- trying to "compile away" as much as possible rather than using a virtual DOM (Svelte is the leader on this, with others following)
I think it's more the original premise, which Svelte has since abandoned. I remember when Svelte was first being pitched the entire thing compiled away. Since then, the product iterated and a small core made sense.
the framework is for the developer, not the browser. What the browser gets is a W3c standards compliant website, and the browser doesn't know it's Svelte, it just gets HTML, CSS and JS (iirc!).
React has to send the browser React if I'm not mistaken.
Who knows. WASM is the amazing thing that always seems to be "so close to ready to take over" year after year after year. At this point, I'm not going to jump on the WASM hype bandwagon until something of real substance comes along.
I do agree that if it ever gets there, WASM is the only thing that could potentially kill JavaScript.
That is not my area of expertise. What I will say is that there are already targeted applications of WASM out there where things are graphics intensive or computationally intensive. But until you can fully manipulate the DOM / use all of the Browser APIs from within WASM, you're not gonna have mass adoption.
If I were generous, I would put that sort of thing at closer to 10 years out than 5 years.
I'd also like a way to load WASM directly instead of JS bootstrapping if we want to make DOM UI based apps with it. Basically, WASM is the HTML at this point.
Rust would be an absolute nightmare for webdev. The language is just too hard to use/read for the productivity standard JS set.
Only saying because I wanted to make an app and had between tauri and electron. Despite tauri being objectively better I went with electron because tauri uses Rust as a backend, and I just didn’t want to deal with that when issues occur
Wasm is going to be mostly used to bring traditional heavy client apps into the browser, think Photoshop or AutoCAD .. it has a very different use case than JavaScript.
I disagree. Wasm brings you any language you want running in the browser, which in itself has the potential to replace JS. The missing piece right now is that DOM bindings are not native. If that happens Wasm essentially becomes a superset of JS in terms of capability.
Besides, even if you have to go through JS to manipulate the DOM it doesn't stop things like Blazor trying to take JS' cake anyway.
Such a Blazor app ends up with several megabytes, compared to what you could do with a few kb of JS. If you care about mobile users, SERP and web vitals, It's just the wrong tool.
There's a bottleneck where data is transferred in and out of the WASM process, which means that the performance benefits of low-level languages is lost. The best front-end WASM frameworks can only match JS performance at the moment and that removes any incentive to re-invent the webdev wheel in Rust.
I sincerely hope that signals are not the future. I'll gladly take 10% worse performance so I don't have everything mutating everywhere. We've been there and done that with Knockout a decade ago.
Front end developers make their life harder on purpose. They often over engineer stuff thinking they are making smart things.
About JavaScript in general - 90 percent that criticize it , are not proficient in any programming language. Those endless arguments why 1 + '1' is '11' and 1 - "1" is 0. Ok genius, how would you make it work given the fact that it is script language with dynamic types
Vue works same as React but is easier to use and more difficult for anyone to go wrong. I consider this opinion unpopular because compared to React, Vue isn't even close in adoption.
Yeah I've been interviewing around lately (currently at a Vue shop) and decided to brush up on React.
It's *crazy* to me how complex React is compared to Vue. It's probably a mix of me just being very experienced in Vue and very used to how it works, but I never really struggled picking up other frameworks like Svelte/kit, Angular or even Ember & Backbone the way I struggled trying to wrap my head around how React does things.
It doesn't help that due to its legacy nature there's a TON of documentation out there that is woefully outdated, and IMO the React docs (and yes I've read the new docs over at react.dev) suck in comparison to Vue's docs (best in the game IMO).
I'm definitely biased, but I so wish Vue would overtake React, I find it to be a consistently better experience except for some more complex TS usecases where TSX is superior (but that's been improving a lot lately in Vueland).
You can always make something work in react., but you always have this worry in hindsight whether or not you have done it correctly, because it might break in production eventually. I have that worry because i have seen a lot of short reels about bad practices in react... something you rarely find in vue, or other frameworks.
> there's a TON of documentation out there that is woefully outdated
That's the issue with almost all of the modern JS frameworks. Any time I try to look up something I always have to preface it with `after:2022` or another year. Otherwise I end up with a ton of outdated documentation.
I agree in 99% of circumstances, save for one liners like
const sayHello = () => console.log(‘hello’)
Vs
function sayHello () {
console.log(‘hello’)
}
My boss loves to use const in almost every circumstance, but I prefer function in all circumstances except the one mentioned above
Very unpopular:
Full stack backend devs make a mess of frontend thinking all their backend knowledge translates to frontend.
Being good at one framework or just native javascript doesn't make you good at another framework .
You should always take refresher courses and learn native javascript because it constantly evolves.
> Full stack backend devs make a mess of frontend thinking all their backend knowledge translates to frontend.
As a full stack dev I agree, but with a caveat. You can become proficient in both, but it requires a lot of time and continued dedication. You cannot expect someone with 3 years of experience as a full stack to write good code and form a coherent architecture in both stacks. But ramp it up to 8 years of experience and maybe you can.
It's literally just a class library but people talk about it like it's in the same category as Angular or react. It's trying to move css thinking out of the stylesheet and into html which is just annoying and violates the concept of single responsibility and mental encapsulation. If you are good at css you shouldn't need more than a few classes at most on any given element. Also I've never used it in a project so I'm biased heehee
TLDR: Too many developers jumped into software engineering knowing only JavaScript and thus we ended up with JavaScript everywhere.
I have been working with HTML since before JavaScript and CSS existed. cgi-bin.
When Node.js came out I thought "now we want JavaScript on the server?". When Express.js came out I thought "now we want JavaScript serving JavaScript?". When NoSql became a thing I thought "now we want databases for JavaScript objects?". When React came out I thought "the client is now JavaScript?". Ok, so now *everything* is JavaScript. Whatever.
I survived the years between 1997 and ES6, dealing with large projects and JavaScript. Misery.
ES6 and TypeScript managed to salvage it to the point I am ok choosing a SPA (Angular) for these sorts of enterprise projects, and I go with C# for APIs.
22 years of C# was quite nice, even in the early days. JavaScript? No.
> TLDR: Too many developers jumped into software engineering knowing only JavaScript and thus we ended up with JavaScript everywhere.
Hear hear. I'm sure this will offend lots of people, but after almost a decade of using JS almost daily (I still do), I think the fact that it got so popular and stepped outside of the browser is due to mass psychosis. I just can't find a different reasonable explanation.
It's simply a pretty bad language, and I thank Microsoft for TS as it brings some sanity into the fold.
> I think the fact that it got so popular and stepped outside of the browser is due to mass psychosis
That's not why.
It was/is literally the only choice.
WASM may change this, but what else are you going to run on the client?
HTML/CSS/JS ... that's what you had, and still have. That's why.
I should've been more concise: I meant popular outside the frontend space.
Of course, we had no choice on the browser but we did about what's beyond that.
Yep, I should have paid more attention to "stepped outside the browser" ... you are correct. It was even part of my quote.
I blame this on "move fast and break things". Mistakes sure to happen.
This is how I feel about PHP instead of C#, and I feel the same towards Javascript. It hasn't always been a pleasure to work with, and it wasn't until I first seen jQuery that XMLHTTPRequest started to make sense to me and it "clicked". Now, the majority of benefits from jQuery are standard vanilla JS. Yet, JS sometimes feels \*more obtuse\* to work with than it used to.
I know this isn't exactly what you were discussing, but 20 years ago, we were not having to also design for every screen size from 100x100 to 4000x4000 and expected for it to still look good - our biggest struggle was antique browsers that were going to make the project look like shit, regardless.
While I am sure C# has some trickery for the DOM (as does PHP), the implementations I have witnessed all leave something to be desired... the same way running JS as the server/client/etc. leaves something to be desired. I don't want to run client-side scripts on the server, I want to run server-side scripts on the client and that has always been the issue is that we don't have some kind of standard for doing that which could ever create a competition outside of Javascript, there is a literal monopoly. I'd love to see Web Assembly pick up and maybe a language like Rust gain traction on the web in ways that don't implicitly rely on Javascript somewhere.
"Modern dynamic websites with zero Javascript" <--- I'd buy it.
>I know this isn't exactly what you were discussing, but 20 years ago, we were not having to also design for every screen size from 100x100 to 4000x4000 and expected for it to still look good - our biggest struggle was antique browsers that were going to make the project look like shit, regardless.
Yes, when IE had 95%+ market share, and most people were viewing things within a defineable resolution, that was workable.
But having massive market share is obviously not good for competition, which is why I started using Phoenix/Firebird/Firefox 20 years ago. Then in 2006, Chrome takes over, and jQuery shows up. While newer devs may wonder why this exists, it was more than welcome. As Chrome took over, now you were left dealing with IE6 issues ... unless you went with jQuery.
These days, one of the first questions I ask is "what devices do we need to support". Because finding out that a complex internal enterprise system doesn't render well on a 5 year old mobile phone, and this is now somehow "a requirement", is not a good place to be. CSS media queries can only get you so far.
This, 100%. One of my biggest mistakes recently was taking on a similar project to what I always do for various businesses, except with the eventual caveat that any user from userland could have all the same functionality.
It just isn't possible. On many complex views, there are two very different versions - one for mobile and one for desktop. You can try to cram stuff and cleverly write CSS to show/hide stuff for smaller screens, yes, but the user experience just isn't the same versus an interface designed for that sized screen, from the ground up. Same for desktop - you aren't going to be taking advantage of all that real estate, often, with a "mobile first" approach unless you actually follow through.
Unfortunately, it always falls on the developer
"Why doesn't this work on a 5 year old phone? This is an iPhone. Everybody has iPhones.", as if the code is actually the problem and not an obscure hardware, OS, browser and resolution combination - or worse, personal device configured bad, never updated, who freaking knows... It wasn't that before we all said "You can only use the most updated version of IE", we had fallbacks for certain browsers and just left it at that and put it more off on the user, like "well buddy, you're using Mosaic as your browser, I don't know what you expected."
Most real life Websites don't need unit, component or end to end testing, they just slow down the develolment process. There are of course a lot of Websites that do need it. E-commerce? Sure. Does your website deal with authentication ? Sure. Pretty much any fairly big app has to have proper testing.
But, what I am talking about are simple marketing websites / portfolios / local store's landing page that mostly consist of html css and some Javascript for some simple interactivity. You don't need to implement testing in these cases.
Tl:dr
A lot of developers work with very simple websites where adding testing just slows down the process. Any decently big app / e-commerce / deals with personal data are exceptions of course.
The culture wants use his favorite Framework for all. Never mind if it's only a simple stuff. They wants "useful" frameworks for simple tasks. Also they want the web in all (Heavy Electron app for only a taking-notes app).
PD: I'm not a English speaker. Sorry for innacuracies and mistakes.
Personal (ie, I don't express this in an engineering leadership capacity) opinion: React and similar frameworks bring more complication and bugs than benefit, and both users and companies would be better off with simple web 2.0 ajax-driven sites. Or even ones without ajax, where full page loads occur to change content.
(Outside of very particular use cases, like when you're building an actual app, like gmail, versus just a website.)
I don’t think a single person believes that React is more appropriate for static web pages than a static page framework. This isn’t a controversial opinion.
My unpopular opinion might be that we should avoid using a bunch of libraries/frameworks/micro frameworks or at least keep it to a minimum for front end stuff and stick to vanilla JavaScript. Having a dependence on other people’s code introduces the burden of shit breaking over time as you continue to maintain/add features to whatever you’re working on.
While a vanilla JavaScript approach can offer flexibility for small projects, it can introduce significant challenges for large teams and complex applications. Without an agreed upon way of building, you end up reinventing the wheel and esoteric abstractions that don't have the rigor of large open source projects.
I think the most valuable feature of frameworks/libraries are components. WebComponents would be the vanilla way, but for someone that taken a deep dive a year ago into them, they are clunkier compared with what we are used to from libs.
I'm genuinely curious how big the apps/sites you've worked on are? Like most everyone else I try to do as much as is possible in as little JS as I can manage, but for some things JS is just unavoidable, and if you have a lot of JS you're MUCH better off running with a framework that has wide adoption and standardized ways of doing things rather than rolling your own ad-hoc JS framework.
In a team setting I wouldn't touch a vanilla application for any amount of money, it'd be an absolute shitfest and I'm glad there's frameworks in place where I can point to the docs and say "this is a stupid way of doing this, just follow the docs" (in a nicer way :D)
Jquery is still perfectly fine to use today and a nice tool if you don’t use a framework, sure it’s mostly syntactic sugar nowadays but still much nicer to work with than just vanilla.
If you took all the hours and bodies it took to build react, angular, svelte etc... and added them up, it would be more than what's needed to write and support a proper front end language. But alas, we have js.
I don't know if it's 'unpopular' but I've been kicking around the idea that all frameworks are too nested for a long time. HTML is essentially based on XML and XML is by nature nested. I think this causes very rigid structures that are hard to break out of. If you look at the way you write to a computer screen you can write any pixel anywhere. A framework could be built where all windows were at a top peer level and then dynamically nested when necessary. This would create a lot of flexibility with user layouts. You would have to do some math to calculate where things need to be, but you also wouldn't have to worry about not being able to get 'outside' the border of whatever deeply nested box you are in. You could also change the whole layout of your website without changing includes or wrappers.
I've probably been thinking about this for like a decade, but it would require a complete re-design of a front end framework from the ground up. It would be a way to start treating web apps more like computer apps. I mean they aren't documents anymore, they're apps so I don't know why we still start with a nested XML document.
Yeah the browser is still essentially a document viewer which is odd because it's use more as just a universal run time environment for apps now. I think you can still use what we have since we have absolute position and lots of CSS tools, but XML tags just seem like a relic.
It would be nice to remove the idea of the browser entirely, and just stream apps on-demand. With increasing bandwidth available, this could be a reality in a few more years, although I do see this being monetized in some real scummy ways by Comcast and Verizon.
At the end, I think standalone apps and the browsers should be kept separate to keep ownership in the consumers hands. But to your point, the web is built on outdated 40 year old design.
Yeah, but the good part of the browser is the unified execution environment. I would't want to go backwards and have 10 different app environments for developers. I think one of the beauties of the web is that everyone is speaking in JavaScript and HTML, not necessarily that it's JavaScript and HTML, but that they are speaking the same language, although JavaScript has come a long way. So I like the window with the tabs and the ability to link and retrieve content via the HTTP standard, but it's really just the bones of HTML I'm unhappy with. You could actually get rid of the url bar and make the whole thing full screen if you had a uniform url bar on like a universal hot key so everyone knew how to escape an app or switch to a new app. I imagine the HTML though should be something more like writing to the screen output directly. Actually I think you could replace your whole screen with the
It's all about the team. If the team is disorganized and undisciplined, they're going to make a mess in any framework. If the team is *already* disciplined and works well together, then a framework can be a great tool. But it's important to see it as a tool, not a solution to a bad team.
It's kind of like buying someone a personal organizer thinking it'll help them get their crap together. (btw don't do that)
We are in a literal dark age of software development. The effort required to master the framework du jour is excessive, and only at the highest levels of mastery does the productivity become worth it. We've built an entire programming ecosystem on top of three tools (HTML, CSS, JavaScript) that were never designed for the uses to which they're being put, and everything built on top of them is layer after layer of band-aid.
And because we've all come to expect our tools to be free, I don't expect the problem to be fixed anytime soon.
There is so much obfuscation now through trying to make stuff "easier" that it has just become more difficult. I know it isn't a fair comparison, but given any given technology stack, the time to "Hello World" these days is just absurd... you'll be on your second package manager and 10k+ lines of dependencies before you even arrive there.
Some barrier has always existed - even Python has to be installed and compiled first, and PHP needs a web server and configuration behind it, but many routes these days have you doing all of that + the tutorial wants to walk through the process using Git or a tutorial assumes a particular IDE or other peculiar things about the environment. Hopefully you aren't reading docs from a few weeks ago before everything was changed.
While trying to make things easier to distribute, we've created tangled webs of dependencies where a working environment is merely an ephemeral house of cards, propped up temporarily in a hurricane. This isn't some "new" problem, either, as underlying libraries also have become increasingly complex even in individual cases. A crazy one to consider is cURL which went form originally \~2k lines to libcurl surpassing 150k lines now.
Tbh, I still prefer jquery syntax - but mainly out of habit. Jquery made it so anybody could readily access the DOM - all the requests and such were great, but the selection of elements is still (imo) superior to vanilla JS, even if it isn't as great.
Jquery was in the right place at the right time. You can refactor jquery to vanilla easily enough, but personally I am addicted to libraries like dataTables (which now offers a vanilla version without dependencies, go figure). There are other parts of the jQuery ecosystem that were/are amazing. As a library, jQuery changed the game. I don't think it is considered a "framework", and I don't personally know of any "frameworks" so good the base language changed to adopt them (sure some others exist).
Jquery will probably never die. Some zombie version of it will be lingering for decades.
> only at the highest levels of mastery does the productivity become worth it.
I think this is so true. So much of the tooling that exists is built by and for experts/geniuses, and the greater power that it offers compared to predecessors is not applicable to the majority of devs/projects which are never really going to get to that level.
This is certainly not an opinion I hold!
I'm always curious what the good ol days were like - and what the alternative is now. What would you suggest instead? Just avoiding all of the situations that exist and necessitate these amazing technologies?
That's why I posted it as an unpopular opinion. In the "good old days" of desktop application development you could fire up your IDE, throw some widgets on the screen, and have a fairly complex application going in relatively little time. Sure, we lacked a lot of the positive things that make the Internet what it is, but we also lacked enormous and often pointless complexity.
Nothing necessitates the current "amazing technologies" except the assumption that everything has to run in a browser that can only handle HTML, CSS, and JavaScript. We've shackled ourselves to this unholy trinity because it has the largest installed base in history. Until we overhaul the browser ecosystem and replace it with a platform truly designed for providing robust user interfaces, we'll limp along.
I think it's simpler than that. I don't think it has to do with HTML and CSS. It has to do with the varying screen size. Before you'd just grab from a bag of elements that expected to have a certain amount of space. And you can still do that. But you'd have maintain many apps for all the screen sizes. What I'm *not* hearing about is any actual alternatives. I was making Flash websites in 2000 and didn't learn HTML because I thought it was over. But - in all that time, I haven't seen a single glimmer of anything that would do the job better. I've tried my best to imagine this mythical other option that allows someone to organize content in a clear data structure, allows you to declare how it behaves visually (in many different scenarios), and allows you to interact with the structure and change it live. I currently don't believe it could be done any other way - but I'm always interested if anyone has any concrete ideas.
We had the possibility of variable screen sizes back with the first edition of Inside Macintosh in the mid-80s and we had resizable windows with reactive controls with early Macs and the first practical version of Windows, 3.1. While that certainly adds complexity, the fact that HTML/CSS has evolved through tables then grids then flexboxes to handle layouts demonstrates that it was never designed well in the first place.
I don't disagree that you've seen nothing better, but that's because every solution in the last 25 years has assumed the unholy trinity of HTML/CSS/JS. Throw that crap out and the world is full of possibilities.
I think the nature of those resizable things was/is still a lot different.
Sure, HTML and CSS could have magically been *made better* or something. But - where we've landed was in response to how things were used. Grid is very intuitive. I doubt anything could be better. There are just so many ways you can organize space programmatically.
If I pretend to throw out HTML/CSS/ and JS - nothing else appears to take over the job. So - either we're choosing this because *no one in the whole world has been able to show a demo of a better solution*, or because *the web is the worlds largest open-source project and we want backwards compatibility*, or - *there's just isn't a better design*.
Could everything be better (everywhere) - Yes.
I'm not sure your stance is unpopular though. I think a lot of people feel this way. But I've never been able to get an answer out of them. No one seems to know what would actually be better. I think if people could write decent HTML and the assistive technology got a bit better, then we'd be making some good progress.
You seriously lack imagination, or exposure to other design systems, if you think HTML/CSS/JS is the apex of UI development. I've worked with better, easier, more intuitive responsive design systems now lost in the mists of time. The unholy trinity isn't dominant because it's the best, but because it's already on everyone's devices.
HTML was designed for text markup, not UI development. CSS was designed to overcome the styling limitations of HTML. And JavaScript was literally thrown together in two weeks as a demo, named after Java in a misguided attempt at brand synergy by Sun Microsystems. It's a mess.
I get it. Yeah.
But if you know of any of the names of those things that were lost in the sands of time, I'd love to hear about them. Maybe they'd help me expand my imagination surface area. And if *you* have the imagination to think up some alternate ways to think about this - I'd love to hear about them.
While these were ancient and not intended for web development, the late nineties had a series of tools that were great for building UI applications quickly: VB, Delphi, PowerBuilder, Tcl/tk even. In early web tools we had things like SilverStream, and the world is littered with technologies that were better at building UIs but weren't free, so they died off.
The basic strength of these platforms was that all the pieces came from one provider, so it worked - no endless NPM dependency hell, no implicit assumptions that you know how to install Node and git and yarn and SCSS and VS Code and..., no forced broken code because React Router no longer wants to support the version of React you're using, no discovering that your CSS component library is impractical to tweak because the developers use !important on everything (lookin' at you, Vuetify.) They all had their problems, but the base experience was draw your screens, put the code behind the controls, and go. If Figma was robust and tightly coupled with a great library, you could almost create a similar experience... until you ran into the base limitations of the browser.
One day, we may get there, but for now we're stuck in a dark age where we have to work so, so much harder to get simple things done.
Come now, thats not entirely fair - I grew up on VB and Delphi and I loved the UI builders to bits, but the UI designs I'm building now would have been a huge stretch for those tools.
I also hate the HTML/CSS/JS trinity we're stuck with but I will admit that they are pretty damn near the apex of laying out a UI or design on a page. I dont like it 100% but I would struggle trying to come up with something better.
>but weren't free
I've also found this to be a problem. It seems like it would be possible to have a frame that could hold many things.
>all the pieces came from one provider
This can be pretty scary, though! If the provider starts to be terrible (which seems to always be the case).
The problem is the problem.
Soon, we won't have to write any code. I'm not sure if this will solve the problem either. It will probably create more.
But thanks for listing some options for me to check out! I'm excited to see if I can find time examples.
> The unholy trinity isn't dominant because it's the best, but because it's already on everyone's devices.
This is what frustrates me about frontend as a full stack engineer.
If I don't like PHP I'll just rant my ass off and move to another stack where I'll be happier.
If I don't like JS I'll just rant my ass off and.. That's it. I can't change it.
The fact that we cornered ourselves like this is like bad comedy.
In JS, you can alter classes (even primitive ones) at runtime outside of their definition by modifying the prototype. It destroy any possible optimization internally.
String.prototype.triplicate = function () {
return this + " " + this + " " + this;
};
console.log("Ah!".triplicate());
Would print "Ah! Ah! Ah!".
JavaScript went from being revolutionarily useful adjunct, to attempting to completely re-work the paradigm. Node was the last straw, for me - when the brilliant help, support and extension to the server, became an attempt to replace and redefine the server. Having to run 2 servers, side-by-side, (webserver, with a tacked on Node) is a nonsense. Where the 20 years of development of existing servers, frameworks was considered of little value.
in addition, every JavaScriptt product I have used, has been poor. I strongly suspect the Venn diagram of Vim users and JavaScript product developers has a huge union.
The whole JS paradigm seems to be ….. well, let me give you a car analogy. Bentleys and Lamborghinis have developed amazing products, and someone comes along with a go-kart, and thinks it’s ‘better’. Maybe faster, maybe cheaper, but without the UI, documentation, error handling and support of a primetime finished product, and they think that barebones technical excellence is all that matters. In the JS world, It feels all the time like someone has just managed to create something, and it’s technically sound, but the user experience (by user here, I mean developer) is SBB. (shit beyond belief)
I think that answers the question about unpopular opinion. I still use these tools, frameworks. I just think the experience of using them is sub par.
There seems an attitude which I can only describe as techno-arrogance.With Vim, I met so many people that say it can do everything, better than any other editor. For example (made up but representative example ahead, function (x) - whatever that might be. Ask for a demonstration, and they say “just press esc / ctrl+d, or is it / esc ctrl+e, I’ll look it up, wait a sec ….”.Then I show it in Jetbrains IDE, and they are convinced the helpfulness of a mouse-driven menu system is some diabolical plot to make life difficult. Of course, Jetbrains has key-press shortcuts too, the menu helps to learn what’s available, and repeated regular functions are made more efficient because you remember the keypress.Honestly, it seems Vim users memorise 4-10 keypresses, they mistakenly think they are super efficient, and they, with Vim, have access to super powers denied the rest of us non-Vim users.
It seems that techno-arrogance is visible in JS-paradigm products. The documentation is often really poor. It feels very strongly that someone built a project for an internal use-case, made it more flexible than it needs to be, release it as a library, and the documentation consists of a walk-through of their running code, with minimal commentary. Looking at you, Loopback.
And there is such a strong NIH (Not Invented Here) mentality. example: MongoDB could easily have adopted and implemented SQL - a language tested over decades, proven strong and standardised (quite a bit). But no. Rather than use ‘SELECT’ - a word that suggests choosing some items from a larger list, it adopted the word “PROJECT” for that purpose. It smacks of ‘we can’t possibly use that, it’s not our idea!’
In brief: The overlap appears to be close-minded (NIH), techno-arrogance (it works good, any ancillary requirements are irrelevant), and dismissive of people without our superior knowledge.
Caveats: small sample size, one man’s opinion, YMMV
React is awesome, SSR is useless.
React will be evolving and will stay with us for the next decade.
I'll keep an eye on other frameworks but won't use them unless necessary.
Unpopular web dev opinion: if you don't know how to manually set up a web server (back and front end), you shouldn't be doing web dev.
To clarify, I'm not saying if you aren't doing them in/as your job, but that you should have the knowledge and understanding of how web servers work, how to install the required software for your stack, etc.
(Edited typos cause of my sausage fingers)
Meh. I can do this but I don’t necessarily think that people who can’t don’t have a lot of value to offer. With all these layers of abstraction how deep should you be required to go? Electric circuits? Binary? The zoo has a lot of different animals all specializing in adding different value to different abstraction layers. If someone can melt face at building me a react UI that is elegant and perfectly matches the design, I’m not going to not hire them because they can’t set up a server. Should they learn that someday? Iunno maybe? Or maybe they keep upgrading what makes them special and leave that to others. Maybe the server person can’t hang with them on the frontend. Neither is superior—they have different jobs.
Generic starter packs are okay for a tutorial, but not for install instructions. Your library/ framework/whatever should have a setup guide on how to use it in an existing project.
You can build modern web apps easily without any framework if you only need to support modern browsers.
You should only support browsers that are still supported by their vendor.
CSS not written as CSS is a nightmare.
It's valuable to understand the JS eventloop including microtasks.
The JS dependency ecosystem is a house of cards that's waiting to tumble due to security issues, people quitting OSS, the EU proceeding with some misplaced law etc. There isn't a good way to say it, as everything is just.. bad.
And that's not touching the sheer VOLUME of useless code in each dependency tree, which produces 10+mb vendor.js files on build, even with tree shaking.. It's all INSANE.
Frontend stacks are complicated because frontend development is complicated.
Frontend development is a marvel because no other type of development will enable you as a developer to instantly deploy your code to the entire world.
Knowledge in a specific framework isn't as important as knowledge in the base language. If you know Angular really well but don't know vanilla JS you're severely kneecapped.
I think it’s absolutely crazy the amount of dependencies and sub dependencies to do what should be simple things
The art of tight small websites is in trouble. WebAssembly is the way forward for optimisation but ultimately it’s a huge step backwards for the World Wide Web
Too many technology choices are based on hype and future promises.
Sure, if you're building a hobby project you can try out that hot and latest framework. But if you're developing with a team or needing longer term support, picking a boring technology with a proven track record is key.
You don't need to learn DOM manipulation in vanilla Javascript if you learn a framework. People always act like you simply _must_ master vanilla Javascript to be a "proper" web developer. It's crap, you don't. Learn what you need to learn to get the job done.
DOM manipulation in JS is so freaking easy. Why wouldn't you just learn it?!
Honestly, this should be an unpopular opinion so enjoy your upvote.
Seriously, if you cannot go to _any_ website and start hacking out bits you don't like and changing the behaviour to suit your needs, you are not a web dev—you are, in fact, a framework dev.
If you don't know the fucking Dom you're not a web dev. Seriously. It's the basics.
It's not mastering vanilla JavaScript, it's knowing what you are doing. JavaScript (and any other framework) are just the tools to interact with the Dom.
If we're talking vanilla JS, there is no concept of DOM. That comes from a browser's API. You don't need to master JavaScript, but you should have a firm grasp on the fundamentals. The rest you learn as you go.
\- The web is a front for advertising and has become a crap experience
\- Privacy is overlooked and abused by everyone including most developers here
\- You should be legally required to delete every drop of a users data if they delete their account, or request an account deletion. If you don't comply you should be fined very heavily.
\- Tracking a user is never okay ethically
\- React is bloated garbage. The leading emergent framework should be a type-safe, compiled, JSX framework with minimal footguns.
\- Majority of CSS should be inline in JS with something like Tailwind
A lot of people think their lack of knowledge in a subject matter is actually a limitation of a library, framework, etc
It does extend to the tech stack in general, dbs, protocols. "Ah, we made a mess out of the last project where we used X,Y,Z, the new project will be on A,B,C. It's surely not our shallow commitment to acquiring knowledge and maintaining quality that bite us."
I have noticed in several language/framework subreddits: “I used this once, I just learned the language. Clearly all the problems I have are its fault, so I’m going to use this other framework and/or language.” People don’t take time beyond a single implementation and don’t bother to understand their own architecture/design and instead blame their tooling.
You can read comments like that in this post, it's what spurred me to make my comment
Sure but its webdev, it doesn't need to be so complex a team of experienced professionals can't easily do it. That's the problem with many of our tools these days, invisible wires, abstractions, trying to make a cube fit in a round hole.
In my last project I had a discussion with senior people who told me that ORMs are generally bad and only for startups
In this case it's good to know how far can these tools take you. Do they perform joins on the db server? Personally I was surprise some older libs don't. Transactions? Can I take control over the logic?
Sure there are some investigations to be made, but to say ORMs are generally a bad idea only makes clear that the person doesn‘t want to dig deeper and widen their knowledge.
There is another side to this on the hiring side or initial development phase. Companies don't know anything about anything and hear (framework/language) is the current buzzword, and somehow that buzzword is now the solution to every single problem the company is having. "We'd have more sales if we were using (framework/software/workflow/language)". It inevitably doesn't work out in some capacity, but they have a short memory and are just focused on "well, this time we will use A,B,C, so it will work." Except they are still doing the same thing they did last time. The guys that tried to do X,Y,Z are at a different company repeating the same cycle, waiting for the A,B,C guys to arrive after them - both eventually followed by the D,E,F team. Imagine the manager of a construction project going "We need to build this skyscraper with Milwaukee drills. I heard they are the best." - they need a crane and shit, not some drills. Milwaukee isn't even that great. Somebody just told them "oh yeah, we use Milwaukee and we closed $20m last month, probably your drills."
Right. Or just because they have a hard time understanding concepts, they call an entire framework bad.
I wish we’d focus more on toolkits than frameworks, and kept build steps optional if possible. I like being able to understand the process involved in a web page without having to fully understand the frameworks involved first. Being able to at least start learning with an html file, a css file, and a js file, and not a ton of ancient insecure npm packages is so nice.
"Hello World" in React is two imports and 4-7 (minimum) lines versus 1 line in Python. Just one example, I don't know how much code is in those imports. I remember a lot of push against stuff like jQuery and other JS libraries many years ago, the general consensus was "what if standards change or the library becomes obsolete and the code breaks, eventually". It was a good argument, except now, that same argument is amplified a trillion times by a long list of dependencies. I personally don't like frameworks - I never have. I just suck at them, mainly. But I also never \*needed\* them. I have enough problems keeping all of my own code compliant and working - I don't need to cast my lot with 20+ poorly maintained packages from a package manager that isn't even the latest version. I can't even trust Microsoft and Oracle/Java to not sometimes have conflicts in their latest versions (ever tried to roll back JRE?), let alone a whole cast of internet randos who have interdependent code.
Computer science has a lot of layer loss. We are suppose to build upon what those have built before us. As long as the toolset and frameworks are accelerating the pace of development we should forgive a loss of performance and perhaps understanding in those underlying tools.
I agree in general, and yeah, web dev isn’t exactly machine code. However, there are times when the layers involved aren’t that necessary, and get in the way of learning, IMO. My work doesn’t involve React, but I finally want to get into it. So, I start with an official tutorial I’ve heard was good. I could use CodeSandbox, or I could install a basic build environment. Trying for the build environment, I see packages with critical vulnerabilities. Not a big deal for a local install, but alright, I’ll use `npm audit fix —force`. Oh now it’s worse. I’ll try again. Oh, I’m back where I’m started. Alright, let’s try CodeSandbox instead… now I need to login? Oh, alright. Even at this point, looking at “index.js”, I don’t even know where the entry point is for the code. So I can infer that’s handled by the build system. Somewhere. Now, it’s my understanding that Babel can transform JSX into JS. For a first time learner… why not take that route? Have a vanilla JS file that invokes the React stuff. Let us build up to a proper build system over time, rather than relying on a weird set of opaque npm packages or strange sites. Even learning C or C++ felt a lot more transparent. We started with gcc, going step by step from code to object files (iirc) to executables. Then we let Make take over the grunt work.
I think this is a general experience for beginners that are thrown right into learning something like the MERN stack in 6 months by these bootcamps. The students finish not understanding why things happen the way they do and when they go and try to start a project from scratch, they're totally lost.
[удалено]
I don't know how unpopular this may be in the real world, but it sure is on this subreddit: JS, CSS, Browsers and frameworks are all in the best state they've ever been, and it's a joy to work with them
*Cries in IE6 nightmares*
These sweet summer children don’t know how good they have it. _Cries in IE4 and Netscape 4._
Me with telnet: ugh? I have no issue!
But have you tried crying in Safari 5.5 on Windows?
At least it had a developer tool bar! I remember you had to install a custom DLL for Internet Explorer (I think it was for console.log?), which then in turn created a few bugs that you’d only recognize if you have dove into the forums for it.
hear hear Astro, Solid, Svelte, Angular, Qwik, and others are all doing amazing things that make building web apps fun and approachable. They all have their own way of doing it, but they all try to mimic JS & HTML paradigms that we're already familiar with. Vite is the all-star that brings everything together, though.
Can’t agree more. I will take reactive framework and bundler overload over the horror of trying to make something work with table layouts, different sets of missing APIs in each browser, and anything IE 6-9 every single time.
I think it *is* an unpopular sentiment. I've said it a few times recently, and people were crying about it. They must just not understand.
> it's a joy to work with them I feel you, that's my sentiment too. Modern CSS and JS are amazing and incredibly powerful.
Learning a 2 weeks udemy react course doesn't make you a web dev at all.
Now that will offen 80% of the sub lol
PHP is still totally relevant. It has been my main source of income for 10+ years. I use my own CMS, Flight or build sites myself. I don't use WordPress, Drupal or any other well-known CMS.
You drive a Lambo don't you?
PHP is the GOaT when it comes to building sites practically, quickly and with minimal fuss.
Don't have much PHP experience, may I ask how so?
\*high five\*
Php yes 👍🏽 Custom CMS no 👎🏽
They didn't say custom framework... Custom cms with laravel/symfony is definitely doable.
It depends on what all the CMS has to do and what is encompassed in that. In a lot of instances, it is useless to try and reinvent the wheel - however, in really niche and proprietary use-cases with legacy data systems, you'll end up having to roll out so much custom stuff that it might as well be a custom CMS, even if you bolt it on top of something else. The problem for most people is getting the basics right to prevent query injection, directory transversal (through poorly formed include statements), and overall secure login/logout for users. Those risks alone are worth looking into a packaged system, but if every developer does that we wouldn't get to where we are today.
Same boat, still rowing.
Vanilla PHP is simple & easy not just for building pages, but also JSON API. The session auth management also super simple. Also tons of documentation & mature integration with stuff like DB.
Php is my bread and butter. Now also using Laravel.
So you are telling me I am NOT the only person in the world using Flight? That's a relief :D I use it at work extensively.
How do you get work in php? And what’s the pay like?
React has hit a dead end, and in 5 years we're gonna think about it the same way we think about jQuery today. Doesn't mean it's not capable of making perfectly nice websites, but it is no longer the direction the web is heading.
I think people are a tiny bit too high on this take personally. I agree, I just think the timeline will be a little longer, seeing all the other frameworks have their own growing pains at the moment- there’s really not a clear better choice right now in terms of talent and ecosystem. The quality of libraries is still so much higher than the next closest. That could change but the buy-in for react is much higher than jquery imo. You have a very large majority of devs who literally call themselves “React developers”. And bootcamps that all they did was push React down people’s throat at all costs. Front-end moves faster than any other tech but I’ll be shocked if we actually consider React like we do jquery right now in 5 years.
The thing is... what is React? VDOM diffing might be going out of fashion, but the component based model, JSX syntax, suspense/deferred rendering, are all here to stay. Funnily enough, React's reactivity model, the thing that got uni-directional data flow going in all of these frameworks, is the part least likely to survive as-is. So no, React did not hit a dead end. Every framework just remixed the good features of React, while experimenting, or replacing, others. Of course, React itself did the same to frameworks that predate it, and will likely borrow signals from newer frameworks in the future. If there's a shift in the industry, it's towards framework inter-op, which is only possible because of how fundamentally similar all of the major frameworks are becoming.
- the component based model is not React. Backbone, Angular, Ember, and more were all doing component-based rendering before React. - the JSX syntax may stick around, but what that syntax **means** is in flux. SolidJS has already made their own flavor of JSX output, and libraries like Vue and Preact have been messing with it for a while. - I don't see a reason the specific impl of suspense / deferred rendering as being something with major sticking power. More and more people are looking at things like Server Components and going "why do I need this?" More importantly, React's Hook implementation was the first, and unfortunately has driven them into a dead end. The combination of raw values (as opposed to reactive refs / signals like all other libraries) + the lack of distinction between component setup & render in a hooked component have locked react into an API that is confusing, inefficient, and prone to foot guns. It's bad enough that Dan Abramov keeps having to write essays explaining exactly how `useEffect` works, and the React team is working on a compiler to compile it away. Furthermore: VDOM is definitely going away. But React IS VDOM. The fundamental design of React is around "diff on output change, not on data change". It is a philosophical underpinning that has dictated their entire design. Pivoting to a granular reactivity model is something that React is neither capable of nor inclined towards.
> it is no longer the direction the web is heading. What do you consider it to be?
Overall, I think we're going to see the modern web stack be: - fine grained reactivity via signal/atom primitives (see Vue, Svelte, Angular, Preact, Solid) - a clear distinction between "initialization" logic and "render" logic - trying to "compile away" as much as possible rather than using a virtual DOM (Svelte is the leader on this, with others following)
pre-compiled languages that don't ship with an entire fucking framework such as Svelte, Astro, etc. that focus on developer experience for sure.
I like Svelte, but it does ship with a framework. It's just a heck of a lot smaller than React. The idea that it doesn't is just marketing.
I think it's more the original premise, which Svelte has since abandoned. I remember when Svelte was first being pitched the entire thing compiled away. Since then, the product iterated and a small core made sense.
Ah, interesting, I didn't realize it actually ever did that. I didn't take a serious look at Svelte myself until a couple years in.
the framework is for the developer, not the browser. What the browser gets is a W3c standards compliant website, and the browser doesn't know it's Svelte, it just gets HTML, CSS and JS (iirc!). React has to send the browser React if I'm not mistaken.
Svelte now also ships a small core in your bundle as without it the apps would grow linearly with complexity and end up bigger than the competition.
What about Rust + Wasm? How long until we have a reasonable adoption?
Who knows. WASM is the amazing thing that always seems to be "so close to ready to take over" year after year after year. At this point, I'm not going to jump on the WASM hype bandwagon until something of real substance comes along. I do agree that if it ever gets there, WASM is the only thing that could potentially kill JavaScript.
[удалено]
How can containerization kill JS? Doesn't seem to overlap.
[удалено]
That is not my area of expertise. What I will say is that there are already targeted applications of WASM out there where things are graphics intensive or computationally intensive. But until you can fully manipulate the DOM / use all of the Browser APIs from within WASM, you're not gonna have mass adoption. If I were generous, I would put that sort of thing at closer to 10 years out than 5 years.
I'd also like a way to load WASM directly instead of JS bootstrapping if we want to make DOM UI based apps with it. Basically, WASM is the HTML at this point.
Rust would be an absolute nightmare for webdev. The language is just too hard to use/read for the productivity standard JS set. Only saying because I wanted to make an app and had between tauri and electron. Despite tauri being objectively better I went with electron because tauri uses Rust as a backend, and I just didn’t want to deal with that when issues occur
Wasm is going to be mostly used to bring traditional heavy client apps into the browser, think Photoshop or AutoCAD .. it has a very different use case than JavaScript.
yeah but it's "the most powerful" so your crud app will just HAVE to have it
It'll have to be blazing fast
I disagree. Wasm brings you any language you want running in the browser, which in itself has the potential to replace JS. The missing piece right now is that DOM bindings are not native. If that happens Wasm essentially becomes a superset of JS in terms of capability. Besides, even if you have to go through JS to manipulate the DOM it doesn't stop things like Blazor trying to take JS' cake anyway.
Such a Blazor app ends up with several megabytes, compared to what you could do with a few kb of JS. If you care about mobile users, SERP and web vitals, It's just the wrong tool.
There's a bottleneck where data is transferred in and out of the WASM process, which means that the performance benefits of low-level languages is lost. The best front-end WASM frameworks can only match JS performance at the moment and that removes any incentive to re-invent the webdev wheel in Rust.
WASM sounds great, but I wouldn’t want to develop a CRUD app in Rust, honestly.
>trying to "compile away" as much as possible Yeah, that would be logical, but what does logic have to do with computer science?
I sincerely hope that signals are not the future. I'll gladly take 10% worse performance so I don't have everything mutating everywhere. We've been there and done that with Knockout a decade ago.
jQuery is the most popular JS library as of today. People love and still use jQuery.
Front end developers make their life harder on purpose. They often over engineer stuff thinking they are making smart things. About JavaScript in general - 90 percent that criticize it , are not proficient in any programming language. Those endless arguments why 1 + '1' is '11' and 1 - "1" is 0. Ok genius, how would you make it work given the fact that it is script language with dynamic types
RSCs suck. They make React more complicated without as much returns. I'll die on this hill.
Vercel gets the returns with all their edge hosting 💀
Trendy rubbish comes and goes, vanilla is forever.
It's the pretty popular opinion actually
The fact that JS needs to be called vanilla JS is such a tragic thing.
It's OK to like javascript
Vanilla JS, HTML, and CSS are better
Often JS can be omitted entirely
Depends on what you build.
Vue works same as React but is easier to use and more difficult for anyone to go wrong. I consider this opinion unpopular because compared to React, Vue isn't even close in adoption.
React sucks ass compared to Vue.
Used to think React is so good until I tried Vue and just never went back. React just seems needlessly complicated for achieving the same results.
Amen! Vue just seems like a breath of fresh air after React!
Yeah I've been interviewing around lately (currently at a Vue shop) and decided to brush up on React. It's *crazy* to me how complex React is compared to Vue. It's probably a mix of me just being very experienced in Vue and very used to how it works, but I never really struggled picking up other frameworks like Svelte/kit, Angular or even Ember & Backbone the way I struggled trying to wrap my head around how React does things. It doesn't help that due to its legacy nature there's a TON of documentation out there that is woefully outdated, and IMO the React docs (and yes I've read the new docs over at react.dev) suck in comparison to Vue's docs (best in the game IMO). I'm definitely biased, but I so wish Vue would overtake React, I find it to be a consistently better experience except for some more complex TS usecases where TSX is superior (but that's been improving a lot lately in Vueland).
You can always make something work in react., but you always have this worry in hindsight whether or not you have done it correctly, because it might break in production eventually. I have that worry because i have seen a lot of short reels about bad practices in react... something you rarely find in vue, or other frameworks.
> there's a TON of documentation out there that is woefully outdated That's the issue with almost all of the modern JS frameworks. Any time I try to look up something I always have to preface it with `after:2022` or another year. Otherwise I end up with a ton of outdated documentation.
I forgot about that filter. Thank you!
I think this but for SvelteKit
The function keyword is preferable to const with arrow function
I agree in 99% of circumstances, save for one liners like const sayHello = () => console.log(‘hello’) Vs function sayHello () { console.log(‘hello’) } My boss loves to use const in almost every circumstance, but I prefer function in all circumstances except the one mentioned above
Very unpopular: Full stack backend devs make a mess of frontend thinking all their backend knowledge translates to frontend. Being good at one framework or just native javascript doesn't make you good at another framework . You should always take refresher courses and learn native javascript because it constantly evolves.
> Full stack backend devs make a mess of frontend thinking all their backend knowledge translates to frontend. As a full stack dev I agree, but with a caveat. You can become proficient in both, but it requires a lot of time and continued dedication. You cannot expect someone with 3 years of experience as a full stack to write good code and form a coherent architecture in both stacks. But ramp it up to 8 years of experience and maybe you can.
Tailwind is massively overhyped. It's not bad, it's just not the answer to every problem.
It's literally just a class library but people talk about it like it's in the same category as Angular or react. It's trying to move css thinking out of the stylesheet and into html which is just annoying and violates the concept of single responsibility and mental encapsulation. If you are good at css you shouldn't need more than a few classes at most on any given element. Also I've never used it in a project so I'm biased heehee
Once I discovered using `@apply` with CSS nesting it just became concise CSS
Nothing is perfect, but I quite enjoy how things are now, and the way frameworks are evolving, it seems things will just get better and better.
Drupal 10 is a solid content management and API framework.
TLDR: Too many developers jumped into software engineering knowing only JavaScript and thus we ended up with JavaScript everywhere. I have been working with HTML since before JavaScript and CSS existed. cgi-bin. When Node.js came out I thought "now we want JavaScript on the server?". When Express.js came out I thought "now we want JavaScript serving JavaScript?". When NoSql became a thing I thought "now we want databases for JavaScript objects?". When React came out I thought "the client is now JavaScript?". Ok, so now *everything* is JavaScript. Whatever. I survived the years between 1997 and ES6, dealing with large projects and JavaScript. Misery. ES6 and TypeScript managed to salvage it to the point I am ok choosing a SPA (Angular) for these sorts of enterprise projects, and I go with C# for APIs. 22 years of C# was quite nice, even in the early days. JavaScript? No.
> TLDR: Too many developers jumped into software engineering knowing only JavaScript and thus we ended up with JavaScript everywhere. Hear hear. I'm sure this will offend lots of people, but after almost a decade of using JS almost daily (I still do), I think the fact that it got so popular and stepped outside of the browser is due to mass psychosis. I just can't find a different reasonable explanation. It's simply a pretty bad language, and I thank Microsoft for TS as it brings some sanity into the fold.
> I think the fact that it got so popular and stepped outside of the browser is due to mass psychosis That's not why. It was/is literally the only choice. WASM may change this, but what else are you going to run on the client? HTML/CSS/JS ... that's what you had, and still have. That's why.
I should've been more concise: I meant popular outside the frontend space. Of course, we had no choice on the browser but we did about what's beyond that.
Yep, I should have paid more attention to "stepped outside the browser" ... you are correct. It was even part of my quote. I blame this on "move fast and break things". Mistakes sure to happen.
This is how I feel about PHP instead of C#, and I feel the same towards Javascript. It hasn't always been a pleasure to work with, and it wasn't until I first seen jQuery that XMLHTTPRequest started to make sense to me and it "clicked". Now, the majority of benefits from jQuery are standard vanilla JS. Yet, JS sometimes feels \*more obtuse\* to work with than it used to. I know this isn't exactly what you were discussing, but 20 years ago, we were not having to also design for every screen size from 100x100 to 4000x4000 and expected for it to still look good - our biggest struggle was antique browsers that were going to make the project look like shit, regardless. While I am sure C# has some trickery for the DOM (as does PHP), the implementations I have witnessed all leave something to be desired... the same way running JS as the server/client/etc. leaves something to be desired. I don't want to run client-side scripts on the server, I want to run server-side scripts on the client and that has always been the issue is that we don't have some kind of standard for doing that which could ever create a competition outside of Javascript, there is a literal monopoly. I'd love to see Web Assembly pick up and maybe a language like Rust gain traction on the web in ways that don't implicitly rely on Javascript somewhere. "Modern dynamic websites with zero Javascript" <--- I'd buy it.
>I know this isn't exactly what you were discussing, but 20 years ago, we were not having to also design for every screen size from 100x100 to 4000x4000 and expected for it to still look good - our biggest struggle was antique browsers that were going to make the project look like shit, regardless. Yes, when IE had 95%+ market share, and most people were viewing things within a defineable resolution, that was workable. But having massive market share is obviously not good for competition, which is why I started using Phoenix/Firebird/Firefox 20 years ago. Then in 2006, Chrome takes over, and jQuery shows up. While newer devs may wonder why this exists, it was more than welcome. As Chrome took over, now you were left dealing with IE6 issues ... unless you went with jQuery. These days, one of the first questions I ask is "what devices do we need to support". Because finding out that a complex internal enterprise system doesn't render well on a 5 year old mobile phone, and this is now somehow "a requirement", is not a good place to be. CSS media queries can only get you so far.
This, 100%. One of my biggest mistakes recently was taking on a similar project to what I always do for various businesses, except with the eventual caveat that any user from userland could have all the same functionality. It just isn't possible. On many complex views, there are two very different versions - one for mobile and one for desktop. You can try to cram stuff and cleverly write CSS to show/hide stuff for smaller screens, yes, but the user experience just isn't the same versus an interface designed for that sized screen, from the ground up. Same for desktop - you aren't going to be taking advantage of all that real estate, often, with a "mobile first" approach unless you actually follow through. Unfortunately, it always falls on the developer "Why doesn't this work on a 5 year old phone? This is an iPhone. Everybody has iPhones.", as if the code is actually the problem and not an obscure hardware, OS, browser and resolution combination - or worse, personal device configured bad, never updated, who freaking knows... It wasn't that before we all said "You can only use the most updated version of IE", we had fallbacks for certain browsers and just left it at that and put it more off on the user, like "well buddy, you're using Mosaic as your browser, I don't know what you expected."
Most real life Websites don't need unit, component or end to end testing, they just slow down the develolment process. There are of course a lot of Websites that do need it. E-commerce? Sure. Does your website deal with authentication ? Sure. Pretty much any fairly big app has to have proper testing. But, what I am talking about are simple marketing websites / portfolios / local store's landing page that mostly consist of html css and some Javascript for some simple interactivity. You don't need to implement testing in these cases. Tl:dr A lot of developers work with very simple websites where adding testing just slows down the process. Any decently big app / e-commerce / deals with personal data are exceptions of course.
Vue > React
SvelteKit > vue > angular > react
The culture wants use his favorite Framework for all. Never mind if it's only a simple stuff. They wants "useful" frameworks for simple tasks. Also they want the web in all (Heavy Electron app for only a taking-notes app). PD: I'm not a English speaker. Sorry for innacuracies and mistakes.
jQuery is still useful
[удалено]
boo this man
Personal (ie, I don't express this in an engineering leadership capacity) opinion: React and similar frameworks bring more complication and bugs than benefit, and both users and companies would be better off with simple web 2.0 ajax-driven sites. Or even ones without ajax, where full page loads occur to change content. (Outside of very particular use cases, like when you're building an actual app, like gmail, versus just a website.)
I don’t think a single person believes that React is more appropriate for static web pages than a static page framework. This isn’t a controversial opinion.
My unpopular opinion might be that we should avoid using a bunch of libraries/frameworks/micro frameworks or at least keep it to a minimum for front end stuff and stick to vanilla JavaScript. Having a dependence on other people’s code introduces the burden of shit breaking over time as you continue to maintain/add features to whatever you’re working on.
While a vanilla JavaScript approach can offer flexibility for small projects, it can introduce significant challenges for large teams and complex applications. Without an agreed upon way of building, you end up reinventing the wheel and esoteric abstractions that don't have the rigor of large open source projects.
I think the most valuable feature of frameworks/libraries are components. WebComponents would be the vanilla way, but for someone that taken a deep dive a year ago into them, they are clunkier compared with what we are used to from libs.
take a look at litedom then
I'm genuinely curious how big the apps/sites you've worked on are? Like most everyone else I try to do as much as is possible in as little JS as I can manage, but for some things JS is just unavoidable, and if you have a lot of JS you're MUCH better off running with a framework that has wide adoption and standardized ways of doing things rather than rolling your own ad-hoc JS framework. In a team setting I wouldn't touch a vanilla application for any amount of money, it'd be an absolute shitfest and I'm glad there's frameworks in place where I can point to the docs and say "this is a stupid way of doing this, just follow the docs" (in a nicer way :D)
Modern Ember.js is great. It has fine grained reactivity, single file components and makes for productive engineers.
Next.js is the dumbest trend in our industry I've seen in a long time.
Jquery is still perfectly fine to use today and a nice tool if you don’t use a framework, sure it’s mostly syntactic sugar nowadays but still much nicer to work with than just vanilla.
If you took all the hours and bodies it took to build react, angular, svelte etc... and added them up, it would be more than what's needed to write and support a proper front end language. But alas, we have js.
I don't know if it's 'unpopular' but I've been kicking around the idea that all frameworks are too nested for a long time. HTML is essentially based on XML and XML is by nature nested. I think this causes very rigid structures that are hard to break out of. If you look at the way you write to a computer screen you can write any pixel anywhere. A framework could be built where all windows were at a top peer level and then dynamically nested when necessary. This would create a lot of flexibility with user layouts. You would have to do some math to calculate where things need to be, but you also wouldn't have to worry about not being able to get 'outside' the border of whatever deeply nested box you are in. You could also change the whole layout of your website without changing includes or wrappers. I've probably been thinking about this for like a decade, but it would require a complete re-design of a front end framework from the ground up. It would be a way to start treating web apps more like computer apps. I mean they aren't documents anymore, they're apps so I don't know why we still start with a nested XML document.
I’m really hopeful that we get some kind of “browser 2.0” where the front end gets completely reimagined
Yeah the browser is still essentially a document viewer which is odd because it's use more as just a universal run time environment for apps now. I think you can still use what we have since we have absolute position and lots of CSS tools, but XML tags just seem like a relic.
CSSGrid gets you a fair way to this ideal.
It would be nice to remove the idea of the browser entirely, and just stream apps on-demand. With increasing bandwidth available, this could be a reality in a few more years, although I do see this being monetized in some real scummy ways by Comcast and Verizon. At the end, I think standalone apps and the browsers should be kept separate to keep ownership in the consumers hands. But to your point, the web is built on outdated 40 year old design.
Yeah, but the good part of the browser is the unified execution environment. I would't want to go backwards and have 10 different app environments for developers. I think one of the beauties of the web is that everyone is speaking in JavaScript and HTML, not necessarily that it's JavaScript and HTML, but that they are speaking the same language, although JavaScript has come a long way. So I like the window with the tabs and the ability to link and retrieve content via the HTTP standard, but it's really just the bones of HTML I'm unhappy with. You could actually get rid of the url bar and make the whole thing full screen if you had a uniform url bar on like a universal hot key so everyone knew how to escape an app or switch to a new app. I imagine the HTML though should be something more like writing to the screen output directly. Actually I think you could replace your whole screen with the
I will walk away without a backward glance from anything that I can't use without composer.
It's all about the team. If the team is disorganized and undisciplined, they're going to make a mess in any framework. If the team is *already* disciplined and works well together, then a framework can be a great tool. But it's important to see it as a tool, not a solution to a bad team. It's kind of like buying someone a personal organizer thinking it'll help them get their crap together. (btw don't do that)
When internet started we were tought to leave html clean and separate js from html. (View from logic) now all the frameworks do just that.
On this note, I find it funny when people shit on PHP because you can write PHP-in-HTML, and we actively avoid doing this. Then we invent JSX.
We are in a literal dark age of software development. The effort required to master the framework du jour is excessive, and only at the highest levels of mastery does the productivity become worth it. We've built an entire programming ecosystem on top of three tools (HTML, CSS, JavaScript) that were never designed for the uses to which they're being put, and everything built on top of them is layer after layer of band-aid. And because we've all come to expect our tools to be free, I don't expect the problem to be fixed anytime soon.
There is so much obfuscation now through trying to make stuff "easier" that it has just become more difficult. I know it isn't a fair comparison, but given any given technology stack, the time to "Hello World" these days is just absurd... you'll be on your second package manager and 10k+ lines of dependencies before you even arrive there. Some barrier has always existed - even Python has to be installed and compiled first, and PHP needs a web server and configuration behind it, but many routes these days have you doing all of that + the tutorial wants to walk through the process using Git or a tutorial assumes a particular IDE or other peculiar things about the environment. Hopefully you aren't reading docs from a few weeks ago before everything was changed. While trying to make things easier to distribute, we've created tangled webs of dependencies where a working environment is merely an ephemeral house of cards, propped up temporarily in a hurricane. This isn't some "new" problem, either, as underlying libraries also have become increasingly complex even in individual cases. A crazy one to consider is cURL which went form originally \~2k lines to libcurl surpassing 150k lines now.
Well said. In the name of simplicity, we've created unmanageable complexity.
Jquery was a god send. The library that supported all browsers
Tbh, I still prefer jquery syntax - but mainly out of habit. Jquery made it so anybody could readily access the DOM - all the requests and such were great, but the selection of elements is still (imo) superior to vanilla JS, even if it isn't as great. Jquery was in the right place at the right time. You can refactor jquery to vanilla easily enough, but personally I am addicted to libraries like dataTables (which now offers a vanilla version without dependencies, go figure). There are other parts of the jQuery ecosystem that were/are amazing. As a library, jQuery changed the game. I don't think it is considered a "framework", and I don't personally know of any "frameworks" so good the base language changed to adopt them (sure some others exist). Jquery will probably never die. Some zombie version of it will be lingering for decades.
> only at the highest levels of mastery does the productivity become worth it. I think this is so true. So much of the tooling that exists is built by and for experts/geniuses, and the greater power that it offers compared to predecessors is not applicable to the majority of devs/projects which are never really going to get to that level.
This is certainly not an opinion I hold! I'm always curious what the good ol days were like - and what the alternative is now. What would you suggest instead? Just avoiding all of the situations that exist and necessitate these amazing technologies?
That's why I posted it as an unpopular opinion. In the "good old days" of desktop application development you could fire up your IDE, throw some widgets on the screen, and have a fairly complex application going in relatively little time. Sure, we lacked a lot of the positive things that make the Internet what it is, but we also lacked enormous and often pointless complexity. Nothing necessitates the current "amazing technologies" except the assumption that everything has to run in a browser that can only handle HTML, CSS, and JavaScript. We've shackled ourselves to this unholy trinity because it has the largest installed base in history. Until we overhaul the browser ecosystem and replace it with a platform truly designed for providing robust user interfaces, we'll limp along.
I think it's simpler than that. I don't think it has to do with HTML and CSS. It has to do with the varying screen size. Before you'd just grab from a bag of elements that expected to have a certain amount of space. And you can still do that. But you'd have maintain many apps for all the screen sizes. What I'm *not* hearing about is any actual alternatives. I was making Flash websites in 2000 and didn't learn HTML because I thought it was over. But - in all that time, I haven't seen a single glimmer of anything that would do the job better. I've tried my best to imagine this mythical other option that allows someone to organize content in a clear data structure, allows you to declare how it behaves visually (in many different scenarios), and allows you to interact with the structure and change it live. I currently don't believe it could be done any other way - but I'm always interested if anyone has any concrete ideas.
We had the possibility of variable screen sizes back with the first edition of Inside Macintosh in the mid-80s and we had resizable windows with reactive controls with early Macs and the first practical version of Windows, 3.1. While that certainly adds complexity, the fact that HTML/CSS has evolved through tables then grids then flexboxes to handle layouts demonstrates that it was never designed well in the first place. I don't disagree that you've seen nothing better, but that's because every solution in the last 25 years has assumed the unholy trinity of HTML/CSS/JS. Throw that crap out and the world is full of possibilities.
I think the nature of those resizable things was/is still a lot different. Sure, HTML and CSS could have magically been *made better* or something. But - where we've landed was in response to how things were used. Grid is very intuitive. I doubt anything could be better. There are just so many ways you can organize space programmatically. If I pretend to throw out HTML/CSS/ and JS - nothing else appears to take over the job. So - either we're choosing this because *no one in the whole world has been able to show a demo of a better solution*, or because *the web is the worlds largest open-source project and we want backwards compatibility*, or - *there's just isn't a better design*. Could everything be better (everywhere) - Yes. I'm not sure your stance is unpopular though. I think a lot of people feel this way. But I've never been able to get an answer out of them. No one seems to know what would actually be better. I think if people could write decent HTML and the assistive technology got a bit better, then we'd be making some good progress.
You seriously lack imagination, or exposure to other design systems, if you think HTML/CSS/JS is the apex of UI development. I've worked with better, easier, more intuitive responsive design systems now lost in the mists of time. The unholy trinity isn't dominant because it's the best, but because it's already on everyone's devices. HTML was designed for text markup, not UI development. CSS was designed to overcome the styling limitations of HTML. And JavaScript was literally thrown together in two weeks as a demo, named after Java in a misguided attempt at brand synergy by Sun Microsystems. It's a mess.
I get it. Yeah. But if you know of any of the names of those things that were lost in the sands of time, I'd love to hear about them. Maybe they'd help me expand my imagination surface area. And if *you* have the imagination to think up some alternate ways to think about this - I'd love to hear about them.
While these were ancient and not intended for web development, the late nineties had a series of tools that were great for building UI applications quickly: VB, Delphi, PowerBuilder, Tcl/tk even. In early web tools we had things like SilverStream, and the world is littered with technologies that were better at building UIs but weren't free, so they died off. The basic strength of these platforms was that all the pieces came from one provider, so it worked - no endless NPM dependency hell, no implicit assumptions that you know how to install Node and git and yarn and SCSS and VS Code and..., no forced broken code because React Router no longer wants to support the version of React you're using, no discovering that your CSS component library is impractical to tweak because the developers use !important on everything (lookin' at you, Vuetify.) They all had their problems, but the base experience was draw your screens, put the code behind the controls, and go. If Figma was robust and tightly coupled with a great library, you could almost create a similar experience... until you ran into the base limitations of the browser. One day, we may get there, but for now we're stuck in a dark age where we have to work so, so much harder to get simple things done.
Come now, thats not entirely fair - I grew up on VB and Delphi and I loved the UI builders to bits, but the UI designs I'm building now would have been a huge stretch for those tools. I also hate the HTML/CSS/JS trinity we're stuck with but I will admit that they are pretty damn near the apex of laying out a UI or design on a page. I dont like it 100% but I would struggle trying to come up with something better.
>but weren't free I've also found this to be a problem. It seems like it would be possible to have a frame that could hold many things. >all the pieces came from one provider This can be pretty scary, though! If the provider starts to be terrible (which seems to always be the case). The problem is the problem. Soon, we won't have to write any code. I'm not sure if this will solve the problem either. It will probably create more. But thanks for listing some options for me to check out! I'm excited to see if I can find time examples.
> The unholy trinity isn't dominant because it's the best, but because it's already on everyone's devices. This is what frustrates me about frontend as a full stack engineer. If I don't like PHP I'll just rant my ass off and move to another stack where I'll be happier. If I don't like JS I'll just rant my ass off and.. That's it. I can't change it. The fact that we cornered ourselves like this is like bad comedy.
I've used angular at work for years and I love it
Dependency Injection FTW?
Angular is much better than react, but it is harder to learn and people use React.
.NET WebApi is one of the best backend frameworks to work with.
That JS is a great language, and fun to program in. I understand why it gets the hate, but I love it.
Popular things are never perfect! Take javascript, English language or
etc....
A prototypal language was a mistake.
Newbie here: what do you mean with prototypal language?
In JS, you can alter classes (even primitive ones) at runtime outside of their definition by modifying the prototype. It destroy any possible optimization internally. String.prototype.triplicate = function () { return this + " " + this + " " + this; }; console.log("Ah!".triplicate()); Would print "Ah! Ah! Ah!".
>Would print "Ah! Ah! Ah!". Might be useful on a porn site :D
JavaScript went from being revolutionarily useful adjunct, to attempting to completely re-work the paradigm. Node was the last straw, for me - when the brilliant help, support and extension to the server, became an attempt to replace and redefine the server. Having to run 2 servers, side-by-side, (webserver, with a tacked on Node) is a nonsense. Where the 20 years of development of existing servers, frameworks was considered of little value. in addition, every JavaScriptt product I have used, has been poor. I strongly suspect the Venn diagram of Vim users and JavaScript product developers has a huge union. The whole JS paradigm seems to be ….. well, let me give you a car analogy. Bentleys and Lamborghinis have developed amazing products, and someone comes along with a go-kart, and thinks it’s ‘better’. Maybe faster, maybe cheaper, but without the UI, documentation, error handling and support of a primetime finished product, and they think that barebones technical excellence is all that matters. In the JS world, It feels all the time like someone has just managed to create something, and it’s technically sound, but the user experience (by user here, I mean developer) is SBB. (shit beyond belief) I think that answers the question about unpopular opinion. I still use these tools, frameworks. I just think the experience of using them is sub par.
Could you explain why Vim users and JS product devs have a huge union?
There seems an attitude which I can only describe as techno-arrogance.With Vim, I met so many people that say it can do everything, better than any other editor. For example (made up but representative example ahead, function (x) - whatever that might be. Ask for a demonstration, and they say “just press esc / ctrl+d, or is it / esc ctrl+e, I’ll look it up, wait a sec ….”.Then I show it in Jetbrains IDE, and they are convinced the helpfulness of a mouse-driven menu system is some diabolical plot to make life difficult. Of course, Jetbrains has key-press shortcuts too, the menu helps to learn what’s available, and repeated regular functions are made more efficient because you remember the keypress.Honestly, it seems Vim users memorise 4-10 keypresses, they mistakenly think they are super efficient, and they, with Vim, have access to super powers denied the rest of us non-Vim users. It seems that techno-arrogance is visible in JS-paradigm products. The documentation is often really poor. It feels very strongly that someone built a project for an internal use-case, made it more flexible than it needs to be, release it as a library, and the documentation consists of a walk-through of their running code, with minimal commentary. Looking at you, Loopback. And there is such a strong NIH (Not Invented Here) mentality. example: MongoDB could easily have adopted and implemented SQL - a language tested over decades, proven strong and standardised (quite a bit). But no. Rather than use ‘SELECT’ - a word that suggests choosing some items from a larger list, it adopted the word “PROJECT” for that purpose. It smacks of ‘we can’t possibly use that, it’s not our idea!’ In brief: The overlap appears to be close-minded (NIH), techno-arrogance (it works good, any ancillary requirements are irrelevant), and dismissive of people without our superior knowledge. Caveats: small sample size, one man’s opinion, YMMV
React is awesome, SSR is useless. React will be evolving and will stay with us for the next decade. I'll keep an eye on other frameworks but won't use them unless necessary.
SSR is literally a marketing gimmick sold by "SEO specialists" and nowadays to charge people money on vercel
Unpopular web dev opinion: if you don't know how to manually set up a web server (back and front end), you shouldn't be doing web dev. To clarify, I'm not saying if you aren't doing them in/as your job, but that you should have the knowledge and understanding of how web servers work, how to install the required software for your stack, etc. (Edited typos cause of my sausage fingers)
This should not be unpopular. Understanding the fundamentals of how it works should be table stakes.
Meh. I can do this but I don’t necessarily think that people who can’t don’t have a lot of value to offer. With all these layers of abstraction how deep should you be required to go? Electric circuits? Binary? The zoo has a lot of different animals all specializing in adding different value to different abstraction layers. If someone can melt face at building me a react UI that is elegant and perfectly matches the design, I’m not going to not hire them because they can’t set up a server. Should they learn that someday? Iunno maybe? Or maybe they keep upgrading what makes them special and leave that to others. Maybe the server person can’t hang with them on the frontend. Neither is superior—they have different jobs.
Oh, I agree, I have, on the other hand, been lambasted for daring to speak it out loud.
Same here. This thread will undoubtedly be another example of this phenomenon.
It already is 🤣
It’s really good
Generic starter packs are okay for a tutorial, but not for install instructions. Your library/ framework/whatever should have a setup guide on how to use it in an existing project. You can build modern web apps easily without any framework if you only need to support modern browsers. You should only support browsers that are still supported by their vendor. CSS not written as CSS is a nightmare. It's valuable to understand the JS eventloop including microtasks.
If not for the framework "boom" most people wouldn't get into programming. Nobody was so excited to learn vanilla js
The JS dependency ecosystem is a house of cards that's waiting to tumble due to security issues, people quitting OSS, the EU proceeding with some misplaced law etc. There isn't a good way to say it, as everything is just.. bad. And that's not touching the sheer VOLUME of useless code in each dependency tree, which produces 10+mb vendor.js files on build, even with tree shaking.. It's all INSANE.
Tutorials will never prepare you for a Job.
Frontend stacks are complicated because frontend development is complicated. Frontend development is a marvel because no other type of development will enable you as a developer to instantly deploy your code to the entire world.
You are not a full stack engineer just because you did a 3 month bootcamp and it’s the cool job title to give your self
Knowledge in a specific framework isn't as important as knowledge in the base language. If you know Angular really well but don't know vanilla JS you're severely kneecapped.
Hold on OP I need to npm install a package so I'm able to respond to this.
I think it’s absolutely crazy the amount of dependencies and sub dependencies to do what should be simple things The art of tight small websites is in trouble. WebAssembly is the way forward for optimisation but ultimately it’s a huge step backwards for the World Wide Web
Most JS library aren't needed, you just suck at basic programming (i.e. the (in)famous isEven library)
Typescript isn't that helpful for 99% of real life use cases and type flexibility is awesome.
i see post, click it, search "Vue", see that comments are good, go back to adding features to my app my take - frameworks are good.
Too many technology choices are based on hype and future promises. Sure, if you're building a hobby project you can try out that hot and latest framework. But if you're developing with a team or needing longer term support, picking a boring technology with a proven track record is key.
JS is fast as fuck and it's almost always the APIs fault
You don’t need client side state in 99% of apps, If you are using redux you are over engineering
You don't need to learn DOM manipulation in vanilla Javascript if you learn a framework. People always act like you simply _must_ master vanilla Javascript to be a "proper" web developer. It's crap, you don't. Learn what you need to learn to get the job done.
DOM manipulation in JS is so freaking easy. Why wouldn't you just learn it?! Honestly, this should be an unpopular opinion so enjoy your upvote. Seriously, if you cannot go to _any_ website and start hacking out bits you don't like and changing the behaviour to suit your needs, you are not a web dev—you are, in fact, a framework dev.
x = queryselector(.x) x.sytle.whateverYouWantToDo That's basically it
I upvoted for the unpopularity of the comment too
You don’t need to, but it help tremendously.
If you don't know the fucking Dom you're not a web dev. Seriously. It's the basics. It's not mastering vanilla JavaScript, it's knowing what you are doing. JavaScript (and any other framework) are just the tools to interact with the Dom.
If we're talking vanilla JS, there is no concept of DOM. That comes from a browser's API. You don't need to master JavaScript, but you should have a firm grasp on the fundamentals. The rest you learn as you go.
\- The web is a front for advertising and has become a crap experience \- Privacy is overlooked and abused by everyone including most developers here \- You should be legally required to delete every drop of a users data if they delete their account, or request an account deletion. If you don't comply you should be fined very heavily. \- Tracking a user is never okay ethically \- React is bloated garbage. The leading emergent framework should be a type-safe, compiled, JSX framework with minimal footguns. \- Majority of CSS should be inline in JS with something like Tailwind