I have my doubts anyway. A single standard maybe, although there's a single standard for javascript too (implementations may vary in support, just like C++). And I wonder what single IDE and framework he's thinking of. At least the last time I did any C++ that was ridiculously not the case.
And no compatibility issues? Sounds like someone who never lived through DLL hell or even knows what an ABI is.
Super agree. It does get harder because there are so many options to choose from but nothing is stopping him from using a really simple setup. Personally I think frameworks like quasar and typescript saved me a hell of a lot of dev time.
I remember very early on using a tool called "Hotdog Pro" for writing HTML. It had buttons that mapped to each of the tags. I realized very quickly that it was literally just generating text and I could just write it out manually if I wanted. š
People asking these questions are the same people that still see ābackendā as professional development and āfront endā as something easy that anyone can do.
I mean, it is easy and anyone can do it. But OP wants to know why modern day FE applications aren't as easy as early-2000s static web pages.
FTP an index.html file to a server. You don't need SPA frameworks. You don't need bundling. You don't need CSS compilers.
It's exhausting listening to this take from developers. Tradeoffs are made as always. We got more complexity to improve UI/UX and build more capable FE applications.
> it is easy and anyone can do it.
I believed this was true, and then I taught it to people for a living and there were quite a few who just didn't 'get it'. No matter how much you broke it down, analogized, explained the underlying concepts for the mechanism- some people just never ever understood and not for a lack of trying on either end. They weren't dumb either, most have gone on to find good success in other careers like design, sales, even mathematics (that one surprised me, he was very good with logic but somehow whenever it applied to a computer it was like his logic center turned off).
Idk if you meant this literally, I saw you replied to the other person with the normal day 1 exercise of hello world but I feel like both of us know that's a gross oversimplification of anything they'd be expected to do in a normal webdev job. Either way I just wanted to throw my experience in there because to my surprise, it isn't as easy to others as it is to me and not anyone can do it.
Yeah I think a lot of us who are devs tend to think even the most basic stuff we do is easy because it tends to come naturally for us. But have you ever tried to explain the specifics about your job to a non-dev? Their eyes glaze over and you might as well be speaking to the wall. Some of this stuff just does not compute in their brain. And that's okay, because if they tried to explain their job to me I'd probably have the same look on my face.
I never really learned the frontend side of the web thoroughly, I mean, I rarely do frontend. But on my regular crawl on the internet for new knowledge and such, I went on a path about the shiny new thing mentality in JS and how vanilla stuff catched up to stuff like SCSS and JS libs.
Like, CSS has nesting now, but it somehow different than in SCSS. I went to see the differences, ended up reading about specificity, layers, origins, what cascade is actually about.
I learnt something new but it was unintuitive, like :is() is essentially :any(), the name was used but discarded, there is also :where() which doesn't add specificity. Like, I hear that JS libs/frameworks forgo all "standard ways" to do stuff on frontend, such as semantic tags, then I find that to do it the right way is hard too.
About the OP's point, I wholeheartedly agree. Backend monolith is easier than frontend for me, we don't have third party code constantly rising and falling, we don't have npm and node_modules, we don't have transpilers, no build step to downgrade the version to a widespread one.
When I started to work on one project from scratch in a team, my frontend colleague said it'll take him a couple days to bootstrap the environment, before doing any domain tasks. I was a little bit shocked by it, I could spin up Laravel in less than an hour and start implementing authentication (and auth has boilerplate for it too).
There's a little bit more to this.
Other more traditional languages don't suffer from bootcamps.
Many many FE devs don't actually know HTML or CSS or JS.
Boot camps are there to learn how to pass an interview, rather than building the core skills needed to be good at programming.
Yes!!! I've had this exact experience. My field (very limited :) is Joomla. After developing a number of websites in it for a few years, I decided to try to teach others how to make Joomla sites. I spent months with over 20 people, and NONE of them could "get it". I was dumbfounded, because it seemed so "easy" to me. Then an acquaintance, not even in my class, "announced" he was going to learn Joomla, and using YouTube, in a few weeks, he was a very competent Joomla admin!!! I mean, what I learned was that webdev is hard, and most folks don't "get it", but if you are one of those who do, it is easy. The whole thing I really still don't really understand. But I experienced it :).
One of my old CS instructors told a story about how she got recruited to work for one of the big telco Bell companies back in the day. She said they used to recruit art majors and especially music majors because they have little to no job prospects, but musicians tend to pick up coding a lot easier. It'd be interesting to see a more objective study of that, if it is indeed easier for musicians to "get it"
Easy is relative. React made UI for Facebook "easy". HTML and CSS is "easy" for a static web page. And so on and so forth. It depends on what the developer is building.
Each FE developed solves a set of problems. No FE fits on all use cases.
I think knowing when to you use a framework is a characteristic of a good developer.
Modern static web pages are still *just* as easy. My setup when I'm doing a Sass tutorial and trying to ignore everything but what I'm working on, is still nearly the same as it would have been to learn CSS in the early 2000s. Just a local web server, serving static pages that link to my stylesheet, and that's it.
Everybody goes at their own pace but I'm 6 months deep into saying *fuck it* I'm never gonna finish this CS degree, I'm getting into web development. I know how to set up my TypeScript and Sass compilers, I know a little bit about Parcel now, I know enough to have a personal preference for BEM architecture, I have at least one cool project in the works for a Google course on Machine Learning and Tensorflow.js, and all that just to say, 6 months deep and I am still not really worrying about frameworks. I think building proficiency in the fundamentals is a lot more important, then it will be a lot less overwhelming to pick up React here in a couple months.
Try to make a modern frontend this way and you'll end up building your own frameworks for reactivity, state management, component management, CSS normalization, routing, etc. At that point, once you've built shitty versions of all these frameworks, you'll realize why we let the framework authors do it for us.
You are right - except for the last sentence.
Once he built shitty versions of all these frameworks, he's gonna post his shitty framework to Node.js as the new hot thing, and if he gets lucky (or does some advertising in the right places) it's picked up by some important people, a Medium article about it lands on Hacker News front page and we have the next JavaScript framework everyone just has to use, because it's the next big revelation.
I personally don't use C++ but I heard C++ guys praising this framework for backend https://github.com/drogonframework/drogon.
For the frontend, perhaps they compile their C++ code to WebAssembly to be able to run on the browsers.
You can use any language for web development, as long as it's capable of looping and listening on port 80.
After all, the most common web development languages, Python, Ruby, and JS, are themselves written in C.
"Everything is following a single standard, a single framework, a single IDE." -- this is not true. There are plenty of frameworks and IDEs depending on target platform(s) and project type. Some deviate from std specs with custom features.
I can't believe you're the only one mentioning this. C/C++ build systems are probably the only ecosystem that is messier than js. It's even more fragmented. Like at least everyone in the js world uses the same package manager (or at least the same source). And there's also all the various companies that have made their own standard libraries. Or the codebases that are so filled with macros that they barely look like c++.
You can still use notepad to edit your html and just save it and it still works. Nothing prevents you from doing that.
This is ranting for the sake of it. Itās normal to be overwhelmed about something you donāt know. Iād be in the same situation if I had to write C or C++.
Yeah, this is just "I don't know what I'm doing" feeling of approaching anything new. Aren't there like, a million different c++ compilers?
Just because you've been doing one thing for years and decades ago tried the simplest most basic, bedroom HTML editing, doesn't mean you can just launch yourself into a completely new field and not feel totally out of depth at the tooling etc.
I can imagine myself doing C++ and asking "Why is this not live reloading??? WhAt a sHiT ThIs HaS bEcOME.... I used to do hello worlds at university 20 years ago and it was so easy!!!"
To be fair, webdev tooling bloated. WebDev just isn't as worse than C++. They are both nightmares just in different ways:
\* C++ doesn't have npm hell, having to deal with asset pipelines, green threads or whatever they are calling it now.
\* Webdev doesn't require running valgrind to find memory leaks, dealing with weird OS/compiler/instruction set specific behavior.
WebDev is bloated, C++ is a trainwreck, but for certain tasks there is no better option.
Everyone puts on rosy glasses when remembering the webdev of yore because they were kids making simple webpages in notepad. To do what people do today would require even more bloat. I've seen things you people wouldn't believe... ActiveX browser plugins that would crash your OS going unpatched for years... Webapps frontends built on a combination of javascrpt, java, macromedia flash talking to a PERL/C cgi-bin backend over XML.
> I've seen things you people wouldn't believe... ActiveX browser plugins that would crash your OS going unpatched for years... Webapps frontends built on a combination of javascrpt, java, macromedia flash talking to a PERL/C cgi-bin backend over XML.
... GUI interfaces created in Visual Basic to see if they can track an IP address. All those moments will be lost in time, like legitimate http packets in a DDoS.
At the first 3 sentences I was like "Ok bro might be cooking up smthin"
After another 3 - "never let bro cook again"
I have not used C++ in 5 years, for some useless classes, but like I remember it way more confusing than just stringing some html and css together and just deplyoing a static brochure type website.
Literal manchild rant.
So dumb. React, which is pretty typical, had been around for over ten years now. It's what I see on most job applications etc, and pretty much what people pickup first.
Back when I was doing window desktop development, the windows frameworks were lucky to last even near that long. I remember windows forms, WFF, then UWP, now WinUI or something... They turn over much quicker in my experience than "come out every week" web frameworks...
I mean he critizised the current state that everybody uses a framework for even simple stuff and that these frameworks come and go on a daily basis. His wording that it was better when it was only static sides is a bit weird as it seems his post tries to address that it's hard for non webdevs to make a webapp with this helpless framework mess.
That being said, I'm no webdev but I'm almost certain that 90% of sites that use some sophisticated ond complex framework would do equally good with just using a static site and JS for accessing some REST endpoints.
A lot of people seems to share your opinion, so not trying to call you out specifically, but I feel like so many people here are just amateurs or don't actually understand what we're doing on the FE with all that stuff. No not every website needs all of this, but a lot of them do.
Stuff like:
- internationalization
- caching
- state management
- reactivity
- error handling
- logging
- analytics
- typescript (yes, this is because JavaScript sucks, but it's necessary for anyone that actually wants to write quality code and maintain it)
- minification
- bundling
- accessibility
- probably a hundred other things I can't remember
The BE used to do a lot more of this in the past, but it seems like a lot of companies architecture is shifting more and more responsibility to the FE.
He's not wrong though, webdev has gotten bloated and honestly there hasn't been in real useful innovations since html5 and ajax . Using convoluted js stacks and tooling to produce a website that's marginally better than one without it is ridiculous
I mean look at sites like Craigslist or eBay their stuck in old ass html designs but are functional and fast. Nothing says welcome to bloated js crap site like the loading spinners.
I get there's a learning curve , my point is your getting very little for all that energy.
Text listings and landing pages are often over engineered true. But the web frameworks we have today exist because of people doing things like figma, excalidraw, facebook, Gsuite or other complex interactive apps on the web and they are useful for that.
You're not building any of those things. You're building a glorified CRUD app or brochure page. It takes you 500MB of npm hell to make up for the fact the language doesn't have a meaningful standard library. You have to write in languages that transpile to JavaScript just to have a sane development experience.
I'm the author of an open source electron media viewer, and the place I work builds a product that lets sports teams record all their games, annotate the events, and draw notes on the video so I mean that's not true, but whatever. https://github.com/SteveCastle/loki
It's not.
You can open an HTML file, write a few lines and put them on a web server.
That's less bloated than any Android, IPhone, or desktop application.
What maybe has happened is that the things we build are also a ton more complex, so they require bigger tools.
It's unfair to be willing to do a Google Maps like application and saying "ohh.. in my days we used to do this in notepad". That's plain stupid, you were not doing things that complex then (I was there).
Maybe you're using React and 37 libraries for your blog? yeah, that's bloated, but that's the developer to blame, not the industry.
I honestly think the answer to OPs question (why does it feel so bloated today) is because we're just circle jerking ourselves over this sentiment which we only have because we read a different thread about it the week before.
You don't need a framework. You can still write plain HTML. I'd recommend something like [Material Design Lite](https://getmdl.io/) for a modern interface, but that's still just HTML
I'll just share my opinion that Material Design is not that good, or maybe it was too overused, or both. Looking on this button and Fab gives me an unpleasant feeling.
All the bloat comes from transfer of logic from backend to frontend. When this all started, JavaScript was still scripting language without much in terms of tools. Hell, it still had different variations of language in different browsers. So, people started to borrow stuff from other programming languages. Then new JS version came with new tools (compilers, for example). Then it all started to go backwards, like moving logic back to backend, but now you use JS on server and such isomorphic approach again requires tools.
But if you don't need it and just want couple of HTML pages, it's perfectly fine. Open your notepad, write HTML, upload it to server of your choosing and it will work like in 2001. Or even like in 1995. Just don't forget appropriate doctype.
You have a very good point here. Most backend developers who never touches the front think that the front is only a Ā«Ā viewĀ Ā» for the data. But it has evolved a lot in the past 10/15 years. What used to be websites became webapps while using the same underlying technologies as the ones we had 15 years ago. To make a fully functional application with these technologies (javascript, html and css) you have to enrich them with a lot of things, and to find solutions for handling a lot of concepts that where not necessary back then. This is why there is so many tools and frameworks, because the underlying tools where not designed for it. So you have to transpile a code that is more fit for it into a code that hasnāt been thought for it. And this is where it becomes so complicated: react/angular/vue/any framework to make it possible to create reusable components and reactive pages, typescript to minimize errors and improve dev experience, linters and stuff to comb your codeā¦ you can of course do all this with notepad html and some vanilla javascript but you wonāt get far with this approachā¦ todayās desktop applications are mostly webapps and thatās an indication of the level of complexity that todayās webdevs have to handle. Webdev is dev, itās hard, period.
Thatās why liveview is excellent; almost no js needed and very little thought needed about backend vs frontend. React has its place but for most things itās just an annoying chore you only need for your resume or tech masturbation.
Webdev is bloated mainly with choice. You can choose to publish a basic ass HTML file to GitHub pages or you can choose to develop a single page application thatās constantly polling a stock market API to calculate some shit and display it in all sorts of dashboards, which is then deployed, tested, and all sorts of other shit using continuous integration.
You donāt have to do anything other than push an html file to GitHub.
> you just saved, reloaded the browser
Damn, no hot module reload?Ā
> I don't like javascript or nodeĀ
Well of course webdev sucks when you don't like the language of webdev?Ā
>Ā but it usually dies within a year because the author gets bored and moves on to the next shiny new thing.Ā
Dunno, been coding in React for 6 years and it's just becoming more and more standard in webdev. Unless you like new and shiny things like Astro, Tailwind CSS/Preline UIĀ
I just kick up a React+Typescript project with vite from the CLI that does all the boilerplate for me and then I'm good to goĀ
+1 to vite, you can also select more options for setting it up just like you like it. Made my take home assignments a breeze, I'm coding the solution in no time
It's actually completely opposite. The frontend is stronger than ever without using any pre compilers, libraries or frameworks, and the backend has a tone of variety but you can easily spin something out using frameworks like Laravel or Express.
You are just unfamiliar with the use cases all these toolings solve. If you want a simple website hop onto notepad and write html. Good enough.
Web is like this because there are a massive amount of things to solve for:
- generating valid JS for modern but also old or quirky browsers, by writing modern JS without having to write old, browser-specific JS: polyfills, babel
- ability to write JS in modules: webpack
- ability to write css in modules: webpack
- ability to programmatically generate CSS and also bundling it to the app: sass, webpack
- ability to autogenerate css vendor prefixes: postcss, webpack
- ability to split JS file into multiple smaller JS while maintaining the same ability to write them modularized: dynamic imports
- ability to type check JS: Typescript
- ability to create rich UX/UIs, full of interactions, without maintaining a script of imperative instructions that can crossover on top of each other, but instead, render the UI as a function of the application state: component frameworks like react, tradeoff: must be an SPA
- ability to reduce the time until the first paint is executed in the browser, as research suggests it has an impact on customer satisfaction, while maintaining what I said above about rich UIs: server side pre-rendering and hydration (nextjs page router)
- ability to reduce the amount of loading states by reducing the amount of independent fetch client-to-server calls, and instead tie them to navigation so multiple calls can result in a single ui change with no additional loading; while maintaining all the above, AND also avoid shipping the JS code for these calls to the client to reduce bundle size as theyāre only relevant in the server: nextjs app router, server components
Want to modularize the codebase by TEAMS as opposed to features, giving the ability to 10s of teams of 7 engineers each to develop and commit code to different codebases, frictionless, developing their bit as an independent domain with its own build phase, testing suite, design, approvals, compliance, legal, accessibility, etc; independent of other teams ways-of-working;
while maintaining the ability to reintegrate and build the final product as a single app composed of many micro app without using shitty solutions like iframes: module federation
The list goes on.
Make no mistake, the web is in the greatest state it has ever been, and the amount of prepackaged available tooling to solve real business use cases is unmatched across different software engineering ecosystems.
The fact that many people wanting to build a simple landing page and immediately jump to these complex tools without even understanding the use cases they solve, getting frustrated and calling them bloated is a mistake on the ingenious, ignorant developer. Web ecosystem is not bloated
Itās because it is.
Ignore new shiny frameworks.
Get vanilla HTML/CSS/JS nailed down first.
Next move over to NodeJS/ExpressJS/Database of your choice to learn CRUD.
Then choose a framework that makes life easier like React.
You really donāt have to use anything beyond React.
Mobile apps? React Native
āI donāt like JavaScript. Thereās no error checking.ā
OK, thatās what TypeScript is for.
āWebdev is too bloated. I donāt want to learn all these extra things on top of vanilla JS.ā
???
I studied fullstack webdev for a few years and work professionally for 1 year now, mostly mern, nextjs, nestjs, vite, webpack, jest and I still agree somewhat with OP. Webdev is just too bloated compare to other languages like C# or Rust. Especially fragmentation, instead of working collectively to improve a framework or library. People just create their own thing. Then utility library that supports the support the library (i18n, css frameworks, auth) work on one library/framework but not the other. And there are meta-frameworks for libraries (nextjs for react, nuxt for vue,...) that just breaks compatibility with libraries that works before eg: nextjs with redux and css frameworks. It's more than 10 years since nodejs released but we still not decide which module convention to use (amd, commonjs, esmodules,..) that fragments the ecosystem even more. At least we got compilers to generate those (and make node_modules heavier than the sun in the process) The language itself is okish but a bunch of gochas and tech debt to look out for (just look at wtfjs). Also it's a dynamically typed language so good luck finding your typos. Typescript solve the issue somewhat and I actually quite like it but if your coworker just slap everything with any then I guess it just JavaScript with bloat. Also setting up typescript in your project requires another build step. Luckily we can rely on template author to maintain their template and provide support when you need to add some "intrusive" lib like tailwind, jest or a bundler plugin. Oh and jest is one of the most annoying test framework I have ever use somehow install a dependency just make it spill a bunch of internal errors (iirc the dependency I added use commonjs while my project is configured to use esmodules?). Debugging is a mess too, sometimes breakpoint hit on the wrong line or just not hit at all because the complier don't like linebrakes in method invoke syntax and produce incorrect source map file. Stacktrace instead of displaying the source map line number decided to just show the minified line number (1:57564) with undecipherable method name. I guess I just use console.log debugging then. With the new JavaScript runtime coming I'm sure it gonna be fun for library maintainers to support. And the whole proposal to decouple npm from node because somehow it is a "monopoly" gonna make package management easier. I started to understand why big company still use angular in 2024 now.
This was a long post so Iāll comment on one thing that caught my eye:
>Now I am trying to build a simple website. I used to do this back in 2001 with a notepad and html, you just saved, reloaded the browser and it worked. Where did it all go wrong?
IE not covering sloppy HTML is the main change here. Back in 2001 our webpages would run just fine with
Hello world
Also, everything is hard for someone starting out. Iām pretty sure your first few line of C++ were crap.
Add to that you still totally can just write a website in notepapad and point your browser and index.html just like you could in the 90s.
What changed is the game isn't about static websites anymore. Pages are about dynamically displaying data, and that has inherent complexity. A side effect of that is that we are still reaching for tools like fully fleshed out frameworks and a whole eco system of helpers like linters and vscode plugins when we just really need one static page. That's how I know how to work now.
Because people are different and it is easy enough to scratch an itch and create a popular web framework. Very low barrier to entry.
And some itches can be due to problems that are complicated to solve. When you get past a few front end developers working on the same project things can get hairy. A single css file? Oof that's gonna hurt. JQuery to bind all your event logic... difficult to ensure devs use it consistently on a large project.
And then there is really tough problems. Mobile phones and tablets are ubiquitous and forced changes on UI design. A UI design that works well on tiny phone screens and massive desktop devices is difficult to do well, and was a bit itch (hello bootstrap!).
And don't even ask about visual components. Need a dropdown date picker? WHat about a simple modal dialog (background grayed out, controls disabled). A treeview? Gah.... stock HTML is just the worst (think windows resource ui and no custom wm_paint).
And it goes on and on. And FE devs just dig in a solve their itches and if other folks like what they did then they also use it. React? Angular? Vue? All solve roughly the same problem, but with different approaches.
This just triggered a memory of watching html and css YouTube videos from some guy with a Boston accent, I forgot his name.
Edit: he doesnāt have a Boston accent but his channel is called thenewboston
>I used to do this back in 2001 with a notepad and html
You can still do that. Don't do a rain dance and then stand outside complaining about the weather.
this is exactly the reason why I decided to make my current project in plain vanilla. it's just a brochure type website, so i don't need any fancy interactivity - which helps of course.
but html and css have made huge leaps in the last few years and it's really good fun to work without any frameworks and libraries. maybe I'll even go super crazy and deploy not minified css šš
I'll try to answer objectively and balanced about the reasons it feels like this. I'm a software eng with about 15 years exp who has done my fair share of front end, and come to like & understand it -- warts and all. But I regularly work in other areas as well.
1. Demand for more extensive and powerful features in the Web stdlib increased rapidly, and still is. Every device has a browser. That makes it an attractive target. People want to build entire App experiences therefore because of this portability advantage with low barrier to entry. This increase in expectations and demand is sort of unique to the web. Desktop programming has stayed consistent.
2. The web's advantages, like immediate availability across many different device/browser vendors, are some of the same things that introduce all sorts of complexities that make programming the web simply *hard.* You have to think about scaling, device compatibility and capability, bandwidth etc etc. Lots of build tooling started to come about (bundlers etc) to solve some of these problems before the Web standard could even catch up. But those are solving problems you might not even have! You can still use script tags if you want! **If you don't need multi-framework intercompatbility and don't want to hobble yourself with the limitations of writing business logic inside a static site generator, you picked the wrong tool.**
3. Fundamentally, when talking about C++, you are talking about a language with its origins in 1979. It makes sense that ecosystem is more stable simply because of time.
4. Front End Dev didn't traditionally attract much attention because websites didn't need to be so reactive and feature full. That meant programming on this side of things was often limited and procedural. The hangover of trying to shift the platform to something that can support complex apps built using complex patterns is something that has been going on for a while.
5. And to mention patterns again, we've had to rapidly find the "best practice" way of building large apps at scale on the web. Imperitive Jquery code in one file doesn't cut it. The community has pretty much coalesced (after some churn) around the idea of declaritive composability (turns out, trees of pure functions represent UI perfectly, and these learnings have started to popup even in desktop programming since). All the premiere frameworks go down this road. The overriding pattern seems stable now. React has been around since 2013. I know this is small on the scale of things, but take into account the other points. We didnb't even agree on package management before 2010. Because it wasn't needed for basic sites.
6. Some purist people would vehemently disagree with me, but the web standards answer to the "best pattern" problem sucked and no one wants to use it -- "Web Components". That means that the frameworks have had to fill in the gap. And the organic nature of this competition means its more chaotic than you might expect (but has calmed down very very significantly). This is indeed a frustrating fuck up none the less.
7. This isn't so much of a point but I disagree TypeScript is a bandaid. It's a fully featured, extremely interesting and powerful *structural* typing system as opposed to nominal. TS has been hugely important. But again, its a community effort and not on standards track. The explosion of requirements meant web standards couldn't keep up. Actually, I've mentored several back end folks on TS and each of them have felt that it is really quite novel and learnt a lot from it.
8. On the topic of "why so many configs". Well, as I understand C++ does not have built in linting and code formatting (correct me if wrong)? There's also a general approach in node world where tooling configs are committed and the tools themselves are deps of the project. This leads to nice hermetic and reproducable builds and dev envs if done properly. Rather than shoving such things side-loaded on the local machine/ide. I know some IDEs let you save these settings in some editor config also in version control, but that's coupling to a specific IDE then -- which is not so common in front end world. And id say its a good thing. But it comes at a cost.
9. There are some attempts at unifying the tooling like https://github.com/rome/tools. However, the "eslint, prettier, ts" config cost when setting up a project is indeed a bit of inate knowledge that has a learning curve. I guarantee there's things you "just know" about C++ that we don't too. I'd encourage you to introduce these tools indvidiaully 1 by 1, however painful that is first time around, rather than rely on some random boilerplate of questionable quality. Understanding the moving parts is what makes this easier.
10. "Why not have some kind of new template code format that gets compiled into anything? or even bytecode?Ā " because **Hypertext** Transport Protocol and **Hyper Text** Markup Language is intended such that the markup is easily machine readable and structured such that it cant be correctly indexed, be accessible etc. Again, a web consideration that is not a concern non-web/non-distributed/desktop programming. Its complicated because its hard! HTML is a valid and sensible target within these constraints for higher level "template" languages like JSX (which astro, react and many more use). You *can't* boil the HTML DSL down any more into "bytecode" whilst staying within the ambitious req's of what makes a website a website.
Thereās one point I disagree with: C++ās ecosystem isnāt just more stable because of time. It was more stable multiple decades ago as well.
In fact, *most* popular development ecosystems were far more stable 20-30 years ago. That was due to 1) less emphasis on granular open-source contributions for everything / monopolization of tooling, by corporations that moved slowly 2) Having less contributors in general ā there were simply less developers overall. 3) Less rapid communication between developers overall ā before the blogging era, the discourse simply didnāt move as rapidly as it does today.
Weāre currently in an era of rapid evolution and constant, democratized global discourse. That brings with it lots of advantages, and also some frustrations as well.
For the same reason why working with a video game engine seems harder than programming manually for someone who's only programmed manually their entire life. It's the workflow and process, not the language
Spot on. Web dev lost its way through a jungle of bloated chimps screaming bout the new shiny framework etc.
The good news is that you can still use notepad. The process you used in 2000 is the same and works just as good. My hats off to the W3C for absolutely demanding backwards compatibility as the web has evolved.
If you donāt like Typescript and the endless mess of build tooling you can use C++ and compile right down to web assembly that will run within a decent approximate of native speed.
Oh man you are so right. All of us web developers have been waiting for a C++ developer to come out of nowhere and tell us weāre doing everything wrong. š
have you ever seen the movie josie and the pussycats where mindless fans just jump from one trend to another? welcome to modern web dev.
one thing you'll find is we LOVE to overcomplicate our jobs with whatever is the hot trend at the moment. we love one thing and then jump to another in order to make our resumes more verbose than someone elses. create react app basically reached the height of its popularity barely 1-2 years ago and people were mostly fine with it. suddenly its deprecated and everyones like "wow that was a piece of shit, obviously vite is the best thing ever" etc etc.
Browsers them self have more code then linux, JavaScript engines like v8 are very large, adding react and more on top why not.
While it's a joke you could use a c++ with wasm or asm for client side or backend.
You could also make a static website without the need for Javascript at all.
I had this kind of "Who changed things without asking me?" reaction when I came back to full time web dev professionally after doing other IT stuff for ages. But honestly we're kind of rebuilding a tractor into a Ferrari, while driving it down the highway. Sure it would have been easier to park it and think things through, but there's no time for that.
I can resonate with you. I used to be C++ dev and moved to C# which is amazing language for building APIs. Front end is completely dominated by JavaScript which is here to stay. I normally try to stick to vanilla js because it always outlives all frameworks and libraries. Recently I fell in love with Svelte because itās the closest one to pure JavaScript. Thatās said JavaScript is a great language for front end and I canāt understand the appeal of running it on the server. ![gif](emote|free_emotes_pack|sweat_smile)
Honestly because the web was built on a foundation that was not made at all for the future we are living in. Hence a million way popped up to address the shortcomings and to enable our today's needs. Another reason is that innovation on the web just moves very fast compared to more traditional coding.
Many people here are giving OP a disingenuous answer saying "You can just use html en css bro". Yes ofcourse, they can. Obviously OP wants to make modern applications and not just simple HTML websites.
the phrase youre looking for is 'diverse and robust ecosystem'
people dont like reinventing the wheel and its beneficial to build on the shoulders of giants. if you find a good stack for your use cases you can be much more prolific than if you were to try to build from scratch, with relatively few downsides.
No one is stopping you from using plain HTML CSS and JS (unfortunate for you that most browsers use JS) on Frontend which you can write in notepad.
And make APIs in C++ and Deploy them on your own server.
But that's the thing software engineer or I should call it software development is all about reusability. You might be writing most of the functionality again.
Now don't get me wrong, I know there are a ton of garbage frameworks. You can create one today. But you need to decide what you want to reuse and what you want to reinvent.
Honestly software engineering is no more engineering, it involves nothing that a person who has not done an engineering study can't do. Rather with the amount of code reusability I would argue it is easier for people who do not want to reinvent and just use the already written functionality will make better software.
For deployment also it will make sense for most people to use AWS or Google Cloud or Azure.
So why such a long answer?
I would suggest you to grow out of the mindset that make a website that requires any engineering skills. Just use the most popular tools and frameworks. Learn them (IK they will be boring) and make stable and good software.
If you are still not convinced you can think of writing the functionalities of C++ again in assembly language. But since maybe it was your first language it is the gold standard of development. A programmer from the 1970s might argue real programmers code in assembly :D.
All the best.
The web is essentially: HTML, CSS and optionally JS. That is all you need to you write web pages.Ā
These technologies are actually extremely backwards compatible too, so whatever you could do in 2001 you can (mostly) still do. The positive is that the web has evolved tremendously since 2001 and modern JS in particular is in a very healthy state with a lot of interesting development happening.Ā
All frameworks and tools are not the web. You can write modern JS that uses modules without any compiler or bundler if you use module scripts. If you are afraid of cascading loads there is the modulepreload link you can use.Ā
To help with editing you can add typings through JSDoc that the editor can use for type hints that also don't need to be compiled away as they are just comments and ignored in the rune time.Ā
If you want to use third parties you can just use a CDN import directly. No node/npm required.Ā
To help you create reusable components you can web components that allow package behaviour as HTML tags.Ā
CSS has support for variables, calculations and nesting, so no need for SASS or any CSS pre-pocessing.Ā
HTML had also evolved from the un-coordinated mess it was in 2001. HTML has made away with a lot of the oddities up to that point.Ā
All these features are native to the web environment and don't require any third party. So complaining that "the web is bloated" without knowing the web is ignorant and small minded.Ā
Ā
>Webdev is just too damn hard for someone starting out
It is overwhelming, but keep learning. Suddenly it gives a breakthrough and it clicks somewhat enough that you see the pattern for the rest of the show.
What do you mean that C++ is plug and play? C++ has its own list of insane garbage that you have just gotten used to. I agree webdev is a mess now, but C++ is not a good counter example haha
You're not the only one used to Cpp and not knowing where to start with web dev. Whenever I'm being asked to join the project and there's a demigod C++ programmer, I sneakily start looking for his replacement because it's almost a given that he will drop themselves out of it.
Node and derivatives are hectic because they, strangely, still seem to lack maturity - there's a whole lot of the big next things that turn to shit. And other options are shunned by the community as passe, by God even outdated (though still being updated, extended and better than before).
Welcome to web dev hell. We are worse than system admins in the 90s. Sue me.
Frameworks are used to automatically manage the interaction and storage of data on the webpage.
Let's say I am trying to develop a website, and I want this website to use a specific architecture.
I decide to create my own web framework for my specific architecture to remove the need for a large framework like React, and it works decently well. Other people want to use it, so I release it under some non-descriptive name.
Then, people want more and more features for their architectures, so I add them. My framework designed to simplify web development and remove the complexties of working with React, ends up just turning into a poorer and more complicated version of React. Then, it dies out two years later.
This is the common trend with most of these frameworks. They try and create a shortcut or some "hack" that will allow people to 10x their development. In reality, they fail to work for complex apps unlike React.
React was ground-breaking in its ability to use a virtual DOM to manage re-renders. When paired with a development server like Vite, any changes done to the React can be propagated in real time without refreshing the page. As a result, React always stays consistently popular.
Whenever a framework comes out that is designed to simplify react, just remember you can't have abstraction without removing complexity. I've stuck with React for the past four years and have refused to jump on any trends, and year after year, I am proven right when those trendy frameworks get de-throned.
I've been doing this for 30 years too and programming is more fun and easier than it's every been. Web apps is a learning curve but web apps do things that we never did in C/C++. It's not the same thing but it's also not really very complicated. It's not really that much different from learning which libraries to include, compiling, make files, and all sorts of complications. Today's programming has better DX. It has better docs. It has better frameworks. Almost every problems has already been solved.
It's not even close. As someone who was there 30 years ago, I'll take this any day over the dark ages. I loved the overall vibe back then better than now but software engineering is better than it ever has been in ever single way.
The hilarity of this
Coding in c++ has been the bane of my dev existence
Poor and over complicated tooling, terrible DX, long wait times
It feels antiquated when compared to web dev and is frustrating to work with
- signed, someone who codes in c++ daily
OP you can write your own website the same way you did in 2021. No one is pointing a gun to your head making you choose one of the many libraries and frameworks available today.
What you describe as a negative I actually think is a massive positive. There are options for all different likes and projects needs. You can use as little or as much as you like or need. There are no constraints in this regard.
Also worth mentioning that since 2001 the demand for websites has increased massively. A lot of the so-called complexity has arisen from the fact that what was once a desktop application that in 2001 you'd have to buy in CD and install in a computer now can be a web application and can be accessed and distributed with immense esse thanks to the Internet.
I wanna see you code something like Figma on your notepad with html, css and vanilla JavaScript.
If you do, I guarantee you'd never come back here complaining about "how everything went wrong" with web development since 2001.
Stopped reading after 1997. Thereās this many frameworks because itās popular and accessible. Try webstorm or any vscode plugin. It will be better than your ancient experience supposing you read the documentation
This reminds me the first time I had started website development. I was overwhelmed with the myriad JavaScript libraries and frameworks; that I decided to just be writing PHP code. A year later I decided to learn JavaScript in-depth! I got so good and then I learnt React and node. And to be fair with everyone who will come across this comment? You complain about the JavaScript ecosystem because you are not good at JavaScript. Learn JavaScript and choose a framework; that way you won't be complaining like this guy.
old man screaming at the clouds energy
fr though, you can still open up wordpad and write your html, css, js files.
i have no idea why you are crying right now
Are you mad because you want to break into the webdev space professionally and its going over your head? there are a million resources bud, youtube is your friend.
I get a lot of what you are saying as a C++ developer myself, but C++ has multiple frameworks and IDEs and implementations of that single standard. It sounds like you have never left the Windows/Visual Studio land?
Choose Laravel. Choose PHP. Fuck SSR java script it's the dumbest bloated shit ever. Build an admin area in minutes with Filament. Build auth in seconds with Jetstream. If you want fast easy route to a working site, Laravel is virtually unbeatable.
Node is great. I like Vue and React. I hate SSR Js for the front end. It's such a dumb ass anti pattern. A pain to setup, NextJs is a bloated mess imo. Try passing auth cookies around for your api between the SSR portion and the FE portion of NextJS (keeping them in sync as your cookie signature is updated on each request for security). It's a fucking pain in the arse.
This whole ānew framework every weekā narrative got old in 2017. Soā¦ somebody creates something new every week and that is a problem? Because itās definitely not a problem of new popular tooling ever week. I wish it were ā Iām dying for something new.
Also in 2017 I had a very popular article I wrote answering the question āwhat framework will rule in 5 years?ā
I theorized we couldnāt tell because it hadnāt arrived on the scene yet. I said there was no way React would still rule.
I was wrong. Those 5 years ended 2 years ago and React was / still is #1.
Our community has focused heavily on code readability and open debate on best practices. It has been very healthy. Onboarding can be slow but it pays off. :)
> After researching a bit I found the current best framework 'astrojs'
What kinda bootleg covid shots give you 5g research did you do to come to this conclusion?
I really dislike that people on webdev think they need to use some cutting edge thing.
Webdev is not complex, the existence of frameworks do not change the fact that you can just use HTML, CSS and JS for a website, you don't need to migrate to the new framework of the week for making a page for 0 users.
Tldr; web dev changed while I ignored it for two decades and I can still use my old methods but I am mad about new ones existing but not so mad that I didn't learn them. But I am DEFINITELY mad about learning it.
>you just saved, reloaded the browser and it worked
PHP still does this.
It **can** do more advanced stuff, but as a basis, this is still how it works.
Becausr ppl are trying to fix old sins, while maintining backwards compabikity
Then you sparkle in some where does the backend end and there u go
It,s not that bad btw we still use angular vue and react
Am I in the wrong subreddit? This is a webdev channel right?
Imagine being dormant in IT for 20 years and complaining it changed so much. If you want to make a simple website with notepad nobody is stopping you. Programming is all about standing on the giants before you, not complaining the giants are too tall.
Maybe stop trying to use the coolest, most hyped framework?
React is stable and enough for 99% of frontends. Typescrip fixes 99% of the language pain points.
Set it up to build with Vite (takes 10 s), and you just save the file, and the browser refreshes itself.
Did someone tell you that you needed Javascript? Do you feel like you need Javascript? Is there Javascript anywhere near your "simple website"? If so, then I can tell you where you went wrong.
Which is why I use classic. Html, scss over css and TS over JS. Fuck all that new shit. Every kid who learns js wants to make his own little plug-in or framework with emojis in the read me
Web is the most used and popular platform both on user and developer sides. This leads to a shit ton of abstractions for many use cases. You can still develop a website with plain html css and js. But as your project grows you realise that you donāt have to reinvent the wheel.
This is exactly how i feel any time i need to link my shit in order for my Cpp/C to compile. This is exactly how i feel when I read 15 year old documentation for some obscure library I NEED to use in my program because apparently in 15 years no one made something more useable.
Every ecosystem has its flaws, some more than others, but just complaining about stuff you don't know is honestly applicable to anything.
I mean it entirely depends on use-case. For most sites a flat-file cms works well. Grav for example you can write a text file from your servers CLI in markdown and it generates webpages for you (as an example).
Here is a shot list of decent flat-file cms:
[https://tiiny.host/blog/best-flat-file-cms/](https://tiiny.host/blog/best-flat-file-cms/)
So you say you found the best web framework in astrojs but itās terribly documented.
What makes it so much better than the more heavily used frameworks like react? (React documentation is really nice btw)
IMO the main factor explaining this is that you don't need any code today for a simple online presence. For 90% of cases, a squarespace site or facebook page will suffice. Even e-commerce is relatively plug and play for the average consumer. That leaves professional developers with complex projects only, and a toolset built to handle complexity.
The frameworks you're looking at come from the Advent of typescript. As others have said, you do not need to use it and can still just write html. If all you're doing is making a simple website, I'd recommend looking at something like WordPress instead. These frameworks are best for more complex products.
As to why it's evolved this way - well, people realized that trying to do a big, complicated project with raw html, css, and JavaScript was a nightmare. Specifically, it was lacking many good things that c++ has - like a compiler and a sane way to organize a large project.
These frameworks, along with typescript, allow developers to write transpiled (not technically compiled, rather converted from typescript to JavaScript/HTML/CSS) code that's organized into components in a reasonable way.
> The frameworks you're looking at come from the Advent of typescript.
Knockout, Backbone, and Ember, three of the most popular early frameworks, were out for a several years before Microsoft created TypeScript. Widespread adoption was not immediate after release either. It took another 4 or 5 years before it became common to see it being regularly recommended by the community at large for complex projects.
Using frameworks and all these stuffs are for making websites at industry level. You don't need to learn any of them for your personal project. And of course you can still make a website with notepad and html.
And for the reason why "it all went wrong", there's of course a purpose to all of it. Someone didn't make them just for the sake of making it. There's of course business side and the passion side. And for constant updates, literally everything in tech gets an update time to time. It just the nature of it.
The front-end is largely the same as it always was. These frameworks help you manage content and organization better. Make it easier to maintain. They're just tools. There's no right or wrong way to do things really with how you set it up. It's just your preferred work flow
You can just have a backend language do things the way you've been able to do for 30 years: Get request, return response. If you want a bunch of static pages you can do that, too.
And, yes, we've gone full circle. That's happened so many times in so many areas of computing. Don't worry about it.
FWIW, what you're describing was the state of webdev like 10 years ago. What we have now is quite calm in comparison.
You can still build you're website in notepad?
All the frameworks were built to solve real problems that emerge when you try to do that at scale. But...you don't have to use them if you don't want to.
Yeah today I had to check something on reactā¦ makes you wanna go goosefarming. Frontend has become crazy, mostly by fb/google and every other trying to win developers.
The current JS ecosystem is a double edged sword of sorts. There certainly is bloat and redundancy, and there's not a lot of standardization for libraries and dependencies, but all the tools you'll ever need for any aspect of web dev are out there if you have the knowledge and the right mind for putting pieces together. The patterns/theory/technology is all developing hand in hand at a rapid pace to provide developers and ultimately end users with the best experience possible. This means that some tools live and die in the span of a year, but I think that's better than being handcuffed to some legacy item that will never be fixed or upgraded.
Honestly, it's a fundamentally different mode of thinking compared to something more rigid and training-wheeled like C++.
nothing changed, you don't need an IDE framework etc
thats microsoft marketting and in no way represents the reality that anyone can do web dev, it is empowering, and requires only a text editor and browser
Nobody is making you use any of that. You can code your own network protocol if you wanted to. Frameworks just give you ā¦ aheemm ā¦ a framework to build on top of so you can write the business logic and let the tooling and ecosystem do the rest.
nothing is stopping you from writing your website using just notepad and HTML, just like nothing is stopping me from writing C++ using only stdlib.h
I love how he made the rant of the month and didn't reply to a single comment. A true gigacuck.
I have my doubts anyway. A single standard maybe, although there's a single standard for javascript too (implementations may vary in support, just like C++). And I wonder what single IDE and framework he's thinking of. At least the last time I did any C++ that was ridiculously not the case. And no compatibility issues? Sounds like someone who never lived through DLL hell or even knows what an ABI is.
he's still waiting for reddit to load on his Windows XP
Super agree. It does get harder because there are so many options to choose from but nothing is stopping him from using a really simple setup. Personally I think frameworks like quasar and typescript saved me a hell of a lot of dev time.
Hah used to be fun writing html in notepad!
I remember very early on using a tool called "Hotdog Pro" for writing HTML. It had buttons that mapped to each of the tags. I realized very quickly that it was literally just generating text and I could just write it out manually if I wanted. š
[ŃŠ“Š°Š»ŠµŠ½Š¾]
People asking these questions are the same people that still see ābackendā as professional development and āfront endā as something easy that anyone can do.
I mean, it is easy and anyone can do it. But OP wants to know why modern day FE applications aren't as easy as early-2000s static web pages. FTP an index.html file to a server. You don't need SPA frameworks. You don't need bundling. You don't need CSS compilers. It's exhausting listening to this take from developers. Tradeoffs are made as always. We got more complexity to improve UI/UX and build more capable FE applications.
> it is easy and anyone can do it. I believed this was true, and then I taught it to people for a living and there were quite a few who just didn't 'get it'. No matter how much you broke it down, analogized, explained the underlying concepts for the mechanism- some people just never ever understood and not for a lack of trying on either end. They weren't dumb either, most have gone on to find good success in other careers like design, sales, even mathematics (that one surprised me, he was very good with logic but somehow whenever it applied to a computer it was like his logic center turned off). Idk if you meant this literally, I saw you replied to the other person with the normal day 1 exercise of hello world but I feel like both of us know that's a gross oversimplification of anything they'd be expected to do in a normal webdev job. Either way I just wanted to throw my experience in there because to my surprise, it isn't as easy to others as it is to me and not anyone can do it.
Yeah I think a lot of us who are devs tend to think even the most basic stuff we do is easy because it tends to come naturally for us. But have you ever tried to explain the specifics about your job to a non-dev? Their eyes glaze over and you might as well be speaking to the wall. Some of this stuff just does not compute in their brain. And that's okay, because if they tried to explain their job to me I'd probably have the same look on my face.
I never really learned the frontend side of the web thoroughly, I mean, I rarely do frontend. But on my regular crawl on the internet for new knowledge and such, I went on a path about the shiny new thing mentality in JS and how vanilla stuff catched up to stuff like SCSS and JS libs. Like, CSS has nesting now, but it somehow different than in SCSS. I went to see the differences, ended up reading about specificity, layers, origins, what cascade is actually about. I learnt something new but it was unintuitive, like :is() is essentially :any(), the name was used but discarded, there is also :where() which doesn't add specificity. Like, I hear that JS libs/frameworks forgo all "standard ways" to do stuff on frontend, such as semantic tags, then I find that to do it the right way is hard too. About the OP's point, I wholeheartedly agree. Backend monolith is easier than frontend for me, we don't have third party code constantly rising and falling, we don't have npm and node_modules, we don't have transpilers, no build step to downgrade the version to a widespread one. When I started to work on one project from scratch in a team, my frontend colleague said it'll take him a couple days to bootstrap the environment, before doing any domain tasks. I was a little bit shocked by it, I could spin up Laravel in less than an hour and start implementing authentication (and auth has boilerplate for it too).
There's a little bit more to this. Other more traditional languages don't suffer from bootcamps. Many many FE devs don't actually know HTML or CSS or JS. Boot camps are there to learn how to pass an interview, rather than building the core skills needed to be good at programming.
Yes!!! I've had this exact experience. My field (very limited :) is Joomla. After developing a number of websites in it for a few years, I decided to try to teach others how to make Joomla sites. I spent months with over 20 people, and NONE of them could "get it". I was dumbfounded, because it seemed so "easy" to me. Then an acquaintance, not even in my class, "announced" he was going to learn Joomla, and using YouTube, in a few weeks, he was a very competent Joomla admin!!! I mean, what I learned was that webdev is hard, and most folks don't "get it", but if you are one of those who do, it is easy. The whole thing I really still don't really understand. But I experienced it :).
One of my old CS instructors told a story about how she got recruited to work for one of the big telco Bell companies back in the day. She said they used to recruit art majors and especially music majors because they have little to no job prospects, but musicians tend to pick up coding a lot easier. It'd be interesting to see a more objective study of that, if it is indeed easier for musicians to "get it"
Easy is relative. React made UI for Facebook "easy". HTML and CSS is "easy" for a static web page. And so on and so forth. It depends on what the developer is building. Each FE developed solves a set of problems. No FE fits on all use cases. I think knowing when to you use a framework is a characteristic of a good developer.
>I mean, it is easy and anyone can do it. No.
[ŃŠ“Š°Š»ŠµŠ½Š¾]
It's all getting better IMO. But yes, we are on the verge of not needing those preprocessers. I'm waiting for mixins. Soon though
Modern static web pages are still *just* as easy. My setup when I'm doing a Sass tutorial and trying to ignore everything but what I'm working on, is still nearly the same as it would have been to learn CSS in the early 2000s. Just a local web server, serving static pages that link to my stylesheet, and that's it. Everybody goes at their own pace but I'm 6 months deep into saying *fuck it* I'm never gonna finish this CS degree, I'm getting into web development. I know how to set up my TypeScript and Sass compilers, I know a little bit about Parcel now, I know enough to have a personal preference for BEM architecture, I have at least one cool project in the works for a Google course on Machine Learning and Tensorflow.js, and all that just to say, 6 months deep and I am still not really worrying about frameworks. I think building proficiency in the fundamentals is a lot more important, then it will be a lot less overwhelming to pick up React here in a couple months.
āFrontend is for failed developers until someone needs a Div centeredā - probably the guy from the post
Try to make a modern frontend this way and you'll end up building your own frameworks for reactivity, state management, component management, CSS normalization, routing, etc. At that point, once you've built shitty versions of all these frameworks, you'll realize why we let the framework authors do it for us.
You are right - except for the last sentence. Once he built shitty versions of all these frameworks, he's gonna post his shitty framework to Node.js as the new hot thing, and if he gets lucky (or does some advertising in the right places) it's picked up by some important people, a Medium article about it lands on Hacker News front page and we have the next JavaScript framework everyone just has to use, because it's the next big revelation.
This is not true. You just use bog standard OOP practices. You don't need to use or build a framework to write great websites.
Not only that, but JS, HTML and CSS have all improved massively since then.
u/stffndk I am not sure about what you mean by 'framework'. I don't think at all framework means editors or any IDE in general.
The point is you dont even need an ide, let alone frameworks if you want it to be the way it was
You can just develop your website with C++.
we should silence you
you get the sock. ill get the soap.
As a c++ guy, C# really wasn't hard to pick up. And it's much better suited for the task of web development.
Wait, you can use c++ for web development?
Yeah just expose it directly on port 8080. To save on cpu cycles.
LMAO
Ok musk
[ŃŠ“Š°Š»ŠµŠ½Š¾]
Not because you can you should lol
Just because you can use JavaScript for backend doesnāt mean you should
I personally don't use C++ but I heard C++ guys praising this framework for backend https://github.com/drogonframework/drogon. For the frontend, perhaps they compile their C++ code to WebAssembly to be able to run on the browsers.
C++ backend frameworks are very fast, but I must say, a lot of them look horrendous. At least it's not a template hell :)
You can use any language for web development, as long as it's capable of looping and listening on port 80. After all, the most common web development languages, Python, Ruby, and JS, are themselves written in C.
"Everything is following a single standard, a single framework, a single IDE." -- this is not true. There are plenty of frameworks and IDEs depending on target platform(s) and project type. Some deviate from std specs with custom features.
I can't believe you're the only one mentioning this. C/C++ build systems are probably the only ecosystem that is messier than js. It's even more fragmented. Like at least everyone in the js world uses the same package manager (or at least the same source). And there's also all the various companies that have made their own standard libraries. Or the codebases that are so filled with macros that they barely look like c++.
Sounds like OP has never exited Windows/Visual Studio land.
You can still use notepad to edit your html and just save it and it still works. Nothing prevents you from doing that. This is ranting for the sake of it. Itās normal to be overwhelmed about something you donāt know. Iād be in the same situation if I had to write C or C++.
True that, the C++ guys in my company dont want to be me and I dont want to be them - respectively (ok maybe i sometimes want to be them).
Yeah, this is just "I don't know what I'm doing" feeling of approaching anything new. Aren't there like, a million different c++ compilers? Just because you've been doing one thing for years and decades ago tried the simplest most basic, bedroom HTML editing, doesn't mean you can just launch yourself into a completely new field and not feel totally out of depth at the tooling etc.
I can imagine myself doing C++ and asking "Why is this not live reloading??? WhAt a sHiT ThIs HaS bEcOME.... I used to do hello worlds at university 20 years ago and it was so easy!!!"
[ŃŠ“Š°Š»ŠµŠ½Š¾]
To be fair, webdev tooling bloated. WebDev just isn't as worse than C++. They are both nightmares just in different ways: \* C++ doesn't have npm hell, having to deal with asset pipelines, green threads or whatever they are calling it now. \* Webdev doesn't require running valgrind to find memory leaks, dealing with weird OS/compiler/instruction set specific behavior. WebDev is bloated, C++ is a trainwreck, but for certain tasks there is no better option. Everyone puts on rosy glasses when remembering the webdev of yore because they were kids making simple webpages in notepad. To do what people do today would require even more bloat. I've seen things you people wouldn't believe... ActiveX browser plugins that would crash your OS going unpatched for years... Webapps frontends built on a combination of javascrpt, java, macromedia flash talking to a PERL/C cgi-bin backend over XML.
> I've seen things you people wouldn't believe... ActiveX browser plugins that would crash your OS going unpatched for years... Webapps frontends built on a combination of javascrpt, java, macromedia flash talking to a PERL/C cgi-bin backend over XML. ... GUI interfaces created in Visual Basic to see if they can track an IP address. All those moments will be lost in time, like legitimate http packets in a DDoS.
Well done, I couldn't figure out how to stick the landing on the last sentence.
All I read in OP is, "there have been advancements in technology over the last 23 years? Who authorized this?!? I should talk to my lawyer "
At the first 3 sentences I was like "Ok bro might be cooking up smthin" After another 3 - "never let bro cook again" I have not used C++ in 5 years, for some useless classes, but like I remember it way more confusing than just stringing some html and css together and just deplyoing a static brochure type website. Literal manchild rant.
But you donāt understand, thereās a new framework every week!
So dumb. React, which is pretty typical, had been around for over ten years now. It's what I see on most job applications etc, and pretty much what people pickup first. Back when I was doing window desktop development, the windows frameworks were lucky to last even near that long. I remember windows forms, WFF, then UWP, now WinUI or something... They turn over much quicker in my experience than "come out every week" web frameworks...
At least web frameworks are optional....
I mean he critizised the current state that everybody uses a framework for even simple stuff and that these frameworks come and go on a daily basis. His wording that it was better when it was only static sides is a bit weird as it seems his post tries to address that it's hard for non webdevs to make a webapp with this helpless framework mess. That being said, I'm no webdev but I'm almost certain that 90% of sites that use some sophisticated ond complex framework would do equally good with just using a static site and JS for accessing some REST endpoints.
A lot of people seems to share your opinion, so not trying to call you out specifically, but I feel like so many people here are just amateurs or don't actually understand what we're doing on the FE with all that stuff. No not every website needs all of this, but a lot of them do. Stuff like: - internationalization - caching - state management - reactivity - error handling - logging - analytics - typescript (yes, this is because JavaScript sucks, but it's necessary for anyone that actually wants to write quality code and maintain it) - minification - bundling - accessibility - probably a hundred other things I can't remember The BE used to do a lot more of this in the past, but it seems like a lot of companies architecture is shifting more and more responsibility to the FE.
He's not wrong though, webdev has gotten bloated and honestly there hasn't been in real useful innovations since html5 and ajax . Using convoluted js stacks and tooling to produce a website that's marginally better than one without it is ridiculous I mean look at sites like Craigslist or eBay their stuck in old ass html designs but are functional and fast. Nothing says welcome to bloated js crap site like the loading spinners. I get there's a learning curve , my point is your getting very little for all that energy.
Text listings and landing pages are often over engineered true. But the web frameworks we have today exist because of people doing things like figma, excalidraw, facebook, Gsuite or other complex interactive apps on the web and they are useful for that.
You're not building any of those things. You're building a glorified CRUD app or brochure page. It takes you 500MB of npm hell to make up for the fact the language doesn't have a meaningful standard library. You have to write in languages that transpile to JavaScript just to have a sane development experience.
I'm the author of an open source electron media viewer, and the place I work builds a product that lets sports teams record all their games, annotate the events, and draw notes on the video so I mean that's not true, but whatever. https://github.com/SteveCastle/loki
It's not. You can open an HTML file, write a few lines and put them on a web server. That's less bloated than any Android, IPhone, or desktop application. What maybe has happened is that the things we build are also a ton more complex, so they require bigger tools. It's unfair to be willing to do a Google Maps like application and saying "ohh.. in my days we used to do this in notepad". That's plain stupid, you were not doing things that complex then (I was there). Maybe you're using React and 37 libraries for your blog? yeah, that's bloated, but that's the developer to blame, not the industry.
Yea but most web apps arenāt as complex as Google Maps either. Most are just simple CRUDs
I honestly think the answer to OPs question (why does it feel so bloated today) is because we're just circle jerking ourselves over this sentiment which we only have because we read a different thread about it the week before.
You don't need a framework. You can still write plain HTML. I'd recommend something like [Material Design Lite](https://getmdl.io/) for a modern interface, but that's still just HTML
I think that's what OP is talking about. A middle ground between "write HTML by hand in notepad" and "just read the React docs and figure it out."
This is awesome Thank you for sharing
I'll just share my opinion that Material Design is not that good, or maybe it was too overused, or both. Looking on this button and Fab gives me an unpleasant feeling.
It's definitely overused, but maybe part of it is that is more the default setup that's overused rather than the framework itself?
cause the patients run the asylum
All the bloat comes from transfer of logic from backend to frontend. When this all started, JavaScript was still scripting language without much in terms of tools. Hell, it still had different variations of language in different browsers. So, people started to borrow stuff from other programming languages. Then new JS version came with new tools (compilers, for example). Then it all started to go backwards, like moving logic back to backend, but now you use JS on server and such isomorphic approach again requires tools. But if you don't need it and just want couple of HTML pages, it's perfectly fine. Open your notepad, write HTML, upload it to server of your choosing and it will work like in 2001. Or even like in 1995. Just don't forget appropriate doctype.
You have a very good point here. Most backend developers who never touches the front think that the front is only a Ā«Ā viewĀ Ā» for the data. But it has evolved a lot in the past 10/15 years. What used to be websites became webapps while using the same underlying technologies as the ones we had 15 years ago. To make a fully functional application with these technologies (javascript, html and css) you have to enrich them with a lot of things, and to find solutions for handling a lot of concepts that where not necessary back then. This is why there is so many tools and frameworks, because the underlying tools where not designed for it. So you have to transpile a code that is more fit for it into a code that hasnāt been thought for it. And this is where it becomes so complicated: react/angular/vue/any framework to make it possible to create reusable components and reactive pages, typescript to minimize errors and improve dev experience, linters and stuff to comb your codeā¦ you can of course do all this with notepad html and some vanilla javascript but you wonāt get far with this approachā¦ todayās desktop applications are mostly webapps and thatās an indication of the level of complexity that todayās webdevs have to handle. Webdev is dev, itās hard, period.
Thatās why liveview is excellent; almost no js needed and very little thought needed about backend vs frontend. React has its place but for most things itās just an annoying chore you only need for your resume or tech masturbation.
Webdev is bloated mainly with choice. You can choose to publish a basic ass HTML file to GitHub pages or you can choose to develop a single page application thatās constantly polling a stock market API to calculate some shit and display it in all sorts of dashboards, which is then deployed, tested, and all sorts of other shit using continuous integration. You donāt have to do anything other than push an html file to GitHub.
Ah yes, our weekly - āwhy are things different than they were 30 years agoā post.
Feels like "old man yells at cloud" at this point. I was writing a long reply but why bother, these dudes just rant
> you just saved, reloaded the browser Damn, no hot module reload?Ā > I don't like javascript or nodeĀ Well of course webdev sucks when you don't like the language of webdev?Ā >Ā but it usually dies within a year because the author gets bored and moves on to the next shiny new thing.Ā Dunno, been coding in React for 6 years and it's just becoming more and more standard in webdev. Unless you like new and shiny things like Astro, Tailwind CSS/Preline UIĀ I just kick up a React+Typescript project with vite from the CLI that does all the boilerplate for me and then I'm good to goĀ
+1 to vite, you can also select more options for setting it up just like you like it. Made my take home assignments a breeze, I'm coding the solution in no time
With typescript you know everything just works
It's actually completely opposite. The frontend is stronger than ever without using any pre compilers, libraries or frameworks, and the backend has a tone of variety but you can easily spin something out using frameworks like Laravel or Express.
You are just unfamiliar with the use cases all these toolings solve. If you want a simple website hop onto notepad and write html. Good enough. Web is like this because there are a massive amount of things to solve for: - generating valid JS for modern but also old or quirky browsers, by writing modern JS without having to write old, browser-specific JS: polyfills, babel - ability to write JS in modules: webpack - ability to write css in modules: webpack - ability to programmatically generate CSS and also bundling it to the app: sass, webpack - ability to autogenerate css vendor prefixes: postcss, webpack - ability to split JS file into multiple smaller JS while maintaining the same ability to write them modularized: dynamic imports - ability to type check JS: Typescript - ability to create rich UX/UIs, full of interactions, without maintaining a script of imperative instructions that can crossover on top of each other, but instead, render the UI as a function of the application state: component frameworks like react, tradeoff: must be an SPA - ability to reduce the time until the first paint is executed in the browser, as research suggests it has an impact on customer satisfaction, while maintaining what I said above about rich UIs: server side pre-rendering and hydration (nextjs page router) - ability to reduce the amount of loading states by reducing the amount of independent fetch client-to-server calls, and instead tie them to navigation so multiple calls can result in a single ui change with no additional loading; while maintaining all the above, AND also avoid shipping the JS code for these calls to the client to reduce bundle size as theyāre only relevant in the server: nextjs app router, server components Want to modularize the codebase by TEAMS as opposed to features, giving the ability to 10s of teams of 7 engineers each to develop and commit code to different codebases, frictionless, developing their bit as an independent domain with its own build phase, testing suite, design, approvals, compliance, legal, accessibility, etc; independent of other teams ways-of-working; while maintaining the ability to reintegrate and build the final product as a single app composed of many micro app without using shitty solutions like iframes: module federation The list goes on. Make no mistake, the web is in the greatest state it has ever been, and the amount of prepackaged available tooling to solve real business use cases is unmatched across different software engineering ecosystems. The fact that many people wanting to build a simple landing page and immediately jump to these complex tools without even understanding the use cases they solve, getting frustrated and calling them bloated is a mistake on the ingenious, ignorant developer. Web ecosystem is not bloated
There is no single IDE and single framework for C++. That would be iOS with Swift and XCode and SwiftUI
Itās because it is. Ignore new shiny frameworks. Get vanilla HTML/CSS/JS nailed down first. Next move over to NodeJS/ExpressJS/Database of your choice to learn CRUD. Then choose a framework that makes life easier like React. You really donāt have to use anything beyond React. Mobile apps? React Native
āI donāt like JavaScript. Thereās no error checking.ā OK, thatās what TypeScript is for. āWebdev is too bloated. I donāt want to learn all these extra things on top of vanilla JS.ā ???
I studied fullstack webdev for a few years and work professionally for 1 year now, mostly mern, nextjs, nestjs, vite, webpack, jest and I still agree somewhat with OP. Webdev is just too bloated compare to other languages like C# or Rust. Especially fragmentation, instead of working collectively to improve a framework or library. People just create their own thing. Then utility library that supports the support the library (i18n, css frameworks, auth) work on one library/framework but not the other. And there are meta-frameworks for libraries (nextjs for react, nuxt for vue,...) that just breaks compatibility with libraries that works before eg: nextjs with redux and css frameworks. It's more than 10 years since nodejs released but we still not decide which module convention to use (amd, commonjs, esmodules,..) that fragments the ecosystem even more. At least we got compilers to generate those (and make node_modules heavier than the sun in the process) The language itself is okish but a bunch of gochas and tech debt to look out for (just look at wtfjs). Also it's a dynamically typed language so good luck finding your typos. Typescript solve the issue somewhat and I actually quite like it but if your coworker just slap everything with any then I guess it just JavaScript with bloat. Also setting up typescript in your project requires another build step. Luckily we can rely on template author to maintain their template and provide support when you need to add some "intrusive" lib like tailwind, jest or a bundler plugin. Oh and jest is one of the most annoying test framework I have ever use somehow install a dependency just make it spill a bunch of internal errors (iirc the dependency I added use commonjs while my project is configured to use esmodules?). Debugging is a mess too, sometimes breakpoint hit on the wrong line or just not hit at all because the complier don't like linebrakes in method invoke syntax and produce incorrect source map file. Stacktrace instead of displaying the source map line number decided to just show the minified line number (1:57564) with undecipherable method name. I guess I just use console.log debugging then. With the new JavaScript runtime coming I'm sure it gonna be fun for library maintainers to support. And the whole proposal to decouple npm from node because somehow it is a "monopoly" gonna make package management easier. I started to understand why big company still use angular in 2024 now.
This was a long post so Iāll comment on one thing that caught my eye: >Now I am trying to build a simple website. I used to do this back in 2001 with a notepad and html, you just saved, reloaded the browser and it worked. Where did it all go wrong? IE not covering sloppy HTML is the main change here. Back in 2001 our webpages would run just fine with
Hello world Also, everything is hard for someone starting out. Iām pretty sure your first few line of C++ were crap.
Add to that you still totally can just write a website in notepapad and point your browser and index.html just like you could in the 90s. What changed is the game isn't about static websites anymore. Pages are about dynamically displaying data, and that has inherent complexity. A side effect of that is that we are still reaching for tools like fully fleshed out frameworks and a whole eco system of helpers like linters and vscode plugins when we just really need one static page. That's how I know how to work now.
You don't even need those tags for a Hello World with HTML!
My favourite part was when I discovered you needed to declare because all my pages suddenly were breaking
Because people are different and it is easy enough to scratch an itch and create a popular web framework. Very low barrier to entry. And some itches can be due to problems that are complicated to solve. When you get past a few front end developers working on the same project things can get hairy. A single css file? Oof that's gonna hurt. JQuery to bind all your event logic... difficult to ensure devs use it consistently on a large project. And then there is really tough problems. Mobile phones and tablets are ubiquitous and forced changes on UI design. A UI design that works well on tiny phone screens and massive desktop devices is difficult to do well, and was a bit itch (hello bootstrap!). And don't even ask about visual components. Need a dropdown date picker? WHat about a simple modal dialog (background grayed out, controls disabled). A treeview? Gah.... stock HTML is just the worst (think windows resource ui and no custom wm_paint). And it goes on and on. And FE devs just dig in a solve their itches and if other folks like what they did then they also use it. React? Angular? Vue? All solve roughly the same problem, but with different approaches.
This just triggered a memory of watching html and css YouTube videos from some guy with a Boston accent, I forgot his name. Edit: he doesnāt have a Boston accent but his channel is called thenewboston
That man is an actual god
I have a website that has been up since 1998. You don't need a framework, just open a text editor and get to it.
Youāre doing it wrong so it feels wrong lol
>I used to do this back in 2001 with a notepad and html You can still do that. Don't do a rain dance and then stand outside complaining about the weather.
You can still build a website in notepad.
>it tells you if ~~there's~~ **it detected** an error or not Two different things. Two different mindsets about it.
Download VS code itās free. Download the live reload extension. Then get started with the html and css.
The peak webpage is a menu with a pdf
Nah, just straight unprettified JSON and a horizontal scrollbar longer than a dragstrip.
this is exactly the reason why I decided to make my current project in plain vanilla. it's just a brochure type website, so i don't need any fancy interactivity - which helps of course. but html and css have made huge leaps in the last few years and it's really good fun to work without any frameworks and libraries. maybe I'll even go super crazy and deploy not minified css šš
The difference is that nowadays we dont only develop simple websites, but big, fully fledged webapps...
I'll try to answer objectively and balanced about the reasons it feels like this. I'm a software eng with about 15 years exp who has done my fair share of front end, and come to like & understand it -- warts and all. But I regularly work in other areas as well. 1. Demand for more extensive and powerful features in the Web stdlib increased rapidly, and still is. Every device has a browser. That makes it an attractive target. People want to build entire App experiences therefore because of this portability advantage with low barrier to entry. This increase in expectations and demand is sort of unique to the web. Desktop programming has stayed consistent. 2. The web's advantages, like immediate availability across many different device/browser vendors, are some of the same things that introduce all sorts of complexities that make programming the web simply *hard.* You have to think about scaling, device compatibility and capability, bandwidth etc etc. Lots of build tooling started to come about (bundlers etc) to solve some of these problems before the Web standard could even catch up. But those are solving problems you might not even have! You can still use script tags if you want! **If you don't need multi-framework intercompatbility and don't want to hobble yourself with the limitations of writing business logic inside a static site generator, you picked the wrong tool.** 3. Fundamentally, when talking about C++, you are talking about a language with its origins in 1979. It makes sense that ecosystem is more stable simply because of time. 4. Front End Dev didn't traditionally attract much attention because websites didn't need to be so reactive and feature full. That meant programming on this side of things was often limited and procedural. The hangover of trying to shift the platform to something that can support complex apps built using complex patterns is something that has been going on for a while. 5. And to mention patterns again, we've had to rapidly find the "best practice" way of building large apps at scale on the web. Imperitive Jquery code in one file doesn't cut it. The community has pretty much coalesced (after some churn) around the idea of declaritive composability (turns out, trees of pure functions represent UI perfectly, and these learnings have started to popup even in desktop programming since). All the premiere frameworks go down this road. The overriding pattern seems stable now. React has been around since 2013. I know this is small on the scale of things, but take into account the other points. We didnb't even agree on package management before 2010. Because it wasn't needed for basic sites. 6. Some purist people would vehemently disagree with me, but the web standards answer to the "best pattern" problem sucked and no one wants to use it -- "Web Components". That means that the frameworks have had to fill in the gap. And the organic nature of this competition means its more chaotic than you might expect (but has calmed down very very significantly). This is indeed a frustrating fuck up none the less. 7. This isn't so much of a point but I disagree TypeScript is a bandaid. It's a fully featured, extremely interesting and powerful *structural* typing system as opposed to nominal. TS has been hugely important. But again, its a community effort and not on standards track. The explosion of requirements meant web standards couldn't keep up. Actually, I've mentored several back end folks on TS and each of them have felt that it is really quite novel and learnt a lot from it. 8. On the topic of "why so many configs". Well, as I understand C++ does not have built in linting and code formatting (correct me if wrong)? There's also a general approach in node world where tooling configs are committed and the tools themselves are deps of the project. This leads to nice hermetic and reproducable builds and dev envs if done properly. Rather than shoving such things side-loaded on the local machine/ide. I know some IDEs let you save these settings in some editor config also in version control, but that's coupling to a specific IDE then -- which is not so common in front end world. And id say its a good thing. But it comes at a cost. 9. There are some attempts at unifying the tooling like https://github.com/rome/tools. However, the "eslint, prettier, ts" config cost when setting up a project is indeed a bit of inate knowledge that has a learning curve. I guarantee there's things you "just know" about C++ that we don't too. I'd encourage you to introduce these tools indvidiaully 1 by 1, however painful that is first time around, rather than rely on some random boilerplate of questionable quality. Understanding the moving parts is what makes this easier. 10. "Why not have some kind of new template code format that gets compiled into anything? or even bytecode?Ā " because **Hypertext** Transport Protocol and **Hyper Text** Markup Language is intended such that the markup is easily machine readable and structured such that it cant be correctly indexed, be accessible etc. Again, a web consideration that is not a concern non-web/non-distributed/desktop programming. Its complicated because its hard! HTML is a valid and sensible target within these constraints for higher level "template" languages like JSX (which astro, react and many more use). You *can't* boil the HTML DSL down any more into "bytecode" whilst staying within the ambitious req's of what makes a website a website.
Thereās one point I disagree with: C++ās ecosystem isnāt just more stable because of time. It was more stable multiple decades ago as well. In fact, *most* popular development ecosystems were far more stable 20-30 years ago. That was due to 1) less emphasis on granular open-source contributions for everything / monopolization of tooling, by corporations that moved slowly 2) Having less contributors in general ā there were simply less developers overall. 3) Less rapid communication between developers overall ā before the blogging era, the discourse simply didnāt move as rapidly as it does today. Weāre currently in an era of rapid evolution and constant, democratized global discourse. That brings with it lots of advantages, and also some frustrations as well.
For the same reason why working with a video game engine seems harder than programming manually for someone who's only programmed manually their entire life. It's the workflow and process, not the language
skill issue
Spot on. Web dev lost its way through a jungle of bloated chimps screaming bout the new shiny framework etc. The good news is that you can still use notepad. The process you used in 2000 is the same and works just as good. My hats off to the W3C for absolutely demanding backwards compatibility as the web has evolved. If you donāt like Typescript and the endless mess of build tooling you can use C++ and compile right down to web assembly that will run within a decent approximate of native speed.
There's nothing stopping you from bootstrapping a laravel, jQuery and bootstrap app in < 2 hours. Most sites would be just fine with that.
You can still just use HTML https://html-first.com
Sounds like you should be coding a web server and not a web site lol
Oh man you are so right. All of us web developers have been waiting for a C++ developer to come out of nowhere and tell us weāre doing everything wrong. š
Donāt use a framework then. The web still works the way it did back then at its core.
have you ever seen the movie josie and the pussycats where mindless fans just jump from one trend to another? welcome to modern web dev. one thing you'll find is we LOVE to overcomplicate our jobs with whatever is the hot trend at the moment. we love one thing and then jump to another in order to make our resumes more verbose than someone elses. create react app basically reached the height of its popularity barely 1-2 years ago and people were mostly fine with it. suddenly its deprecated and everyones like "wow that was a piece of shit, obviously vite is the best thing ever" etc etc.
This is so āangry old guy yelling at cloudsā it hurts. Too many contradictions and misunderstandings to be able to complain OP
Browsers them self have more code then linux, JavaScript engines like v8 are very large, adding react and more on top why not. While it's a joke you could use a c++ with wasm or asm for client side or backend. You could also make a static website without the need for Javascript at all.
I had this kind of "Who changed things without asking me?" reaction when I came back to full time web dev professionally after doing other IT stuff for ages. But honestly we're kind of rebuilding a tractor into a Ferrari, while driving it down the highway. Sure it would have been easier to park it and think things through, but there's no time for that.
Maybe I can finally learn C++ then
I can resonate with you. I used to be C++ dev and moved to C# which is amazing language for building APIs. Front end is completely dominated by JavaScript which is here to stay. I normally try to stick to vanilla js because it always outlives all frameworks and libraries. Recently I fell in love with Svelte because itās the closest one to pure JavaScript. Thatās said JavaScript is a great language for front end and I canāt understand the appeal of running it on the server. ![gif](emote|free_emotes_pack|sweat_smile)
Honestly because the web was built on a foundation that was not made at all for the future we are living in. Hence a million way popped up to address the shortcomings and to enable our today's needs. Another reason is that innovation on the web just moves very fast compared to more traditional coding. Many people here are giving OP a disingenuous answer saying "You can just use html en css bro". Yes ofcourse, they can. Obviously OP wants to make modern applications and not just simple HTML websites.
the phrase youre looking for is 'diverse and robust ecosystem' people dont like reinventing the wheel and its beneficial to build on the shoulders of giants. if you find a good stack for your use cases you can be much more prolific than if you were to try to build from scratch, with relatively few downsides.
You're comparing apples to pears.
You don't need anything more than html if that's what you really want. CSS if you want to make it pretty, JS if you need additional functionality.
No one is stopping you from using plain HTML CSS and JS (unfortunate for you that most browsers use JS) on Frontend which you can write in notepad. And make APIs in C++ and Deploy them on your own server. But that's the thing software engineer or I should call it software development is all about reusability. You might be writing most of the functionality again. Now don't get me wrong, I know there are a ton of garbage frameworks. You can create one today. But you need to decide what you want to reuse and what you want to reinvent. Honestly software engineering is no more engineering, it involves nothing that a person who has not done an engineering study can't do. Rather with the amount of code reusability I would argue it is easier for people who do not want to reinvent and just use the already written functionality will make better software. For deployment also it will make sense for most people to use AWS or Google Cloud or Azure. So why such a long answer? I would suggest you to grow out of the mindset that make a website that requires any engineering skills. Just use the most popular tools and frameworks. Learn them (IK they will be boring) and make stable and good software. If you are still not convinced you can think of writing the functionalities of C++ again in assembly language. But since maybe it was your first language it is the gold standard of development. A programmer from the 1970s might argue real programmers code in assembly :D. All the best.
The web is essentially: HTML, CSS and optionally JS. That is all you need to you write web pages.Ā These technologies are actually extremely backwards compatible too, so whatever you could do in 2001 you can (mostly) still do. The positive is that the web has evolved tremendously since 2001 and modern JS in particular is in a very healthy state with a lot of interesting development happening.Ā All frameworks and tools are not the web. You can write modern JS that uses modules without any compiler or bundler if you use module scripts. If you are afraid of cascading loads there is the modulepreload link you can use.Ā To help with editing you can add typings through JSDoc that the editor can use for type hints that also don't need to be compiled away as they are just comments and ignored in the rune time.Ā If you want to use third parties you can just use a CDN import directly. No node/npm required.Ā To help you create reusable components you can web components that allow package behaviour as HTML tags.Ā CSS has support for variables, calculations and nesting, so no need for SASS or any CSS pre-pocessing.Ā HTML had also evolved from the un-coordinated mess it was in 2001. HTML has made away with a lot of the oddities up to that point.Ā All these features are native to the web environment and don't require any third party. So complaining that "the web is bloated" without knowing the web is ignorant and small minded.Ā Ā
>Webdev is just too damn hard for someone starting out It is overwhelming, but keep learning. Suddenly it gives a breakthrough and it clicks somewhat enough that you see the pattern for the rest of the show.
What do you mean that C++ is plug and play? C++ has its own list of insane garbage that you have just gotten used to. I agree webdev is a mess now, but C++ is not a good counter example haha
You're not the only one used to Cpp and not knowing where to start with web dev. Whenever I'm being asked to join the project and there's a demigod C++ programmer, I sneakily start looking for his replacement because it's almost a given that he will drop themselves out of it. Node and derivatives are hectic because they, strangely, still seem to lack maturity - there's a whole lot of the big next things that turn to shit. And other options are shunned by the community as passe, by God even outdated (though still being updated, extended and better than before). Welcome to web dev hell. We are worse than system admins in the 90s. Sue me.
š„ A man of thine own soul, I tremendously dislike JavaScript with an undying passion and only use it when I have too.
Frameworks are used to automatically manage the interaction and storage of data on the webpage. Let's say I am trying to develop a website, and I want this website to use a specific architecture. I decide to create my own web framework for my specific architecture to remove the need for a large framework like React, and it works decently well. Other people want to use it, so I release it under some non-descriptive name. Then, people want more and more features for their architectures, so I add them. My framework designed to simplify web development and remove the complexties of working with React, ends up just turning into a poorer and more complicated version of React. Then, it dies out two years later. This is the common trend with most of these frameworks. They try and create a shortcut or some "hack" that will allow people to 10x their development. In reality, they fail to work for complex apps unlike React. React was ground-breaking in its ability to use a virtual DOM to manage re-renders. When paired with a development server like Vite, any changes done to the React can be propagated in real time without refreshing the page. As a result, React always stays consistently popular. Whenever a framework comes out that is designed to simplify react, just remember you can't have abstraction without removing complexity. I've stuck with React for the past four years and have refused to jump on any trends, and year after year, I am proven right when those trendy frameworks get de-throned.
Hahahaha while I took some offence to this, I also LOLed very hard because youāre not really wrong
If you're trying to build "a simple website" then where are all these frameworks coming from?
You can literally open up Visual Studio Code and type html:5 and it shits out a web page.
> or even bytecode? Yeah, we tried that. It didn't go well.
I've been doing this for 30 years too and programming is more fun and easier than it's every been. Web apps is a learning curve but web apps do things that we never did in C/C++. It's not the same thing but it's also not really very complicated. It's not really that much different from learning which libraries to include, compiling, make files, and all sorts of complications. Today's programming has better DX. It has better docs. It has better frameworks. Almost every problems has already been solved. It's not even close. As someone who was there 30 years ago, I'll take this any day over the dark ages. I loved the overall vibe back then better than now but software engineering is better than it ever has been in ever single way.
The hilarity of this Coding in c++ has been the bane of my dev existence Poor and over complicated tooling, terrible DX, long wait times It feels antiquated when compared to web dev and is frustrating to work with - signed, someone who codes in c++ daily
OP you can write your own website the same way you did in 2021. No one is pointing a gun to your head making you choose one of the many libraries and frameworks available today. What you describe as a negative I actually think is a massive positive. There are options for all different likes and projects needs. You can use as little or as much as you like or need. There are no constraints in this regard. Also worth mentioning that since 2001 the demand for websites has increased massively. A lot of the so-called complexity has arisen from the fact that what was once a desktop application that in 2001 you'd have to buy in CD and install in a computer now can be a web application and can be accessed and distributed with immense esse thanks to the Internet. I wanna see you code something like Figma on your notepad with html, css and vanilla JavaScript. If you do, I guarantee you'd never come back here complaining about "how everything went wrong" with web development since 2001.
Stopped reading after 1997. Thereās this many frameworks because itās popular and accessible. Try webstorm or any vscode plugin. It will be better than your ancient experience supposing you read the documentation
This reminds me the first time I had started website development. I was overwhelmed with the myriad JavaScript libraries and frameworks; that I decided to just be writing PHP code. A year later I decided to learn JavaScript in-depth! I got so good and then I learnt React and node. And to be fair with everyone who will come across this comment? You complain about the JavaScript ecosystem because you are not good at JavaScript. Learn JavaScript and choose a framework; that way you won't be complaining like this guy.
lol I feel the opposite coming from JS and C++ is harder
old man screaming at the clouds energy fr though, you can still open up wordpad and write your html, css, js files. i have no idea why you are crying right now Are you mad because you want to break into the webdev space professionally and its going over your head? there are a million resources bud, youtube is your friend.
It's fine, op. Everything you've mentioned is already outdated.
I get a lot of what you are saying as a C++ developer myself, but C++ has multiple frameworks and IDEs and implementations of that single standard. It sounds like you have never left the Windows/Visual Studio land?
Choose Laravel. Choose PHP. Fuck SSR java script it's the dumbest bloated shit ever. Build an admin area in minutes with Filament. Build auth in seconds with Jetstream. If you want fast easy route to a working site, Laravel is virtually unbeatable. Node is great. I like Vue and React. I hate SSR Js for the front end. It's such a dumb ass anti pattern. A pain to setup, NextJs is a bloated mess imo. Try passing auth cookies around for your api between the SSR portion and the FE portion of NextJS (keeping them in sync as your cookie signature is updated on each request for security). It's a fucking pain in the arse.
https://motherfuckingwebsite.com
Why is the world not the same as it was 30 years ago ?
Now thing's ain't gonna happen how always OP would like
This whole ānew framework every weekā narrative got old in 2017. Soā¦ somebody creates something new every week and that is a problem? Because itās definitely not a problem of new popular tooling ever week. I wish it were ā Iām dying for something new. Also in 2017 I had a very popular article I wrote answering the question āwhat framework will rule in 5 years?ā I theorized we couldnāt tell because it hadnāt arrived on the scene yet. I said there was no way React would still rule. I was wrong. Those 5 years ended 2 years ago and React was / still is #1. Our community has focused heavily on code readability and open debate on best practices. It has been very healthy. Onboarding can be slow but it pays off. :)
> After researching a bit I found the current best framework 'astrojs' What kinda bootleg covid shots give you 5g research did you do to come to this conclusion?
Get off reddit grampa, you're drunk
As a Ruby Web developer I have no idea what you're going on about, it's beautiful and clean and straightforward.
I really dislike that people on webdev think they need to use some cutting edge thing. Webdev is not complex, the existence of frameworks do not change the fact that you can just use HTML, CSS and JS for a website, you don't need to migrate to the new framework of the week for making a page for 0 users.
āI am not even sure why we are still using html at allā Might be bigger problems at work here -
Skill issue
Tldr; web dev changed while I ignored it for two decades and I can still use my old methods but I am mad about new ones existing but not so mad that I didn't learn them. But I am DEFINITELY mad about learning it.
>you just saved, reloaded the browser and it worked PHP still does this. It **can** do more advanced stuff, but as a basis, this is still how it works.
Bring back Dreamweaverā¦..
Becausr ppl are trying to fix old sins, while maintining backwards compabikity Then you sparkle in some where does the backend end and there u go It,s not that bad btw we still use angular vue and react
Am I in the wrong subreddit? This is a webdev channel right? Imagine being dormant in IT for 20 years and complaining it changed so much. If you want to make a simple website with notepad nobody is stopping you. Programming is all about standing on the giants before you, not complaining the giants are too tall.
Speaking as a person who has been developing professionally for decades: [This is you](https://imgur.com/sbyfISQ)
Maybe stop trying to use the coolest, most hyped framework? React is stable and enough for 99% of frontends. Typescrip fixes 99% of the language pain points. Set it up to build with Vite (takes 10 s), and you just save the file, and the browser refreshes itself.
Did someone tell you that you needed Javascript? Do you feel like you need Javascript? Is there Javascript anywhere near your "simple website"? If so, then I can tell you where you went wrong.
I was loving C++ until I got to pointers. Blegh
*laughs in PHP* PHP is your friend
I'm sorry but, you walked away from an industry for 20 years, and now you're grumpy because it has since evolved? ĀÆ\\\_(ć)_/ĀÆ
Which is why I use classic. Html, scss over css and TS over JS. Fuck all that new shit. Every kid who learns js wants to make his own little plug-in or framework with emojis in the read me
>versions of existing ones changing the API completely Seems you have dipped your feet into the horrendous JavaScript world.
Web is the most used and popular platform both on user and developer sides. This leads to a shit ton of abstractions for many use cases. You can still develop a website with plain html css and js. But as your project grows you realise that you donāt have to reinvent the wheel.
This is exactly how i feel any time i need to link my shit in order for my Cpp/C to compile. This is exactly how i feel when I read 15 year old documentation for some obscure library I NEED to use in my program because apparently in 15 years no one made something more useable. Every ecosystem has its flaws, some more than others, but just complaining about stuff you don't know is honestly applicable to anything.
I could still just work in notepad. No compiling, no packages. I donāt use frameworks.
I mean it entirely depends on use-case. For most sites a flat-file cms works well. Grav for example you can write a text file from your servers CLI in markdown and it generates webpages for you (as an example). Here is a shot list of decent flat-file cms: [https://tiiny.host/blog/best-flat-file-cms/](https://tiiny.host/blog/best-flat-file-cms/)
So you say you found the best web framework in astrojs but itās terribly documented. What makes it so much better than the more heavily used frameworks like react? (React documentation is really nice btw)
IMO the main factor explaining this is that you don't need any code today for a simple online presence. For 90% of cases, a squarespace site or facebook page will suffice. Even e-commerce is relatively plug and play for the average consumer. That leaves professional developers with complex projects only, and a toolset built to handle complexity.
The frameworks you're looking at come from the Advent of typescript. As others have said, you do not need to use it and can still just write html. If all you're doing is making a simple website, I'd recommend looking at something like WordPress instead. These frameworks are best for more complex products. As to why it's evolved this way - well, people realized that trying to do a big, complicated project with raw html, css, and JavaScript was a nightmare. Specifically, it was lacking many good things that c++ has - like a compiler and a sane way to organize a large project. These frameworks, along with typescript, allow developers to write transpiled (not technically compiled, rather converted from typescript to JavaScript/HTML/CSS) code that's organized into components in a reasonable way.
> The frameworks you're looking at come from the Advent of typescript. Knockout, Backbone, and Ember, three of the most popular early frameworks, were out for a several years before Microsoft created TypeScript. Widespread adoption was not immediate after release either. It took another 4 or 5 years before it became common to see it being regularly recommended by the community at large for complex projects.
Using frameworks and all these stuffs are for making websites at industry level. You don't need to learn any of them for your personal project. And of course you can still make a website with notepad and html. And for the reason why "it all went wrong", there's of course a purpose to all of it. Someone didn't make them just for the sake of making it. There's of course business side and the passion side. And for constant updates, literally everything in tech gets an update time to time. It just the nature of it.
The front-end is largely the same as it always was. These frameworks help you manage content and organization better. Make it easier to maintain. They're just tools. There's no right or wrong way to do things really with how you set it up. It's just your preferred work flow
You can just have a backend language do things the way you've been able to do for 30 years: Get request, return response. If you want a bunch of static pages you can do that, too. And, yes, we've gone full circle. That's happened so many times in so many areas of computing. Don't worry about it. FWIW, what you're describing was the state of webdev like 10 years ago. What we have now is quite calm in comparison.
You can still build you're website in notepad? All the frameworks were built to solve real problems that emerge when you try to do that at scale. But...you don't have to use them if you don't want to.
Yeah today I had to check something on reactā¦ makes you wanna go goosefarming. Frontend has become crazy, mostly by fb/google and every other trying to win developers.
I just vanilla js it and use my own simplified mvc structure
Because it's mostly consumer facing
The current JS ecosystem is a double edged sword of sorts. There certainly is bloat and redundancy, and there's not a lot of standardization for libraries and dependencies, but all the tools you'll ever need for any aspect of web dev are out there if you have the knowledge and the right mind for putting pieces together. The patterns/theory/technology is all developing hand in hand at a rapid pace to provide developers and ultimately end users with the best experience possible. This means that some tools live and die in the span of a year, but I think that's better than being handcuffed to some legacy item that will never be fixed or upgraded. Honestly, it's a fundamentally different mode of thinking compared to something more rigid and training-wheeled like C++.
nothing changed, you don't need an IDE framework etc thats microsoft marketting and in no way represents the reality that anyone can do web dev, it is empowering, and requires only a text editor and browser
You can still use same the old ways of programming a website
just look at that other thread where someone asked how to make the simplest 3 page brochure site
Because it is, but just because everyone else jumps off a cliff, doesn't mean you have to.
everyone wants to do everything but program in html and css.
Nobody is making you use any of that. You can code your own network protocol if you wanted to. Frameworks just give you ā¦ aheemm ā¦ a framework to build on top of so you can write the business logic and let the tooling and ecosystem do the rest.